Драйвера Windows - источник зла

DigitalScream

Xakep, номер #062, стр. 062-068-3

Первое, что необходимо определить – какие процессы запускает приложение, к чему обращается и т.д. Немного покопав Process Viewer’ом, можно выйти на след библиотеки VSMON.DLL. В диспетчере задач сразу бросается в глаза то, что она имеет права системы. Нетрудно догадаться, что это сервис, и, скорее всего, именно он и общается с драйвером.

Все сомнения по поводу правильности этой теории исчезают, как только заглядываешь в панель управления. В разделе Администрирование -> Службы необходимо отыскать имя этой библиотеки, после чего в ее свойствах перейти на закладку зависимости. Можно увидеть, что она зависит от какого-то компонента vsdatant. Это и есть тот самый драйвер, использующий Zone Alarm для контролирования сетевой активности приложений.

Второй способ – использование API мониторинга. Дело в том, что для подключения к устройству (имеется в виду драйвер, а не физическое устройство) используется функция CreateFile. А поэтому, отлавливая ее вызовы для определенного приложения, можно узнать, к какому именно устройству оно подключается.

Для обращения к драйверу следует использовать UNC стандарт. Это значит, что при вызове функции CreateFile, в качестве имени файла необходимо указать \\.\vsdatant. Хочу заметить, что удаленное подключение к драйверам невозможно, поэтому атака относится исключительно к локальным.

Следующий этап для атакующего - определение поддерживаемых драйвером операций. Для этого следует воспользоваться API монитором. Его нужно направить на Zone Alarm, причем включить в настройках фильтра только функции для работы с файлами и драйверами.

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

После нескольких минут анализа собирается следующая инфа:

Появившаяся инфа

dwIoControlCode:0x8400000f,

lpInBuffer:0x17a3e3,

nInBufferSize:27,

lpOutBuffer:0x12ee06,

nOutBufferSize:4,

lpBytesReturned:4,

lpOverlapped:0

В этом случае можно предположить, что злоумышленник, используя функцию 0x8400000f, может контролировать 4 байта (переменная nOutBufferSize), передавая на драйвер какие-то данные (структуры).

Чтобы убедиться в правильности догадок, следует дизассемблировать программный код драйвера и посмотреть, каким образом производится обработка полученных структур. В качестве дизассемблера можно выбрать IDA, поскольку он обладает наибольшим количеством встроенных функций и имеет ряд дополнений.

Уже известно, что устройство обрабатывает функцию 0x8400000f, а это значит, что в IDA следует искать именно ее. Для этого нужно воспользоваться поиском (ALT + T).

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