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

Все средства, которые доступны программам защиты, доступны и руткиту. Какие бы направления внутри операционной системы ни блокировались, чтобы защититься от действий руткита, все они легко могут быть разблокированы.

Руткит может препятствовать запуску или правильной работе программ обнаружения или предотвращения вторжений. В конечном итоге в «гонке вооружений» между нападающим и защищающимся подавляющее преимущество у того кода, который раньше проникнет в ядро и будет исполнен.

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

Верно и обратное: разработчики непрерывно обновляют программы обнаружения вторжений по мере появления новых технологий в разработке руткитов.

Руткит (англ. rootkit, то есть «набор root’а») — набор программных средств (например, исполняемых файлов, скриптов, конфигурационных файлов), для обеспечения:

маскировки объектов (процессов, файлов, директорий, драйверов)

контроля (событий происходящих в системе)

сбора данных (параметров системы)

Rootkit позволяет взломщику закрепиться во взломанной системе и скрыть следы своей деятельности путём сокрытия файлов, процессов, а также самого присутствия руткита в системе.

https://ru.wikipedia.org/wiki/%D0%F3%F2%EA%E8%F2

В этой статье мы рассмотрим два основных подхода к обнаружению руткитов: определение факта присутствия руткита и выявление его деятельности.

Обнаружение факта присутствия руткита

 

Для обнаружения факта присутствия руткита может быть использовано множество приемов. В прошлом соответствующие программы, такие как Tripwire, искали некие образы в файловой системе. Подобный подход, который до сих пор применяют основные производители антивирусных программ, вполне подходит и для обнаружения руткитов.

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

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

Поскольку программам, подобным Tripwire, присущи указанные ограничения, используются и другие методы обнаружения руткитов. В следующих разделах мы рассмотрим некоторые из них, применяемые для нахождения в памяти самого руткита или оставленных им улик.

Метод «охраны дверей»

Все программы должны «жить» где-то в памяти. Таким образом, чтобы найти руткит, можно исследовать память.

Исследовать память можно двояко. Первое — ловить руткит в момент его загрузки в память. При этом подходе, называемым охраной дверей (guarding the doors), проверяется все, что попадает в компьютер (процессы, драйверы устройств и т.д.).

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

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

Например, в системе IPD (Integrity Protection Driver — драйвер: защиты целостности) производства компании Pedestal Software защита была построена на перехвате функций ядра в SSDT, таких как NtLoadDriver и NtOpenSection.

Однако была найдена возможность загрузить модуль в ядро, вызвав функцию ZwSetSystemlnformation, которую IPD-драйвер не перехватывал. После того как это упущение IPD было исправлено, некто под псевдонимом Crazylord опубликовал статью, описывающую, как обойти защиту IPD-драйвера, используя символическую ссылку WDEVICEWPHYSICALMEMORY.

В результате разработчикам IPD-драйвера пришлось снова совершенствовать свое детище.

Последняя версия IPD-драйвера отлавливала следующие функции:
? ZwOpenKey;
? ZwCreateKey;
? ZwSetValueKey;
? ZwCreateFile;
? ZwOpenFile;

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

На данный момент компания Pedestal больше не поддерживает этот продукт.

К тому же список функций не полон. Например, еще одним способом загрузить руткит может быть проникновение в адресное пространство другого процесса. Кроме того, для загрузки DLL в другой процесс могут быть использованы другие подходы. Однако и это далеко не все доступные методы проникновения.

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

Очевидным способом выявить такую попытку является контроль функций ZwOpenKey, ZwCreateKey и ZwSetValueKey (как это делает, например, IPD-драйвер). Однако если программа обнаружения руткитов контролирует эти функции, как она узнает, какие ключи охранять?

Драйверы обычно располагаются в ключе:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Вполне естественно наблюдать за этим ключом, но руткит может изменить и другой ключ:
HKEY_LOCAL_MACHINE\System\ControlSet001\Services

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

В данном примере мы даже не пытаемся учесть все те ключи реестра, которые отвечают за загрузку программных расширений. Кроме того, нужно учесть возможность загрузки дополнительных библиотек DLL, например, вспомогательных объектов браузера (Browser Helper Object).

Программы обнаружения руткитов должны также уделять внимание символическим ссылкам. Символические ссылки — это альтернативные имена системных объектов.

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

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

Но даже если предположить, что нам удалось найти все пути, которыми может воспользоваться руткит для загрузки, и мы знаем все возможные имена критических ресурсов, которые надо защищать, у нас остается проблема, как отличить «хорошие» программы от «плохих».

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

Оба этих подхода очень сложно реализовать на практике. Сигнатуры требуют знания руткита, и очевидно против неизвестного руткита они не помогут. Анализировать поведение также сложно, поскольку не ясны критерии положительных и отрицательных результатов проверки.

Столь же важно знать, когда поднимать тревогу. Эта битва за безопасность, которую ведут разработчики антивирусных программ, идет непрерывно.

Вы можете посмотреть так же записи