Как убить защитный драйвер в Windows

Когда-то, во времена Windows XP, почти все пользователи работали с правами админа. Исключения встречались в основном в корпоративном секторе.

Сейчас от такой практики отходят, но в реальности многие взломы так или иначе приводят к получению атакующим прав админа. Это может происходить в результате эксплуатации уязвимости, ошибок конфигурации софта, работающего с повышенными привилегиями, или банального перебора паролей. Получение атакующим прав админа на одной из машин в домене — это путь к контроллеру домена. Атакующий может, например, перехватить пароль доменного админа на одной из пользовательских машин (когда на нее зайдет сам админ), а затем залогиниться на контроллер домена.

Поскольку бизнес слишком медленно реагирует на такие угрозы (да и Microsoft те бреши, которые за уязвимости не считаются, закрывает очень долго), то некоторые производители начали реализовывать защиту от админа. Такая защита бывает в антивирусах (в виде модулей самозащиты), также есть отдельные продукты, предназначенные для защиты серверов и рабочих станций от действий «плохого админа».

Хорошо известно, что защиту на том же уровне привилегий реализовать можно только через усложнение (security through obscurity), поэтому для защиты от программ, работающих с правами администратора, то есть в ring 3, нужно применять драйвер, который работает в ring 0.

С помощью драйвера можно запретить определенные опасные операции с процессами, дисками, файлами и реестром.

Модули самозащиты антивирусов, как правило, препятствуют удалению или отключению антивируса, изменению его компонентов, изменению или удалению его конфигурации. Это реализуется при помощи перехвата функций API, изучения переданных им аргументов и блокирования опасных операций (путем возврата ошибки без вызова перехваченной функции). Например, перехват функции удаления ключа реестра должен блокировать удаление ключа реестра, если этот ключ относится к антивирусу (ведь антивирус можно отключить, если удалить записи о его сервисах, — в таком случае при следующей загрузке операционной системы антивирус не запустится).

Самозащитой антивирусов, конечно, дело не ограничивается — существует продукт, позволяющий гибко настроить ограничения для программ, в том числе работающих с правами админа. Этот продукт называется Symantec Data Center Security (DCS).

DCS предназначен для защиты главным образом серверов. В его функциональность входит защита сервисов, работающих с повышенными привилегиями, защита операционных систем после окончания их поддержки, мониторинг целостности файлов, защита от эксплоитов. Также этот продукт реализует некоторые функции хостовой IDS/IPS.

Symantec DCS позволяет задавать гибкие правила для каждой программы (далее в статье будет говориться про версию Data Center Security Server Advanced 6.7.2.1390 этого программного решения). Например, можно запретить одной программе читать какой-то файл, но разрешить чтение для другой программы (при том, что обе программы работают с правами админа). Или запретить модификацию определенного файла всем программам, кроме заданной. И так далее, вплоть до настройки разрешений для ключей реестра и узлов, с которыми допускается сетевое взаимодействие. Гибкость настройки правил разграничения доступа впечатляет! При этом, кстати, поддерживаются общие наборы правил, то есть безопасник не попадет в трясину настройки правил для каждого экзешника.

Следует отметить, что перечисленные ограничения не основаны на дескрипторах безопасности Windows, вместо этого на уровне драйвера реализуется собственный механизм разграничения доступа.

В ходе тестирования было установлено, что Symantec DSC успешно защищает от прямого чтения данных с диска (попытка такого чтения завершается с ошибкой), от mimikatz и от некоторых других популярных векторов рекогносцировки и распространения по сети. Мечта безопасника, казалось бы…

Немного о защитном драйвере

Из-за PatchGuard почти все производители защитных средств опираются на официальные способы перехвата функций. Для реестра, например, это функции обратного вызова (callbacks), устанавливаемые драйверами с помощью функции CmRegisterCallback или CmRegisterCallbackEx.

Посмотрим на отрывок из официальной документации:

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

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

Аналогичный подход применяется в отношении файловой системы и сетевого трафика: так, драйвер мини-фильтра может перехватывать операции с файлами, запрещать или разрешать их, а с помощью фильтрующей прослойки (filtering layer) можно разрешать или запрещать сетевые пакеты.

Для получения более подробной информации рекомендую пройти по указанным ссылкам, все-таки низкоуровневые аспекты фильтрации не входят в тему статьи.

Как убить защитный драйвер из пользовательского режима

Основная опасность заключается в том, что нельзя все предусмотреть, — настолько широки возможности обхода (нейтрализации) подобных «изолирующих» и «самозащитных» драйверов в Windows.

Замена куста реестра

В составе Windows API есть две функции: RegSaveKeyEx и RegReplaceKey. Первая позволяет экспортировать куст реестра (например, HKLM\System) в файл (в бинарном формате), а вторая — заменить весь куст реестра на ранее экспортированный файл.

Трюк заключается в следующем. Мы берем куст HKLM\System, экспортируем его в файл с помощью функции RegSaveKeyEx, затем убираем из этого файла записи о защитном драйвере (формат файлов реестра известен), после чего заменяем текущий куст HKLM\System нашим модифицированным. После перезагрузки компьютера куст HKLM\System будет содержать наши модифицированные данные (то есть записей о защитном драйвере, которые мы удалили, в нем не будет).

Объявление функции RegReplaceKey следующее:

На низком уровне замена куста реестра экспортированным файлом происходит следующим образом (описание приведено для куста HKLM\System, путь к каталогу Windows взят стандартный):

