Итак, мы уже разобрались с фаззингом файлов, протоколов — теперь попробуем использовать фаззинг для поиска ошибок в драйверах. Тут надо понимать, что драйверы используются не только для управления устройствами, вовсе нет. Многие программы устанавливают в систему драйвер в качестве посредника для доступа в более привилегированный режим — Ring0. Прежде всего, это антивирусы и утилиты, обеспечивающие (по крайней мере, обещающие обеспечить) безопасность системы. Драйверы, в общем, ничем не отличаются от программы в плане безопасности: как и везде, большое количество уязвимостей связано с неправильной обработкой данных, в особенности тех, что поступают в IRP-запросах. I/O request packets (IRP) — это специальные структуры, использующиеся моделью драйверов Windows для взаимодействия и обмена данными драйверов друг с другом и самой системой. Получается, и здесь есть все условия для того, чтобы автоматизировать поиск уязвимостей. Конечно, инструмент тут нужен совершенно особенный, потому как обычным фаззерам доступ в недра системы закрыт.
Одна из немногих разработок в этой области — IOCTL Fuzzer, которая изначально нацелена на проведение fuzzing-тестов, манипулируя с данными в IRP-запросах. Программа устанавливает в систему вспомогательный драйвер (не удивляйся, что подобную активность антивирус посчитает подозрительной), который перехватывает вызовы NtDeviceIoControlFile, тем самым получая возможность контролировать все IRP-запросы от любого приложения к драйверам режима ядра. Это нужно потому, что изначально формат IRP-запроса для конкретного драйвера или программы неизвестен. А имея на руках перехваченный IRP-запрос, его можно легко изменить — получается классический фаззинг с помощью мутации. Проспуфенный IRP-запрос ничем не отличается от оригинального за исключением поля с данными, которые заполняется фаззером псевдослучайным образом. Поведение фаззера, лог-файл, названия драйверов для спуфинга и другие параметры задаются с помощью простейшего XML-конфига, который находится в корне программы. Но прежде чем рваться в бой, необходима некоторая подготовка.
Из эксперимента с драйверами на рабочей машине ничего хорошего не выйдет. Если IOCTL Fuzzer удастся нащупать слабое место в каком-нибудь из драйверов, то система легко улетит в BSOD, а это едва ли прибавит удобства для идентификации уязвимости :). По этой причине для использования фаззера нам понадобится отдельная виртуальная машина, к которой мы подключим удаленный дебаггер ядра. Тут честь и хвала Microsoft, которые не только смогли сделать толковый отладчик WinDbg, поддерживающий удаленный дебаггинг, но и распространяют его бесплатно. Взаимодействие между гостевой системой в VMware и удаленным отладчиком WinDbg осуществляется с помощью именованного канала (named pipe), который мы сейчас и создадим.
1. Сначала создаем именованный канал в VMware. Для этого переходим в меню "Settings „p Configuration Editor", нажимаем на кнопку добавить оборудование ("Add"), выбираем "Serial Port", жмем "Next", далее из списка выбираем тип порта — "Use named pipe" и оставляем дефолтное название для именованного канала (\\.\pipe\com_1). После этого задаем режим работы "This end is server. The other end is application" в двух выпадающих полях и напоследок нажимаем кнопку "Advanced", где активируем опцию "Yiled CPU on poll" (иначе ничего не заработает).
Осталось реализовать возможность загрузки гостевой системы с включенным режимом удаленной отладки. Для этого в boot.ini (будем считать, что в качестве гостевой системы используется Windows XP) необходимо вставить новую строку для запуска системы, добавив два важных ключа /debugport и /baudrate:
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional - Debug" /fastdetect /debugport=com1 /baudrate=115200
Во время следующей перезагрузки необходимо в загрузчике выбрать ту версию системы, для которой мы включили режим отладки. Остается настроить сам отладчик, но для этого нужно лишь во время запуска передать ему параметры именованного канала:
windbg -b -k com:pipe,port=\\.\pipe\com_1,resets=0
Вот теперь можно запускать IOCTL Fuzzer в режиме фаззинга, не опасаясь BSOD’а на основной системе. Выполняем произвольные манипуляции с тестируемым ПО до тех пор, пока отладчик не сообщит нам о возникновении необрабатываемого исключения (это значит, что в обычных условиях, скорее всего, это закончилось бы аварийным завершением работы системы).
Далее необходимо возобновить выполнение кода на виртуальной машине (в случае с WinDbg надо просто нажать F5), после чего ОС, работающая на виртуальной машине, запишет аварийный дамп (crash dump) на диск. Готово: теперь у нас есть подробные логи, дамп и сам запрос, который привел к падению. Дело за малым — понять, как это можно эксплуатировать :).