Разбор задач One Task

Что такое CTF и зачем белому хакеру решать задачи

CTF (Capture The Flag) это соревнование по информационной безопасности, где нужно найти уязвимость в задаче и достать флаг. Флаг это строка, которая подтверждает, что ты проэксплуатировал то, что заложил автор. По сути это та же работа пентестера (специалиста по тестированию на проникновение), только в миниатюре: ты видишь веб-приложение, оцениваешь его функционал, прикидываешь, где может прятаться уязвимый код, и строишь в голове киллчейн, то есть цепочку уязвимостей.

Каждая задача CTF это чья-то находка: автор однажды столкнулся с уязвимостью в продукте и упаковал этот опыт в задание.

Решая CTF, ты проходишь тот же путь, что и автор, включая анализ функционала и попытку разобраться построчно, почему место уязвимо.

Как решать CTF: методология важнее случайных payload'ов

Главная ошибка новичка в CTF это кидать во всё подряд кавычки и XSS, надеясь, что что-то сработает. Так задачи не решаются.

Сначала оценивается функционал, потом строится гипотеза, и только потом идёт проверка.

Каждая гипотеза должна быть обоснована. Это экономит часы: ты не проверяешь то, чего в этом функционале быть не может.

У тебя никогда не должно быть безумного решения. На любую гипотезу отвечай на вопрос, почему уязвимость именно здесь: если видишь лендинговый сайт, SQL-инъекции тут обычно нет, и искать её незачем.

Никита Коломиец

Алгоритм решения CTF-задачи в девять шагов

Алгоритм решения CTF удобно держать в голове как простой порядок действий:

Авторы часто оставляют подсказку в условии, иногда почти прямым текстом говорят, где уязвимость. Категория часто подписана в самой задаче (web и так далее), класс подсказывает функционал, а сбор информации это часть разведки: какие библиотеки могли использоваться и что вообще происходит. На каждую гипотезу отвечай, почему она возможна, быстрые проверки начинай с самых распространённых payload'ов и развивай тот путь, где реакция сервера на payload отличается от обычной.

Небезопасная десериализация Pickle в Python: выполнение команд

Первая задача: приложение использует pickle, нужно добиться выполнения команд и прочитать флаг в корне файловой системы. Pickle это библиотека Python для сериализации. Сериализация это превращение объекта в передаваемое представление, например в байты, а десериализация это обратный процесс. Представь класс "машина" с полями модель, цвет, год: чтобы передать такой объект строкой, его сериализуют, а чтобы собрать обратно, десериализуют.

Как только видишь pickle, в связке сразу всплывает популярная уязвимость: небезопасная десериализация. Payload строится через класс с методом __reduce__, который возвращает os.system и строку с командой. Pickle упаковывает это в бинарное представление, а на стороне сервера при десериализации команда выполняется. Готовую заготовку берут из репозитория PayloadsAllTheThings, подставляют свою команду (например whoami) и кодируют в base64.

Слепая уязвимость: out-of-band и Burp Collaborator

Если отправить payload и в ответ прилетает только пятисотка, это слепая уязвимость: результат команды ты не видишь. Выход это out-of-band, когда команда делает запрос на твой внешний сервер. В Burp для этого есть Collaborator: поднимаешь его, меняешь команду на ping до адреса коллаборатора и смотришь, пришёл ли запрос. Опенсорсный аналог это Interactsh от Project Discovery.

Дальше можно вытаскивать флаг. Прямой путь это cat /flag, но фигурные скобки запрещённый символ в доменном имени, поэтому их вырезают через tr. Надёжнее поднять на своём сервере netcat на отдельном порту и отправить содержимое файла туда напрямую, тогда ограничения на символы снимаются.

Type juggling в PHP: обход авторизации через нестрогое сравнение

