«Собака BUGскервилей» и «Однажды в Bravera Capital» — вы, наверное, подумали, что это названия свежих детективных романов? На самом деле это заголовки заданий киберучений главного онлайн-кэмпа по практической кибербезопасности CyberCamp 2025.
Задания CyberCamp 2025 стали еще ближе к реальным вызовам. Некоторые из них позволили участникам почувствовать себя в роли современных ИБ-специалистов и прокачать свои профессиональные навыки — от поиска секретов в истории Git до расследования APT-атак. Разбираем самые запутанные и интересные задания — те, что помогли не просто «набрать баллы», а получить практический опыт.
«Собака BUGскервилей»
Задание от Axel PRO
Количество баллов: 150
Время на выполнение: 30 минут
Что случилось?
Что делать?
С помощью «Шерлока» разберите все уязвимости на эксплуатируемые и false-positive и отыщите все спрятанные флаги. У вас есть проект с набором подсказок, часть из которых спрятана в отчётах сканеров (Secrets/SAST/Image scan), истории коммитов (удалённые файлы) и описании проекта.
Действуем!
Флаг №1 «Что мы знаем о команде? Для этого есть карточка с описанием проекта»
Да, хочется сразу «броситься» в анализ ИБ-дефектов и разметку, но любая ИБ начинается с инвентаризации и понимания того, «а с чем вообще мы работаем, что это такое и зачем оно нужно».
Разработка безопасного ПО — не исключение. Информация о проекте располагается в «Карточке проекта». В ней могут содержаться данные, которые могут быть полезны при работе AppSec-специалиста:
Наименование ПО
Критичность ПО
Описание
Состав команды
Информация об используемых реестрах
Сведения о доступных стендах и прочее
Для того чтобы открыть «Карточку проекта», после авторизации в «Шерлоке» перейдем к выданной нам группе
и найдем кнопку просмотра описания проекта «О проекте».
В самом низу «Карточки проекта» окажется флаг SHERLOCK{h1dd3n_1n_pr0j3ct_c@rd}.
Флаг №2 «Кто это: проведите аудит пользователей в проекте»
Посмотрим, что еще мы можем узнать о проекте. Описание следующего флага «Кто это: проведите аудит пользователей в проекте» подсказывает, что нужно получить сведения о пользователях, которые имеют доступ к проекту.
Воспользуемся поиском, зная маску флага — SHERLOCK{…}
«Соединяя» логин SHERLOCK и почту «wh0_1s_th@t.us3r», получаем флаг — SHERLOCK{wh0_1s_th@t.us3r}.
Флаг №3 «Изучите Critical CVE и найдите флаг»
Наконец-то! Можно перейти к ИБ-дефектам и немного с ними поработать! Но где искать?
В названии задания есть подсказка — «Изучите CVE». CVE характерны для ИБ-дефектов типа SCA и Image Scan. Отлично! Это сокращает область поиска в 2 раза.
Продолжаем отсекать «лишнее». Нам доступен только один «критичный» ИБ-дефект, даже фильтры использовать не придется. Изучим всю доступную информацию и отметим бурное обсуждение в комментариях.
Можно увидеть, что последний комментарий от AppSecAnton изменен. Для того чтобы получить информацию о том, каков был комментарий до изменения, можно воспользоваться «Историей ИБ-дефекта», в которой отображаются любые изменения (критичность, статусы, задачи в Jira, комментарии), связанные с ИБ-дефектом.
Voila! Вот и наш флаг — SHERLOCK{h1dd3n_1n_1nc1d3nt}.
Флаг №4 «Узнать все: референсы со сканеров помогут найти флаг»
Референсы — дополнительная информация, которая может помочь AppSec-специалисту лучше понять, в чем заключается суть ИБ-дефекта. Эта информация предоставляется большинством различных сканеров, вне зависимости от их типа (Secrets, SAST, SCA, Image Scan и прочее). Поэтому как-то «сократить» область поиска, как в предыдущем задании, не получится.
Есть и хорошие новости: для анализа доступен всего 21 ИБ-дефект. Если присмотреться, часть из них имеет статус «Устранен», «Проигнорирован», «Риск принят», и они нам неинтересны. Сфокусируемся на «Новый» и «Подтвержден». Уже что-то! Их всего 12. Поочередно открываем карточки ИБ-дефектов, заходим на вкладку сканера и просматриваем референсы. Где-то в 9-ом ИБ-дефекте оказался тот самый флаг — SHERLOCK{f3w_p30pl3_l00k_h3r3!}.
Флаг №5 «Несекретный секрет: точно ли удалены секреты?»
Название флага намекает, что нужно проверить ИБ-дефекты типа Secrets. Нам доступен только один такой, с некоторым интересным комментарием.
Нажмем на ссылку public/secret_secret.txt и перейдем в GitLab.
Странно… указанного файла нет в репозитории. Возможны несколько вариантов — либо сканер ошибся, либо файл был, но в актуальном commit его нет. Проверить первый вариант при прохождении задания мы не сможем, а вот второй — вполне! Обратимся к истории commit’ов.
Сразу 3 commit’a «Update file secret_secret.txt» на выбор:
fbce97602b0fedc4a4bac8d29b142cdff9f7f1cd
7bed5861fda3120fb49e150616b6fee982238f57
68e085090b1448f6c3254b303e78e63bb5d21e2d
Проверим их все. В первых двух ничего интересного. Разве что добавление и удаление закрытого ключа (не делайте так, используйте специализированные решения по управлению секретами ?). А вот в «68e085090b1448f6c3254b303e78e63bb5d21e2d» находим то, что нам нужно — SHERLOCK{bur13d_1n_h1st0ry}.
Возможен и иной вариант решения. Для этого нам потребуется скачать репозиторий и найти удаленные файлы. Воспользуемся командой: git log --diff-filter=D --oneline --name-only.
Остается только вывести содержимое удаленного файла: git show $(git log --diff-filter=D --oneline -- "frontend/public/secret_secret.txt" | head -1 | cut -d' ' -f1)^:"frontend/public/secret_secret.txt".
И, если долго всматриваться, то можно увидеть уже знакомый нам флаг.
Флаг №6 «Тестовый секрет: сможете его отыскать в результатах SAST?»
Идем на вкладку SAST и смотрим, что у нас есть. Всего 5 ИБ-дефектов. Можно, конечно, открыть их по очереди, а можно обратить внимание на поле «Тип». Статические анализаторы классифицирует находки по разным категориям, например, обход директории, всевозможные инъекции (SQL, LDAP, Command и другие), межсайтовый скриптинг, отказ в обслуживании и тому подобное. В задании указано «отыскать текстовый секрет». В доступном нам перечне есть один ИБ-дефект с типом «Чувствительные данные в исходном коде». Откроем его карточку.
В комментарии на строке №7 находим искомый флаг — SHERLOCK{53CR3T_4CC355_K3Y}.
Флаг №7 «Проду это не нужно: снова подскажет SAST»
Просьба не расходиться! Остаемся во вкладке SAST! Опять посмотрим на типы ИБ-дефектов:
Некорректное управление доступом
Внедрение команд ОС
Чувствительные данные в исходном коде // молния, вроде, не бьет 2 раза в одну точку?
Прочее
Что бы мы не хотели видеть в проде? Конечно же, все из перечисленного. Но что такое «Прочее»? Откроем карточку ИБ-дефекта для уточнения информации.
Bingo! Такое точно недопустимо для прода. Отключаем debug-режим и забираем флаг — SHERLOCK{bug_m0d3_3n@bl3d_1n_pr0d}.
Флаг №8 «Опять баг: точно ли был фикс?»
Тут есть небольшая отсылка к другому заданию киберучений — «Устрой deploy». Уязвимость, которая была использована для развития атаки, так и осталась неустраненной. Поэтому нам надо найти в результатах сканирования SAST ИБ-дефект с типом «Внедрение команд ОС».
Прочитав грустную историю в комментариях, посмотрим на сам код. Видим искомый флаг SHERLOCK{h@lf_p@tch3d_d00r} на строке №51.
Флаг №9 «Релиз-кандидат: стоит проверить, был ли фикс в ветках»
«Шерлок» позволяет консолидировать результаты сканирований разных веток проектов. До этого мы работали с main-веткой. Название задания подсказывает, что нужно проверить — нет ли других веток.
То, что надо! Переключимся на release-candidate-ветку.
Набор ИБ-дефектов изменился. Исходя из задания, нам надо проверить наличие фикса, так как ИБ-дефект должен быть «Устранен». У нас есть только один такой — откроем его карточку.
Увы, иногда и так бывает… Забираем рекомендацию и сам флаг — SHERLOCK{@lw@ys_ch3ck_1nl1n3_1gn0r3_c0mm3nt}.
Флаг №10 «Красивая картинка: что скрывает лого CyberCamp»
Бонус! Да, это задание не имеет прямого отношения к «Шерлоку», но разработка безопасного ПО не ограничивается работой с результатами сканирования.
Переходим в GitLab и ищем лого CyberCamp. Оно доступно по пути: /frontend/public/cybercamp.svg. Качаем логотип и откроем его, например, в Notepad++.
Получаем флаг, заботливо спрятанный в самой первой строчке — SHERLOCK{funny_b1n@ry_gh0st}.
Что это было?
Задание стало идеальным введением в AppSec: от инвентаризации и анализа сканов до проверки фиксов в релизных ветках и поиска артефактов в бинарных файлах.
Задание имело уровень сложности «средний», его прошло более 40 команд-участников CyberCamp 2025 корпоративной лиги, с чем мы их и поздравляем! Быстрее всех справились ребята из TraumaTeam, которые получат специальные подарки от Axel PRO.
«Однажды в Bravera Capital»
Задание от R-Vision
Количество баллов: 300
Время на выполнение: 120 минут
Что случилось?
Что делать?
Вам как ИБ-специалистам поручено расследовать этот случай. Пользуясь инструментами R-Vision SOAR и R-Vision SIEM, изучите предоставленные артефакты и помогите компании разобраться, как злоумышленники проникли в сеть и что именно произошло.
Действуем!
1. Уязвимость, позволившая получить административные привилегии в базе знаний.
Да уж! Данных много, глаза разбегаются… Но начинать с чего-то надо! Например, с восстановления хронологии событий. Для этого добавим в SIEM поле device_time. Это позволит нам лучше ориентироваться «во времени и пространстве».
При изучении событий можно заметить, что помимо Veeam, Windows и Linux событий есть информация о Confluence. Отлично! В базах знаний много всего интересного, изучим ее более детально. Для этого добавим фильтр device_product = confluence.
Легче не становится… 711 событий… Чтобы отсечь лишнее будем смотреть только на PUT и POST-запросы, т.к. они могут изменять данные. Просмотрев несколько событий замечаем, что есть очень подозрительные. Например, запрос на создание нового администратора с IP-адреса 95.104.169.124. Создание привилегированных учетных записей процедура не типовая, проанализируем ее.
Кроме создания привилегированной учетной записи есть еще одно очень странное событие – перевод Confluence в режим инициализации.
Запрос инициирован с уже знакомого нам IP-адреса – 95.104.169.124. Совпадение? Не думаю!
Разделяй Собирай и властвуй! О чем нам говорит совокупность этих двух событий? Правильно, это говорит о том, что злоумышленник воспользовался CVE-2023-22515, характерной для Confluence версии 8.0.0.
Забираем желанный флаг и идем дальше!
2. Время добавления злоумышленником нового администратора (device_time)
Где-то мы уже это видели… Осталось только найти нужное время. Его хорошо видно в «Деталях события», в котором злоумышленник создал нового администратора – 15:06:27.
3. Уязвимость, позволившая выполнять команды на веб-сервере
Одного сonfluence злоумышленнику явно было мало, и он продолжил атаку. Его целью стал веб-сервер. Надо определить выбранный им путь. В качестве зацепки можно было использовать выявленный ранее IOC — IP-адрес 95.104.169.124. Видим обращение с него к файлу шаблона text-inline.vm.
Воспользовавшись опытом или любимым поисковиком, понимаем, что обращения к этому шаблону связаны с эксплуатацией уязвимости CVE-2023-22527. Очень неприятная штука – она позволяет позволяет реализовать удаленное выполнение кода (remote code execution, RCE).
4. Имя файла, использованного для сканирования инфраструктуры
После удачного «захвата» Confluence, злоумышленник решил осмотреться. Ему надо было понять, как можно развить атаку. Для этого он изучал внутреннюю сеть Bravera Capital. Надо узнать, чем именно он пользовался. Ответ на этот вопрос можно найти в событиях сервера, записанных с помощью auditd.
Haha, classic! Конечно же это nmap (его даже в фильмах показывают, правда не всегда правильно запускают, но не будем заострять на этом внимание). Злоумышленник попытался «спрятать» nmap «превратив» его в некий scnr. Наша задача – изучить события и найти этап «трансформации», в котором мы найдем интересующий нас флаг.
5. Утилита, использованная для проникновения вглубь инфраструктуры
После сетевой разведки злоумышленник начал свой путь внутрь инфраструктуры, задачей команд было найти инструмент, который для этого использовался. Поиск по событиям EXECVE на том же сервере наводит нас на след использования Chisel.
Также фиксируем его запуск в соседних событиях:
6. Уязвимость, позволившая получить доступ ĸ учетным данным
Если не знаешь с чего начать, начинай с начала! «Точкой входа» в Bravera Capital для злоумышленника был веб-сервер. Найдем все события, которые с ним связаны. Для этого указываем src_ip = 10.150.208.6 (IP-адрес веб-сервера) и видим обращения к контроллеру домена и системе резервного копирования.
По событию запуска Chisel мы видели, что выполнялся проброс портов 3389, 6160 и 9401. Порты 6160 и 9401 используются как раз Veeam Backup. Уделим ему должное внимание. На том же скриншоте выше видим неуспешные и успешные попытки входа пользователя с именем vvonka c веб-сервера на сервер резервного копирования:
Тут же видим обращение cо скомпрометированного веб-сервера на API-порт Veeam и сервис veeam.backup.service:
Просмотрев еще несколько событий, обнаруживаем «Зафиксирован запрос на просмотр информации о всех УЗ»:
По имеющимся зацепкам плюс последующему успешному входу по RDP (на скриншоте выше) пользователя vvonka мы можем сделать вывод, что злоумышленник проэксплуатировал уязвимость CVE-2023-27532 и получил в своё распоряжение валидную УЗ. Уязвимость позволяет неаутентифицированному пользователю с сетевым доступом до Veeam Backup извлечь учетные данные, хранящиеся в конфигурационной БД, с помощью запроса по API.
7. Имя учетной записи, полученной атакующим
Как мы видели выше, злоумышленник воспользовался для входа на сервер резервного копирования УЗ vvonka, это и был правильный ответ на вопрос.
8. Наименование задачи на резервное копирование, завершенной при помощи Powershell
Ищем все Powershell-события по EventID 4104 и находим нужный – ad-backup!
9. Количество хостов, на которые заходил атакующий под скомпрометированной УЗ
Мы уже знаем имя скомпрометированной учетной записи – vvonka. Осталось составить простой фильтр, который позволит нам найти ответ на поставленный вопрос.
Но есть нюанс! Куда уж без них. При детальном рассмотрении можно заметить, что для входа на DC01 учетная запись vvonka не использовалась, присутствуют только события Kerberos. Поэтому правильный ответ на задание – 3.
10. Имя хоста атакующего
Для поиска ответа вернемся к событиям успешного входа пользователя vvonka на сервер Veaam. В «Деталях события» смотрим на src_hostname и забираем флаг – macbook-pro.
11. Семейство вредоносного программного обеспечения, использованного для нанесения вреда инфраструктуре
Для начала нужно было отыскать вредонос, который использовался злоумышленником для нанесения ущерба. Сориентироваться помогал поиск по событиям 4688 на сервере резервного копирования. Мы видим 177 событий запуска процессов:
Если переключиться на «Статистику», то один исполняемый файл сразу же привлекает к себе внимание, не правда ли?
Имя файла очень похоже на hash-сумму. Убедиться в этом можно прочитав данные Sysmon-события, раздел «dst_process_hash_sha256».
Этот же хэш можно было обнаружить в событиях от KSC c хоста win02, сигнализирующих об обнаружении ВПО:
Обнаружен вредонос был на хосте win02, но не на сервере резервного копирования, где хоть анивирус и был запущен, но базы, по-видимому, не были обновлены. Далее поиском по хэшу выходим на отчеты по анализу вредоноса, например, эти:
Это позволяет нам понять, что финальным аккордом атаки злоумышленника стал запуск шифровальщика семейства Lockbit.
Что это было?
Это задание воссоздавало классическое расследование APT-атаки в условиях корпоративной инфраструктуры. Оно требовало уверенного владения инструментами SIEM/SOAR, понимания тактик MITRE ATT&CK и умения работать с логами операционных систем (включая auditd, Sysmon, PowerShell). Особенно выделялся финальный этап: только 10 команд смогли корректно идентифицировать семейство шифровальщика по хэшу и событиям запуска процессов.
Наибольшее количество баллов (262,5) в корпоративной лиге за это задание смогла получить команда socRAT. Они справились с заданием за 61 минуту. В студенческой лиге первое место заняла команда EXE.1sior – 187,5 победных баллов и 161 минута на решение. Поздравляем участников!
«Политик аналитик»
Задание от UserGate
Количество баллов: 200
Время на выполнение: 60 минут
Что случилось?
Что делать?
Помогите Архитектору: проанализируйте политики UserGate NGFW и UserGate WAF, которыми защищены ресурсы подключаемой инфраструктуры, и выявите все недостатки. В вашем распоряжении — доступ к панелям управления каждого СЗИ в режиме Read-Only, все мисконфиги необходимо искать в них.
Действуем!
1. По какой причине правило межсетевого экранирования №8 (с привязанным профилем СОВ Cybercamp_Profile) не обнаруживает угрозы атаки типа bruteforce протокола RDP?
A. МСЭ UserGate не поддерживает детектирование данной атаки.
B. В профиле СОВ нет сигнатур для детектирования этого типа атак.
C. На виртуальном МСЭ слишком мало места для записи события об обнаружении.
D. В правиле с профилем СОВ используется сценарий, условия которого не выполняются.
E. Для соответствующей сигнатуры в профиле выставлено значение «Пропустить».
Чтобы ответить на вопрос, изучим профиль Cybercamp_Profile и особенное тщательно рассмотрим сигнатуры, которые в него попали:
Как мы видим, в профиль включены далеко не все сигнатуры. Проверим, есть ли среди них RDP Bruteforce. Добавим в фильтр поле «Класс» и отметим только «bruteforce»:
Видим, что относящихся к RDP сигнатур не просматривается. Делаем промежуточный вывод и идем далее: проверим сценарий, привязанный к правилу:
Заглянув в сценарий, понимаем, что правило сработает только если нет доступа в Интернет и недоступен внешний DNS-сервер, что нелогично:
В итоге мы имеем два верных ответа на вопрос:
В профиле СОВ нет сигнатур для детектирования этого типа атак
В правиле с профилем СОВ используется сценарий, условия которого не выполняются
2. Почему правило PBR "Intruders_Routing_1" не перенаправит трафик на нужный шлюз, если роль мастера переедет на ноду slave_cybercamp?
A. Правило выключено и не обрабатывает трафик.
B. Нет дублирующего правила для ноды slave_cybercamp.
C. В правиле не определена зона источника трафика.
D. Правило обработает трафик, но в событиях не отобразится, так как не включено журналирование.
Для поиска ответа на этот вопрос нам понадобиться доступ к обоим узлам кластера NGFW. Проверим наличие правил для шлюзов на каждом из них.
Изучив списки, видим, что правило для шлюза Slave ноды (Block_GW_2) отсутствует.
В случае такой конфигурации при смене роли Slave-ноды на Master не будет подходящего правила для работы PBR. Правильный ответ на вопрос найден: нет дублирующего правила для ноды slave_cybercamp.
3. По какой причине в журнале трафика нет событий по правилу №2 межсетевого экрана?
A. В названии правила говорится, что оно разрешающее, а действие выставлено «Запретить».
B. Некорректно задан Сервис в правиле.
C. В правиле нет критериев, удовлетворяющих проходящему трафику.
D. Для правила не включено журналирование трафика.
E. Трафик не доходит до правила, поскольку его «затеняет» вышестоящее.
Изучение правила помогает сделать однозначный вывод: журналирование не активировано, что и является правильным ответом на поставленный вопрос.
Далее шли несколько вопросов, касающихся неработоспособного кластера, о чем свидетельствовало предупреждение в панели управления:
4. Кластер находится в состоянии «Ошибка». По какой причине это происходит?
A. На зоне "Cluster" в контроле доступа нет разрешения «Кластер».
B. Между интерфейсами нод кластера не настроена маршрутизация.
C. В правилах межсетевого экрана есть правило, которое блокирует синхронизацию нод между собой.
D. Выполняется попытка собрать в кластер устройства с различными версиями ПО.
Начнем с простого! Проверим версии программного обеспечения, установленного на всех узлах кластера. Хм, вроде все идентично…
Думаем дальше! Для корректной работы в зоне с кластерным интерфейсом должна быть активна опция «Кластер». Проверим настройки и…
Вот и ответ на вопрос:
· На зоне "Cluster" в контроле доступа нет разрешения «Кластер»
Следующий вопрос раскрывал предыдущий и участникам нужно было понять, как исправить ситуацию.
5. Вы обнаружили, из-за чего кластер находится в состоянии «Ошибка». Какое действие необходимо предпринять, чтобы вернуть кластер в работоспособное состояние?
A. Необходимо перезагрузить по очереди обе ноды кластера.
B. Включить на зоне безопасности Cluster ноды main_cybercamp разрешение «Кластер».
C. Включить на зоне безопасности Cluster ноды slave_cybercamp разрешение «Кластер».
D. Включить на зоне безопасности Cluster обеих нод разрешение «Кластер».
Правильно ответив на предыдущий вопрос, найти здесь верные ответы не составит труда. Необходимо лишь убедиться, что и на Slave аналогичная настройка не выполнена. И правильный ответ будет найден:
· Включить на зоне безопасности Cluster обеих нод разрешение «Кластер»
После разборок с кластером командам предстояло разобраться в ряде ситуаций.
6. Пользователь Director из зоны безопасности Users решил поиграть в кибербезопасность и скачал на рабочий ПК ВПО. Почему потоковый антивирус не обнаружил атаку?
A. SSL-инспекция для данного трафика не настроена или находится в исключениях.
B. На NGFW UserGate нет лицензии для работы данного функционала.
C. Правило потокового антивируса требуется продублировать для обеих нод отказоустойчивого кластера.
D. Потоковый антивирус не включен для данного трафика.
Для начала проверим политику безопасности, связанную с фильтрацией контента. Находим такую, активную для всей зоны Users, включающей и пользователя Director:
Провалившись дальше, замечаем неактивную проверку потоковым антивирусом:
Казалось бы, ответ найден, но это еще не всё. Дополнительно следовало проверить политики SSL-инспекции и найти там пользователя Director в исключениях расшифровки:
Правильные ответы у нас в кармане:
· SSL-инспекция для данного трафика не настроена или находится в исключениях.
· Потоковый антивирус не включен для данного трафика.
7. Серверы из зоны DMZ не могут выйти в сеть Интернет для получения обновлений через зону Untrusted. В чём главная причина данной проблемы?
A. Правила для выхода в Интернет из DMZ написаны слишком широко, и поэтому NGFW такой трафик автоматически блокирует.
B. Отсутствует статический маршрут в Интернет.
C. Для доступа серверов в Интернет требуется динамическая маршрутизация с наивысшей Administrative Distance.
D. Зоны DMZ и Untrusted находятся в разных таблицах маршрутизации
E. Не настроена трансляция сетевых адресов (NAT).
Кажется, что ответ находится на поверхности — не настроена трансляция, поэтому и не работает. Но не всё так просто. Если мы заглянем в настройки маршрутизации, мы увидим, что port6 (зона DMZ) и port5 (зона Untrusted) находятся в разных таблицах маршрутизации (используются разные виртуальные маршрутизаторы), что является блок-фактором для прохождения трафика между ними:
Правильный ответ на этот вопрос:
· Зоны DMZ и Untrusted находятся в разных таблицах маршрутизации
Переходим к следующему вопросу — он был на внимательность:
8. В зоне безопасности Servers начал действовать botnet. Его IP-адреса известны и попадают в список ботнет-сетей вендора. По какой причине не происходит блокировка?
A. Правило не журналируется.
B. В правиле использована неправильная зона безопасности для идентификации трафика серверов.
C. Список C2-серверов используется в правиле некорректно.
D. К правилу прикреплено расписание, которое включит его только на следующей неделе.
Найти причину можно было в политике безопасности в соответствующем правиле:
Видим подозрительную зону 5ervers, заглянем в Зоны и найдём её там:
А здесь видно, что зона 5ervers не имеет ничего общего с реальной зоной Servers. Видимо, кто-то в спешке не заметил этот артефакт. Но большинство команд заметило.
Правильный ответ:
· В правиле использована неправильная зона безопасности для идентификации трафика серверов
9. В инфраструктуре AD-сервер используется в качестве LDAPS-коннектора, аутентификация по LDAP запрещена политикой информационной безопасности и соответствующим правилом на МСЭ. Но по какой-то причине LDAPS ни у кого из пользователей не работает, а LDAP в незашифрованном виде проходит. В чём причина происходящего?
A. В запрещающем правиле для LDAP в сервисе назначения указан 636 порт.
B. В разрешающем правиле для LDAPS в сервисе назначения указан 389 порт.
C. Правило должно иметь дополнительный критерий в виде сценария для проверки доступности LDAPS-сервера.
D. Для серверов зоны DMZ данный сервер недоступен по маршрутизации.
Порты LDAP(s) были указаны неверно. Как-то подозрительно просто, поэтому проверим еще несколько сценариев.
Проверив настройки маршрутизации (или воспользовавшись данными из вопроса №7) приходим к выводу, что интерфейс, относящийся к зоне DMZ, ошибочно помещен в отдельный VRF. По этой причине трафик не сможет попасть в зону Servers.
Правильные ответы:
· В запрещающем правиле для LDAP в сервисе назначения указан 636 порт.
· В разрешающем правиле для LDAPS в сервисе назначения указан 389 порт.
· Для серверов зоны DMZ данный сервер недоступен по маршрутизации.
10. Серверы из зоны DMZ пытаются получить доступ к корпоративному DNS-серверу. Разрешение по сервису DNS есть, но стандартный 53 порт не работает. Почему так происходит?
A. Сервис DNS содержит ошибочный порт назначения.
B. Трафик проходит по другому вышестоящему правилу.
C. Правило сохранено, но не применилось в базе данных. Для применения требуется нажать кнопку »Принудительно применить».
It’s always DNS! Смотрим настройки сервиса DNS и видим некорректно назначенный порт, что приводит к его неработоспособности.
Правильный ответ:
· Сервис DNS содержит ошибочный порт назначения
11. Укажите имя зоны c небезопасной конфигурацией доступа к управлению устройством.
В этом вопросе нужно было уделить внимание настройкам безопасности в зонах и определить, какая из «лишних» Консолей администрирования является небезопасной.
И правильный ответ здесь был связан с доступной для пользователей (зона Users) «админкой», что позволяет им пытаться получить доступ в панель администрирования UserGate NGFW. А так быть не должно.
Правильный ответ: Users
12. Укажите через запятую номера затененных правил межсетевого экранирования.
С этим вопросом многие команды не справились, указав в качестве затененных правила, которые были просто выключены:
Но здесь командам важно было найти правила, затененные не визуально, а логически: именно те, которые перекрываются вышестоящими в ACL. Такая ситуация может возникнуть, если более широкое правило находится выше более узкого. И таких правил в политике было два:
Как видно из конфигурации, оба эти правила перекрыты вышестоящими и в обработке трафика ни при каких условиях не участвуют — он попросту до них не доходит.
Правильный ответ: 13, 16
Завершающим вопросом раздела была конфигурация экспорта журналов во внешние сервисы.
13. Укажите причину, по которой в SIEM не долетают журналы UserGate NGFW.
A. Нет правил с включенным журналированием событий.
B. Не настроен экспорт журналов.
C. Трафик до SIEM попадает под «закрывающее» блокирующее правило NGFW (Правило №22).
Как видно из настроек в соответствующем разделе, правил для отправки событий в SIEM настроено не было:
Правильный ответ: Не настроен экспорт журналов
Теперь переходим к WAF!
Нужно было ответить на десять вопросов по конфигурации UserGate WAF версии 7.4.1.224707R. За ним находилось несколько защищаемых приложений из нашего виртуального города. Задания для UserGate WAF открывались в 10 утра. А с чего начинается УТРО? С кофе! Плавно переходим от реального кофе в виртуальную кофейню и наше первое задание. Погнали!
1. Сайт кофейни coffee.cyber.camp не работает. В чём может быть проблема?
Варианты ответов:
A. В «Global portal» -> «Reverse proxy servers» для кофейни coffee.cyber.camp установлен «Keep original source IP address» («Не изменять IP адрес источника») и трафик от сервера не возвращается на UserGate WAF.
B. В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «Real IP» не установлен «Get real IP» и в разделе «Trusted source» не добавлен ip-диапазон для клиентских устройств.
C. В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «Security profiles» не установлен «Enable Web Application Firewall feature» .
D. В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «General» неверно указан «Ports» .
Давайте запросим coffee.cyber.camp в браузере.
Получаем сообщение об ошибке «Powered by UserGate». Если раскрыть сообщение details, увидим: {shutdown,timeout}. Всё указывает на то, что нам пора заглянуть в графическую консоль UserGate WAF. Причём варианты ответа прямо явно указывают куда нам смотреть:
Правильный ответ: В «Global portal» -> «Reverse proxy servers» для кофейни coffee.cyber.camp установлен «Keep original source IP address» («Не изменять IP адрес источника») и трафик от сервера не возвращается на UserGate WAF.
Не возвращается, потому что сервер веб-приложения кофейни отправляет ответ напрямую клиенту, который ничего про этот сервер не знает, так как клиент отправлял запрос к UserGate WAF, а не напрямую серверу. Получаем подходящий и, как выясним дальше, единственно правильный вариант. Обратите внимание, что мы получаем именно timeout, а не econnrefused, который бы подошёл для неправильного варианта:
В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «General» неверно указан «Ports».
Заметь это, и вам бы не пришлось выяснять это в логах. Что же на счёт других вариантов?
В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «Real IP» не установлен «Get real IP» и в разделе «Trusted source» не добавлен ip-диапазон для клиентских устройств.
Вот сама вкладка «Real IP»:
Действительно ничего не настроено? Но надо ли? Если вы немного знакомы с WAF — то знаете, что не надо. Эта настройка позволяет передавать реальный ip-адрес клиента самому веб-приложению в заголовках HTTP. Без этой настройки приложение будет считать, что клиентом является сам UserGate, и будет работать, хоть и не совсем корректно, но WAF точно не будет отдавать timeout. Кстати, обычно используют X-Forwarded-For (или коротко в произношении XFF) или X-Real-IP.
Остался последний вариант:
В «Global portal» -> «Reverse proxy rules» для кофейни coffee.cyber.camp во вкладке «Security profiles» не установлен «Enable Web Application Firewall feature».
Профиль-то установлен, то есть вариант неправильный.
Это был прямой путь, но многие из вас заметили, что кроме coffee.cyber.camp есть dev.coffee.cyber.camp, настройки которого идентичны, за исключением «Keep original source IP address». При этом dev.coffee.cyber.camp работает и позволяет найти «нежный кофейный напиток с большим количеством молока и воздушной пенкой, дарующий возможность отклонять созвоны!».
2. Магазин уязвимостей!
При расширении бизнеса Магазина уязвимостей shop.cyber.camp менеджер столкнулся с проблемой при подключении новых позиций. При переходе на страницы сотой или сто первой уязвимости появляется страница с блокировкой от UserGate WAF. Найдите причину блокировки.
A. В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом CMAK.
B. В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом CKAM.
C. В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом MAKC.
D. В профиле Магазина уязвимостей включен слой Buffer Overflow, в котором используется ограничение на размер id.
E. В профиле Магазина уязвимостей включен слой Directory Indexing, в котором используется ограничение на размер id.
F. В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом MACK.
На WAF-ах давно можно настраивать контроль бизнес-логики, и UserGate не исключение. Контролировать можно и примитивные последовательности шагов — сперва зайди в корзину, а потом на страницу оплаты, и более сложные сценарии. Как правило, это настраивается на WAF’ах «ручками» администратора. Вот и здесь явно настроено ограничение на «переход» на сотую или сто первую страницу. Особо долгого исследования приложения не требовалось. Разве что для поиска пасхалочек. Идентификатор id действительно был и передавался, например, в строке URL из браузера. Здесь было два пути, и как обычно начнём с пути «в лоб». Вижу варианты ответа — проверяю каждый!
В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом MACK
Неверный! Layer-то добавлен, но выключен!
В профиле Магазина уязвимостей включен слой Directory Indexing, в котором используется ограничение на размер id
В Layer есть четыре правила из OWASP top 10, два на CVE и ещё два, не имеющих отношения к нашим id. Последние два могли отнять время у упорного участника.
В профиле Магазина уязвимостей включен слой Buffer Overflow, в котором используется ограничение на размер id
А он пустой! Правил в нём нет :) и ограничений тоже!
В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом MAKC
Сразу видно, что данное правило разрешает что-то связанное с мобильными номерами и почтами, а не запрещает — значит, неверный вариант.
В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом CKAM
Достаточно простое правило, которое, судя по синтаксису — смотрите на скриншот — не подходит. Заголовков бывает, конечно, и около 40, но у нас было намного меньше. И никак не ровно 60.
Перед переходом к правильному ответу зацените варианты для типов уязвимостей.
const severities = ['critical', 'high', 'medium', 'low'];
const types = [
'Remote Code Execution',
'SQL Injection',
'Cross-Site Scripting',
'Солидный bypass с LFI',
'Bypass комплексных WAF с <3',
'Найденное в экспериментальном веб мониторинге',
'Buffer Overflow',
'Privilege Escalation',
'Authentication Bypass',
'Information Disclosure',
'Directory Traversal'
];
Мы оставили три необычные версии — ведь парсить и декодить больше трёх раз не любят даже PROфессионалы. Тыкая на кнопки, можно было получить что-то весёлое!
В профиле Магазина уязвимостей добавлен Layer с пользовательским правилом CMAK
Самый смак написать регулярку на id в URL и чтоб она отрабатывала. Для тех, кто хочет копнуть поглубже — ваши запросы, которые подходят под строчки, кроме последней — пропускаются. В том числе, когда вы запрашиваете GET-ом страницу с id в диапазоне от 0 до 99 или через js пытаетесь выгрузить аналогичную инфу через API и прочее.
Конечно, так решали единицы, большинство участников, знакомых с WAF, пошло в Dashboard. И там ответ можно было получить очень легко — запросив id больше сотни. Мы оставили вам возможность увидеть результат сработки правила и его имя. Это нам обеспечила директива rule_log(yes) в правиле.
Большинство разработчиков WAF под Dashboard понимают то, что в интерфейсе есть раздел под названием Attacks (Атаки). Раздел Dashboard (Приборная панель) больше напоминает мониторинг и позволяет посмотреть текущее состояние WAF, его загрузку, объемы трафика, проходящего через WAF, работу систем фильтрации, статус лицензии. Не путаемся!
Чтоб не допускать досадных ошибок, нужно ходить в школу :) К ней и переходим
3. В студенческом приложении школы CyberCamp можно пообщаться с экспертами в режиме on-line. Однако Компот натворил бед, пока играл с мышкой — теперь страница школы открывается, но чат не работает. Что же понажимал Компот в графическом интерфейсе UserGate WAF?
A. Активировал настройку Block WebSocket traffic.
B. Удалил WAF профиль для школы.
C. Удалил reverse proxy rule для школы.
D. Снял галочку с Enable a WebSocket connection protection в Reverse proxy rule configuration.
E. Удалил все Sec-WebSocket-Extensions в профиле школы.
F. Удалил все Sec-WebSocket-Protocols в профиле школы.
Да, да многие сразу поняли, что раз не работает чат — значит, косяк с ws, то есть WebSoсkets! Так и есть. Правильный ответ: Активировал настройку Block WebSocket traffic.
Эта настройка находится в профиле школы CyberCamp в «Security Policy» -> «WebSocket profiles». Провалившись в DevTool, можно было убедиться, что используется ws, точнее «должен использоваться», но он блокируется на WAF.
Варианты с «удалил» профиль или reverse proxy rule неверные, так как и то, и другое не удалено. Заголовки Sec-WebSocket-Extensions и Sec-WebSocket-Protocols не используются и поэтому не настроены. Здесь можно было потратить время, решая прямо.
Ну, и последний неправильный вариант:
Снял галочку с Enable a WebSocket connection protection в Reverse proxy rule configuration
Не снял, поэтому вариант неверный.
Опять же, решить можно было проще, обратив внимание на аналог dev.school.cyber.camp. Если запросить его в браузере, то он открывался, и чат там работал и демонстрировал отсылку к одному известному мультику.
Отличие в настройке было в Block WebSocket traffic. Ох, уж этот кот Компот и его лапки!
4. Заболевший администратор пытался завести ГИС «Com-poRt» com-port.cyber.camp за UserGate WAF. Проанализируйте настройки и найдите, на чём остановился администратор
A. В разделе UserGate WAF -> Certificates загружен ГОСТ сертификат от тестового сервера, а не com-port.cyber.camp
B. В разделе Libraries -> SSL Profiles выбранные Ciphers suites не поддерживают выбранные SSL protocols
C. В разделе Global portal -> Reverse proxy rules для ГИС «Com-poRt» не выбран Security profile
D. В разделе Global portal -> Reverse proxy servers для ГИС «Com-poRt» не выбран пункт HTTPS to server
Взлом кошачьих кормушек? Не это ли искал Компот, когда сломал нам предыдущий сайт школы?
Намёк на то, что раз ГИС, то что-то не так с ГОСТ-ом, выкупили многие. Выбранные шифры поддерживали выбранные SSL-протоколы, пункт HTTPS to server выбран, да и Security profile выбран.
А вот сертификат действительно от тестового сервера, а не com-port.cyber.camp.
Чтобы не грустно было заходить на сайт, мы его наполняли, как могли — ведь это целая «Государственная информационная система постановки на кошачий учёт!». Тут и «Срочный вызов хозяев к миске», а чего стоит описание скрытого режима! Со всем этим можно было ознакомиться на Dev-версии приложения через обычный RSA.
Переходим к магазину косметики!
Заметили, что значки оказались не вписаны в кружки? Мы тоже, но вспомнив, что речь о косметике, решили, что коробка или упаковка всегда в разы больше самого товара/содержания, и оставили всё как есть!
5. От первой линии поддержки пришла жалоба на малонагруженный магазин косметики beauty.cyber.camp. Для защиты от атак конкурентов вы просили нового инженера завести его за UserGate WAF, но что-то пошло не так. Почему же магазин косметики не работает?
A. В политике магазина косметики добавлен пользовательский слой beauty_headers.
B. В политике магазина косметики добавлен пользовательский слой beauty_bad_ips.
C. В политике магазина косметики добавлен пользовательский слой beauty_categories.
D. В политике магазина косметики добавлен пользовательский слой beauty_mime.
E. В политике магазина косметики добавлен пользовательский слой beauty_SEO
F. В политике магазина косметики добавлен пользовательский слой beauty_qparam.
Мисконфиг в beauty_headers приводил к тому, что все GET-запросы блокировались. Косметику можно было посмотреть через dev.beauty.cyber.camp, но это было не обязательно.
Остальные слои (layers) выглядели так:
а слой beauty_SEO был выключен.
6. Какие действия логично сделать для защиты приложения mail.cyber.camp? Выберите один наиболее подходящий ответ:
A. В политике для этого приложения требуется написать пользовательский слой для защиты этого приложения.
B. В политике для этого приложения внутри системных слоёв требуется добавить технологию защиты Outlook Web Access.
C. Заводить данное приложение за UserGate WAF не имеет смысла, так как это не HTTP приложение.
D. В политике для этого приложения включить WAF слой Outlook Web Access.
E. Включить WAF профиль для Outlook Web Access.
Задача достаточно простая. Да, WAF обычно защищает OWA. Вопрос сводился к тому, чтобы найти в WAF, где эту защиту включить. Для сомневающихся при переходе на mail.cyber.camp открывался интерфейс, очень напоминающий OWA. А dev-версии не было, чтобы не сбивать с толку.
Правильный ответ был:
В политике для этого приложения внутри системных слоёв требуется добавить технологию защиты Outlook Web Access
Прийти к нему можно было либо поискав в руководстве администратора https://docs.usergate.com/waf-7x-rukovodstvo-administratora-610/, либо прощелкав интерфейс до нужной глубины:
Ломаем банк, задание 7!
7. При обращении к приложению банка bank.cyber.camp каждый запрос помечается атакой. Введите флаг вида 11111111-1111-1111-1111-111111111111 в слое, который приводит к такому поведению
0a4c08ba-081f-4abc-8868-e07e4bb39ccf
Наконец-то! Наконец-то мы узнали, зачем были эти комментарии «Something is here! c094be34-06b7-4eaf-8d61-e51241af910b»! Естественно, это флаг!
Задание предполагало просмотр самих слоев и правил:
и Dashboard для проверки своих доводов:
Правила в пользовательских слоях не обязательно что-то блокируют, могут и помечать.
Новая задачка и новая проблема №8.
8. Администратор ИБ хотел заблокировать доступ к веб-приложению через curl и завёл его за WAF. Политику безопасности настроили, но запросы curl по-прежнему проходят через WAF. Почему блокировка не сработала?
Домен приложения: http://cat.cyber.camp:8060
В политике переопределено действие по блокировке.
К профилю привязана неправильная политика.
Не выполнены критерии срабатывания правила.
Политика WAF не включена для опубликованного приложения.
Критерии срабатывания правила выполнены и в Dashboard есть сработки. Только вот Action у нас почему-то No action, а не Deny. Третий вариант не подходит и двигаемся дальше.
Политика к профилю привязана правильная и она включена. Ещё минус два неправильных варианта.
Действия можно переопределять в «политике», точнее, в профиле WAF. В этом и косяк, смотрим скриншот.
9. Администратор ИБ пытается защитить веб-приложение от SQL-инъекций с помощью политики WAF. Политику настроили и опубликовали, но атаки по-прежнему проходят. Почему не работает защита?
Домен приложения: http://studio.cyber.camp:8061
Сигнатуры SQL-инъекций отключены на уровне WAF.
Пользовательское правило исключает из обработки запросы к приложению.
Политика WAF настроена в режиме мониторинга и не выполняет блокировку атак на приложение.
Политика WAF настроена только на проверку POST-параметров, поэтому защита не срабатывает полноценно.
Сигнатуры SQL-injection включены и их Action выставлен в Deny, а не мониторинг. Минус два неверных ответа. Раз системные слои включены, то проверяются не только POST-запросы.
Остаётся найти слой с правилом, который исключает все запросы из обработки. При написании правил нужно быть аккуратным. В плохих случаях можно либо всё заблокировать, либо всё разрешить.
10. Администратор ИБ опубликовал веб-приложение за WAF и ожидал, что система защитит его от атак класса HTTP Response Splitting. Однако, ознакомившись с отчётом по проведённому пентесту приложений, он узнал, что такие атаки всё же успешно выполняются, а WAF их не блокирует. Почему WAF не сработал?
Домен приложения: http://bakery.cyber.camp:8062
Политика WAF не была применена к нужному приложению.
В политике не включен WAF-слой HTTP Response Splitting.
Внутри WAF-слоя HTTP Response Splitting не выбраны все технологии, которые использует приложение, из-за чего все атаки проходят.
В наборе сигнатур для HTTP Response Splitting не задано действие.
Пойдем жарить в bakery! Видим, что политика применена, а значит — минус один неправильный вариант ответа.
В профиле WAF включен Response Splitting, минус второй неправильный. Внутри WAF-слоя HTTP Response Splitting выбраны все технологии, минус третий неправильный. А вот Action выбран No action, причём это сделано не в самой политике для bakery, а в наборе сигнатур. То есть для тех профилей, в которых действие не переопределено внутри, будет действовать No action.
Что это было?
Задание наглядно показало: даже самые современные СЗИ не спасут, если конфигурация содержит ошибки.
Заработав 142,33 балла, лидером в корпоративной лиге стала команда CITRUS. Они справились с заданием за 170 минут. В студенческой лиге первое место заняла команда EXE.1sior – у них 110,96 баллов и 129 минут. Поздравляем, вы лучшие!
«Осторожно, злой WAF»
Задание от «Код Безопасности»
Количество баллов: 150
Время на выполнение: 60 минут
Что случилось?
Что делать?
Изучите политику на Континент Web, выявите её слабые места и найдите флаги на защищаемом приложении.
Действуем!
Континент Web встречает нас веб-интерфейсом:
Любая защита WAF-ом начинается с настройки проксирования ресурса. Переходим в «Ресурсы» и посмотрим, что настроил админ.
Видим два ресурса: «dev.cookieshop.cyber.camp» и «cookieshop.cyber.camp». Проверим, работают ли они.
А вот и первый флаг. Это было слишком просто.
Dev-зона оказывается просто статичной страничкой. Пойдем к основной к странице.
Тут уже больше различных активностей. Кнопка «Я готов», «Ты точно не робот?», зона, отражающая текущие Cookies, и «?».
Рассмотрим каждую поближе. «Я готов» генерирует какой-то POST запрос и, судя по отсутствию полезной нагрузки, этот POST без тела.
И хоть RFC7231 не запрещает такого поведения, но это считается плохой практикой и рекомендуется к блокировке, что, в общем-то, мы и видим.
Что ж, записали, пошли дальше.
«Ты точно не робот?» — вероятно, какая-то версия капчи. А, нет, банальный переход на другую страницу.
И сразу блокировка, значит, есть какая-то проверка. Пока с ней ничего не сделать. Пойдем дальше.
Блок текущих Cookies. Секретов, на первый взгляд, не видно, вероятно, действительно считывает и выводит текущие куки.
«?». Снова перенаправление, но на этот раз на phpinfo. Возможно, осталось с отладки, а может, подсказка.
Хм, стандартный phpinfo, но версия скрыта силами WAF. Однозначно, это неспроста…
С анализом приложения покончено. Намечены пути дальнейшего движения:
Блок пустого POST запроса.
Зачем показывать мои текущие Cookies.
Блок на api-gateway.php.
Скрытая версия php.
Посмотрим, что в политике безопасности на WAF-е. Настроен один профиль WAF, в котором для ресурса cookieshop.cyber.camp применяются два анализатора.
Блок пустого POST явно должен быть в «Валидации HTTP», ведь это отклонение от стандарта HTTP. Поэтому начнем с него.
Действительно, видим слайдер «Блокировать POST/PUT/PATCH запросы без тела». Пощелкаем по вкладкам, может, есть что интересное.
Выглядит, как будто все настройки по умолчанию.
На защищаемой странице есть поле с текущими куками, наверное, стоит обратить внимание на вкладку Cookies.
Итак, в «Основных параметрах» POST без тела запрещен, но, судя по функционалу сайта, отправить его всё-таки нужно. Посмотрим в «Специальные настройки».
Отлично, видимо, они применяются только для URL /flag-admin.php. И на этот раз «пустой» POST разрешен.
Переходим на URL и берем флаг по кнопке.
Также сравним значения в других вкладках для этого URL.
В Cookies разрешен символ %. Небезопасно, сможем применить URL-encode. Попробуем отправить запрос с кукой, в которой будет знак %. Можно через Burp, а можно и прямо в браузере.
И обновим страничку. «Окак»!
Блок пустого POST запроса.Зачем показывать мои текущие Cookies.Блок на api-gateway.php.
Скрытая версия php.
В политике у нас остался «Сигнатурный анализатор».
Много сигнатур от вендора, пользовательские сигнатуры, исключения... Анализ каждой явно не наш путь, пойдем сразу в «Специальные настройки».
Ага, а вот и api-gateway.php.
Хм, регулярка на блокировку. Блокировать запрос, если в заголовках запроса нет совпадения с регулярным выражением.
Читается жирнейший намек на User-Agent: curl. Вперед в терминал!
Итак, осталась скрытая версия PHP. Анализаторы проанализированы, где же искать? Часто в WAF-ах есть функционал подмены отдельных значений в трафике «на лету». Посмотрим детально, как заведено проксирование.
А вот и подмена. Значит, версия PHP 7.1.33.dev. Но, очевидно, что это не флаг, он не подходит по маске и количеству символов.
Почему могут прятать значение версии? Может быть, она уязвима? Да и в описании флага сказано про «уязвимую версию ПО».
Похоже, нас ждет RCE CVE-2019-11043. Поищем эксплоит, потому что Metasploit — это слишком просто. Пара минут поиска в сети, и вот мы имеем эксплоит на питоне с гитхаба.
Ctrl+C -> Ctrl+V, стартуем атаку.
Подставляем наш URL.
Веб-шелл ждет нас на указанном URL.
А вот и flag. Читаем, забираем.
Что это было?
Задание продемонстрировало, что WAF — это не «стена», а сложная система правил, где даже мелкая ошибка в конфигурации может открыть путь к полной компрометации.
Максимальный результат (110,74 баллов) в корпоративной лиге показала команда Vostok343, которая справилась с заданием за 111 минут. В студенческой лиге первое место заняла команда EXE.1sior – 83,81 баллов и 74 минуты на выполнение. Молодцы!
Итог
CyberCamp 2025 подтвердил: лучшее обучение — через практику. Участники не просто разгадывали «головоломки», а сталкивались с теми же задачами, что и в реальных SOC, AppSec и OT-командах. Если вы участвовали в CyberCamp – напишите, насколько вам было интересно решать задания и понравились ли они вам!