1. Файл C:\Windows\System32\config\SYSTEM переименовывается в lpOldFile.
2. Файл lpNewFile переименовывается в C:\Windows\System32\config\SYSTEM.
3. Операционная система продолжает использовать для куста HKLM\System файл lpOldFile вплоть до перезагрузки.
4. После перезагрузки операционная система начинает использовать файл C:\Windows\System32\config\SYSTEM.

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

Подобный «недостаток» (хотя его можно назвать и уязвимостью) был обнаружен в защитном решении Symantec DCS, в антивирусах «Лаборатории Касперского» и ESET. Ни одна из этих организаций не признала это за уязвимость.

Windows предоставляет возможность установить перехват на замену куста реестра. Драйвер, установивший перехват, получает информацию об имени файла, в который будет переименован текущий файл куста ( lpOldFile), а также об имени файла, которым будет заменен текущий куст ( lpNewFile). Защитный драйвер может проанализировать файл lpNewFile и решить, следует ли заменять им текущий куст или нет.

Однако, если присмотреться внимательнее, можно заметить, что контроль по именам файлов надежным быть не может, поскольку могут возникать ошибки класса TOCTOU (time of check to time of use). Защитный драйвер проанализирует файл lpNewFile и разрешит исполнение кода для замены куста реестра (time of check), но этот код может получить на вход уже совсем другой файл с тем же именем (time of use).

Таким образом, атакующий может инициировать вызов функции RegReplaceKey с каким-то переданным ей на вход именем файла, а в процессе работы этой функции (что включает в себя обратный вызов в защитный драйвер) заменить этот файл другим путем переименования (новый файл будет иметь такое же имя, какое было передано в функцию RegReplaceKey, но фактически это уже другой файл с другим содержимым). При определенном стечении обстоятельств это позволит произвести замену файла как раз перед исполнением кода для замены куста реестра, но после исполнения кода проверки.

Замена ключа реестра

В составе Windows API есть функция RegRestoreKey. Эта функция чем-то отдаленно похожа на RegSaveKeyEx, только заменяет не куст реестра, а отдельный ключ (данные для замены берутся из экспортированного файла реестра, в том же бинарном формате, что назван выше). И не требует перезагрузки.

Объявление функции RegRestoreKey следующее:

В качестве аргумента dwFlags можно передать REG_FORCE_RESTORE, что позволит заменить ключ реестра даже в том случае, если он или его подключи были открыты какой-либо программой (операции над открытыми ключами после замены будут завершены с ошибкой).

Если защитный драйвер не проверит и не заблокирует вызов функции RegRestoreKey, то можно заменить некоторые важные для работы защитного средства ключи реестра. Например, защитное решение Symantec DCS позволяет заменить ключи реестра, отвечающие за запуск сервисов этого решения при загрузке компьютера, пустыми ключами (то есть замененный ключ окажется пустым, без каких-либо ранее существовавших подключей и значений).

Правда, для отключения сервисов все же требуется перезагрузить компьютер. Компания Symantec не признала данный «недостаток» уязвимостью (хотя в 2006 году в отношении другого продукта той же компании аналогичный «недостаток» уязвимостью был признан).

Следует отметить, что антивирусы «Лаборатории Касперского» и ESET блокируют подобные операции. То есть не все так плохо.

Перезагрузка в безопасный режим

А еще можно перезагрузить компьютер в безопасный режим (safe mode), где защитные драйверы обычно не запускаются. Правда, если атакующий получил удаленный доступ к серверу через уязвимый сервис, то этот сервис в безопасном режиме вряд ли запустится (и атакующий потеряет свой доступ), а значит, атакующему надо как-то иначе обеспечить исполнение его кода в безопасном режиме.

Один из вариантов — переконфигурировать операционную систему на запуск уязвимого сервиса в безопасном режиме (это можно сделать, например, создав подключи в ключе HKLM\System\ControlSet001\Control\SafeBoot\Network). Symantec DCS от такого вектора атаки не защищает.

Почему бы не защищать от изменений ключи реестра, отвечающие за запуск сервисов в безопасном режиме?

Работа с защищенными файлами через общие директории

Если процесс атакующего не может прочитать какой-то файл, потому что Symantec DCS блокирует попытки доступа, то можно попытаться сделать то же самое через общие директории. Так, если искомый файл находится в расшаренной папке, то DCS разрешит доступ (в том числе и на запись) к этому файлу по сетевому пути (например, \\127.0.0.1\c$\block_access_files), даже если локальный доступ для данного процесса явно запрещен.

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

Чтение защищенных файлов через краш-дампы

Прочитать открытый в другом процессе защищенный файл можно и косвенно. Например, создать дамп памяти этого процесса (например, с помощью компонента Task Manager или программы procdump) и искать в нем содержимое открытого файла. DCS не блокирует попытки одного процесса инициировать создание дампа памяти другого процесса.

На скриншоте ниже — фрагмент дампа памяти Notepad, где открыт файл, доступ к которому со стороны процесса, инициировавшего создание дампа памяти, закрыт (а в самом дампе есть содержимое открытого файла).

Выводы

Защита от админа в Windows и, в частности, изоляция программ, работающих с правами администратора, друг от друга — это не так просто, как может показаться. Даже весьма «взрослые» продукты вроде Symantec DCS не предоставляют полной защиты.