Дополнительные главы практической безопасности (2021)/Домашнее задание по фаззингу: различия между версиями

Материал из SecSem Wiki
Перейти к навигации Перейти к поиску
(Задача)
(Задача)
Строка 88: Строка 88:
  
 
Для сдачи задания вам нужно прислать тест-триггер уязвимости и описание, как высокоуровнево устроен бекдор, на [mailto:vient@seclab.cs.msu.ru мою почту]. С вопросами по поводу дз можно писать мне в телеграм @vient.
 
Для сдачи задания вам нужно прислать тест-триггер уязвимости и описание, как высокоуровнево устроен бекдор, на [mailto:vient@seclab.cs.msu.ru мою почту]. С вопросами по поводу дз можно писать мне в телеграм @vient.
 +
 +
'''Дедлаин по этой задаче: 16 мая 23:59:59'''

Версия 12:57, 8 мая 2021

Домашнее задание по фаззингу

Первый семинар

Задача

http://fuzzing.tasks.course.secsem.ru/

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

Исследуемый продукт: GtkVNC — клиент для приложений доступа к удалённого экрану, которые используют протокол RFB. RFC на протокол

Для того, чтобы начать искать уязвимости достаточно сделать это...

Правила игры: Чем больше уязвимостей Вы найдёте в проекте — тем лучше. Сколько уязвимостей — неизвестно, но они есть. Если Вы — первый человек, кто нашёл уязвимость данного типа, то мы вместе непублично репортим уязвимость вендору и регистрируем на Вас идентификатор CVE. Уязвимости, которые приводят к возможности получения удалённого доступа на клиенте оцениваются выше, чем уязвимости, которые приводят к падению клиента (RCE круче, чем DoS). Уязвимости искать руками тоже можно не используя фаззинг, это не будет контролироваться.

Для того, чтобы подтвердить, что вы действительно нашли уязвимость вам необходимо будет написать минимальный Proof-of-Concept, который необходимо будет сдать в проверяющую систему. Проверяющая система будет запускать ваш PoC и тестировать, что бинарный пакет gtkvnc, скомпилированный с AddressSanitizer выдаёт типичную для ASAN-a ошибку. Если уязвимость, которую вы нашли не триггерит ASAN, но является уязвимостью (например это ошибка неинициализированной памяти, которую клиент удалённо может считать), то пишите в телеграмм paulchr . Такие уязвимость тоже буду засчитаны.

Прежде, чем посылать эксплоит на сервер рекомендуется убедиться, что вы можете получить ошибку локально, подключившись при помощи клиента GtkVNC, который скомпилирован с библиотекой ASAN. После того как вы убедились в этом, посылайте ваш PoC на сервер. Для этого надо зарегистрироваться на нём, выбрать "Targets" -> "GtkVNC" и загрузить скрипт на сервер. Запускаться он будет через ./poc, так что не забудьте шабанг.

Если PoC успешно пройдёт проверку, то он будет переведён из состояния "in progress" в состояние "success", иначе он перейдёт в состояние "failed". Таймаут работы — одна минута, но если вашему скрипту нужно больше времени на работу, чтобы стриггерить уязвимость, так как он, например, посылает много данных, то это поправимо (пишите в телеграмм). Если после загрузки файла на сервер ваш PoC завис в состоянии "in progreess", "created" или "internal error", то пишите в телеграмм, скорее всего что-то сломалось и я постараюсь это почитать как только так сразу. Система тестируется на людях в первый раз.

Если ваш PoC перешёл в состояние success, то поздравляю, вы стриггерили уязвимость, но это не конец. Для успешного завершения упражнения Вам необходимо написать репорт в проверяющую систему где вы опишете подробно насколько это возможно уязвимость и последствия для программы, к которым она приводит. Описание отправляется на ревью (состояние "on review") и может быть отклонено администраторами системы, если репорт был плохо написан. Примеры таких возможных случаев: причина уязвимости была неверно истолкована или непонятно изложена, импакт данной уязвимости был определён неверно, ваш PoC написан не достаточно понятно или обфусцирован или был загружен бинарный исполняемый файл. В таком случае Ваш submission отправляется в состояние "rejected". Если Вы первым смогли стриггерить данную уязвимость, но плохо написали репорт, и человек после Вас получил успешный статус "success", то он будет считаться первым успешно выполнившим задание, а следовательно, будет претендовать на получение идентификатора CVE, даже если Вы потом успешно заново сдали данную уязвимость.

