Перейти к содержимому
Integra

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

Recommended Posts

 
  • Защита от админа в исполнении драйвера
  • Немного о защитном драйвере
  • Так ли просто закрыть бреши?
  • Уби(р|в)аем защитный драйвер из пользовательского режима
  • Замена куста реестра
  • Замена ключа реестра
  • Перезагрузка в безопасный режим
  • Работа с защищенными файлами через общие директории
  • Чтение защищенных файлов через краш-дампы
  • Выводы

Представь себе, что ты получил доступ к контроллеру домена с правами админа. Твои следующие шаги? Я бы сразу скопировал себе базу NTDS (ведь там есть хеши для доменных учеток), а еще бы посмотрел, что покажет mimikatz, — это могут быть хеши от паролей для различных учеток и иногда сами пароли открытым текстом.

Вот только базу NTDS просто так не скопировать — она представляет собой залоченный файл, который нельзя открыть и прочитать. Чтобы это обойти, атакующие вычитывают эту базу напрямую с диска, с помощью собственного парсера NTFS. Программы вроде mimikatz тоже работают не в лоб, а с некоторыми хитростями.

И однажды можно обнаружить, что на одном из серверов прочитать данные с диска напрямую нельзя — что-то мешает. И mimikatz тоже завершается с ошибкой. Хотя права админа есть. Что же это?

Защита от админа в исполнении драйвера

Когда-то, во времена 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.

Давай уже перейдем к техническим деталям!

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

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

LSTATUS RegReplaceKeyA(
  HKEY   hKey,
  LPCSTR lpSubKey,
  LPCSTR lpNewFile,
  LPCSTR lpOldFile
)

На низком уровне замена куста реестра экспортированным файлом происходит следующим образом (описание приведено для куста 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 следующее:

LSTATUS RegRestoreKeyA(
  HKEY   hKey,
  LPCSTR lpFile,
  DWORD  dwFlags
);

В качестве аргумента 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 не предоставляют полной защиты.

 


View full article

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хммм

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Действительно не просто

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да это так на первый взгляд кажется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я вот уже давно нечто подобное искал

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×