Во второй задаче нужно обойти авторизацию, а перед тобой исходник на PHP, и его нужно уметь читать. Знать язык целиком необязательно, незнакомые функции достаточно прогуглить. Логика простая: из POST декодируется JSON, проверяется, что логин равен нужному значению, и что strcmp пароля возвращает 0, то есть строки совпали. Угадать одновременно и логин, и хэш пароля звучит безнадёжно, поэтому слабость ищут в самих сравнениях.

PHP печально известен нестрогим сравнением. При двойном равно булево true, сравниваемое со строкой, всегда даёт true, так что в поле логина можно передать 1 или true и пройти первую проверку. Со strcmp своя беда: если вместо строки передать массив, функция возвращает не число, и сравнение с нулём проходит. Через JSON это выглядит как передача пустого массива вместо хэша. Так авторизация обходится целиком.

Рядом стоит вспомнить про magic hashes: это когда разные значения дают один и тот же хэш, то есть у функции происходит коллизия. В боевых версиях приёмы вроде strcmp-байпаса встречаются редко, но знать их полезно.

XXE-уязвимость: чтение файла через внешний DTD

Третья задача без подсказок. В Burp видно, что приложение отправляет XML.

Как только видишь XML, первым в голову должна приходить XXE-уязвимость (XML External Entity).

Через XXE можно читать локальные файлы и делать SSRF.

Здесь уязвимость тоже слепая, и простой out-of-band содержимое файла не отдаёт: внешняя сущность не подгружается. Рабочий путь это связка из двух сущностей во внешнем DTD-файле. Одна сущность читает файл (flag.txt), вторая подставляет его содержимое в запрос к твоему серверу. DTD кладёшь на свой сервер и поднимаешь рядом python3 -m http.server на нужном порту. Когда приложение обрабатывает XXE, оно скачивает твой DTD, читает флаг и само отправляет его тебе. Без собственного сервера задача по сути не решается: DTD негде разместить так, чтобы приложение его забрало.

PayloadsAllTheThings, HackTricks и собеседование пентестера

Почти все заготовки для CTF-задач лежат в двух местах: репозиторий PayloadsAllTheThings и HackTricks. Последний это большая база знаний. Payload'ы оттуда часто приходится чуть править под конкретный стенд, но основа готова.

Любой payload нужно разбирать, а не копировать вслепую.

Если находишь готовый payload, обязательно разберись, как он работает. Иначе, когда уязвимость точно есть, а раскрутить её не получается, ты просто не поймёшь, что сделал не так.

Никита Коломиец

Методология приходит из практики. База у всех похожая: разведка плюс поиск уязвимостей, а дальше наработка на пробах и ошибках. На собеседовании пентестера хорошо упомянуть WSTG как методологию и понимать, что такое CVSS.

Лучший твой друг это практика. Нарешиваешь много, и в моменте начинает попадаться похожая уязвимость, за которую проще зацепиться: в голове уже отложилось, что здесь такое было.

Никита Коломиец

Пентест на практике: скорость, брут, частые уязвимости и WAF

Скорость решения это не показатель мастерства.

Скорость важна только на соревнованиях вроде Standoff 365, где нужно быстрее реализовать критическое событие. В настоящей работе пентестера гонка только мешает: торопясь, легко пропустить зацепку и поставить себе блокер на всё дальнейшее решение.

Брут на CTF обычно не нужен: задача про интересную уязвимость, а не про перебор паролей. Максимум короткий дефолтный словарь. На боевых проектах перебор упирается в другое: приходится ограничивать число запросов в секунду, большая инфраструктура в тысячи хостов перебирается долго, а брут при включённом файрволе быстро приводит к бану. Работать надо аккуратно, чтобы не положить инфраструктуру заказчика.

Чаще всего встречаются IDOR (перебор идентификаторов), HTML-инъекции и XSS, если проект без React. SQL-инъекции зависят от проекта и попадаются реже. Отдельная категория это уязвимости бизнес-логики. Для обхода WAF payload кодируют и запутывают так, чтобы файрвол не смог его разобрать.