В окружении в котором будет запускаться ваш PoC есть питон3 и библиотека pwntools. Подробнее об устройстве PoC контейнере

Делиться информацией о найденных уязвимостях ни с кем категорически нельзя до конца задания!

Дедлаин по этой задаче: 16 мая 23:59:59

Вспомогательные материалы

FAQ по домашке

  • Что делать если "Internal Error"?

Писать в чат в телегремме. На сервере иногда случаются докер-проблемы, но всё что отработало с "Internal Error" будет перепроверено и засчитано.

  • Почему мы откатываемся на какой-то коммит? Неужели ты нас обманул и мы ищем уже запатченные уязвимости?

Нет, на коммит я откатился, потому что на нём я тестировал свой фаззер и вместе с ним сбилжен тестовый билд с ASAN-ом на котором проверяются ваши эксплоиты. Соответственно вам тоже удобнее будет тестировать не на последнем коммите, потому что если в проекте с тех пор появились какие-то обновления, то они могут помешать и вы не поймёте что случилось.

  • У тебя там тестируется всё локально, поэтому я могу наверное как-то обмануть проверяющую систему и мне засчитается submission?

Скорее всего это не получится. Контейнеры, в которых запускаются ваш PoC и уязвимый бинарь, изолированы друг от друга и от общей докеровской сети. Кстати, в связи с этим будьте внимательны: ваш PoC должен слушать порт 5900 не на 127.0.0.1, а на 0.0.0.0

  • Экслоит не работает. Что делать?

Сбилдить указанный коммит с ASAN-ом и проверить руками свой пок.

  • Эксплоит работает локально, но не работает удалённо. Что делать?

Проверьте различные проблемы. Проверьте, что первой строчкой в вашем поке идёт шебанг. Вы используете питон версии 3. Ваш пок не использует лишних библиотек. Если вы сидите на винде, то замените все переводы строк с CRLF на LF. Если всё это не работает, то пишите в чат в телеграмме.

  • Что должен содержать минимальный репорт?

Подробное описание где конкретно проижошла уязвимость с именами файлов, функций и номерами строк. Что привело к уязвимости: понятное и точное описание с именами переменных. Импакт от данной уязвимости. Может ли данная уязвимость привести к возможности удалённого исполнения кода. Если для этого будут требоваться другие уязвимости, то написать какие именно (например, memory leak). Если при описании импакта Вы не уверены на 100%, то можно написать об этом. Идентификатор CWE.

  • Где создать репорт?

После того, как ваш PoC отработал со статусом "success" кнопка "Create Report" будет находиться на полной странице вашего submission_a. Там же впоследствии появится комментарий проверяющего после ревью.

Второй семинар

Третий семинар

На третьем семинаре мы говорили о фаззинге бинарных программ на уровне ядра.

Задача

Дан небольшой ядерный модуль для Linux 5.4.0-72 (такое ядро есть, например, на полностью обновлённой Ubuntu 20.04). Его можно загрузить с помощью команды insmod. Модуль реализует простейшее устройство, принимающее файл конфигурации и возвращающее значение параметра из него. Для взаимодействия с ним можно создать устройство в файловой системе: после insmod посмотрите в выводе dmesg, какой "major device number" получило устройство test. У меня этот номер равен 241, дальше буду использовать его. Для создания файла устройства выполните команду mknod /dev/test c 241 0. После этого с модулем можно общаться через файл /dev/test. Для примера, сделайте echo '{"param1": "123456"}' > /dev/test && head -c 6 /dev/test.

В модуле есть "закладка", вам предлагается найти её с помощью фаззинга. Скачайте kAFL (официальный репозиторий располагается тут, но я советую использовать мою ветку ip_decoder_fix отсюда): git clone https://github.com/vient/kAFL && cd kAFL && git checkout ip_decoder_fix. После этого воспользуйтесь мануалами и документацией для подготовки окружения и фаззинга. Обратите внимание, что kAFL не будет работать в виртуальной машине!

Для сдачи задания вам нужно прислать тест-триггер уязвимости и описание, как высокоуровнево устроен бекдор, на мою почту. С вопросами по поводу дз можно писать мне в телеграм @vient.

Дедлаин по этой задаче: 16 мая 23:59:59