Система обнаружения скрытых ресурсов в системе

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

Область техники

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

Уровень техники

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

Однако существуют также классы вредоносных программ, которые по-прежнему являются одной из самых больших угроз для компьютерной безопасности. Речь идет о так называемых "руткитах" (rootkit), т.е. о программах, которые скрывают следы своего присутствия в системе, используя, например, режим администратора (более подробно можно прочитать, в том числе и в Википедии - http://en.wikipedia.org/wiki/Rootkit). Подобные программы бывает тяжело обнаружить из-за того, что антивирусное приложение может быть не в состоянии определить наличие или использование каких-либо скрытых ресурсов в системе, например, файлов или веток реестра. Для сокрытия своего присутствия руткиты применяют различные перехваты системных функций (т.е. программные перехватчики), которые они изменяют таким образом, чтобы возвращаемые результаты не содержали скрываемых ресурсов (например, сокрытие веток реестра).

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

Традиционные методы обнаружения руткитов заключаются в том, что для каждого из них разрабатывается собственная процедура обнаружения для того, чтобы его обнаружить или убрать перехваты, которые он использует, что увеличивает время их обнаружения и добавления в антивирусные базы. С этой целью можно использовать различные программы, такие как Sophos Anti-Rootkit (http://www.sophos.com/products/free-tools/sophos-anti-rootkit.html) или AVZ (http://www.z-oleg.com/secur/avz/). Системы для обнаружения скрытых ресурсов в системе также описаны в патентах и заявках, таких как US 20070078915, WO 2007044498, JP 2008004064, US 20050229250. Однако все эти системы не способны обнаружить новые типы руткитов, которые используют другие способы сокрытия ресурсов в системе. Таким образом, требуется создать систему, которая позволяла бы определять факт присутствия руткита в системе при нахождении скрытых ресурсов в системе.

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

Сущность полезной модели

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

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

В частном варианте реализации средство доступа предназначено для аутентификации средства сравнения с целью дальнейшей передачи списка ресурсов на средство сравнения от средства предоставления возможностей ядра.

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

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

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

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

Краткое описание чертежей

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

Фиг.1 иллюстрирует работу системы настоящей полезной модели.

Фиг.2 отображает разделение процессов в компьютерной системе.

Фиг.3 показывает факт обнаружения руткита при определении скрытых ресурсов в системе.

Фиг.4 отображает процесс инициализации средства предоставления возможностей ядра и драйвера режима ядра.

Фиг.5 иллюстрирует работу настоящей полезной модели с устройством на низком уровне.

Фиг.6 показывает вариант реализации настоящей полезной модели.

Описание вариантов осуществления полезной модели

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

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

На фиг.1 отображена схема работы настоящей полезной модели, которая используется для обнаружения скрытых ресурсов за счет обхода перехватов, которые могут использовать руткиты. Как видно, приложения пользователя 130, которые работают в режиме пользователя, для получения доступа к определенному ресурсу компьютерной системы, должны будут обратиться к ядру операционной системы. Однако в ядро ОС 120, к которому обычно и идут такие запросы, может быть внедрен руткит 160, который имеет доступ к перехваченной API функции 140а. Таким образом, если приложение пользователя пытается запросить, например, список файлов, то руткит 160 легко может скрыть необходимые ему файлы путем возврата модифицированного списка файлов через перехваченную API функцию 140а. Таким же образом руткит может скрыть необходимые ему файлы или ветки реестра, что позволяет успешно скрывать свое присутствие в системе.

Однако при применении средства 110 предоставления возможностей ядра с неизмененными API функциями 140 можно обойти подобные перехваты. Для этого используется драйвер режима ядра 150, который обеспечивает доступ к средству 110 предоставления возможностей ядра. Благодаря такому подходу возможно обойти перехваты и получить данные, которые могут включать также и скрытые руткитами ресурсы. Стоит отметить, что в средстве 110 предоставления возможностей ядра находится на выполнении только тот поток, который запросил информацию (например, это может быть запрос о списке файлов). На этом моменте стоит остановиться более подробно.

Как известно, каждый процесс порождает потоки выполнения (threads) в системе. Для того чтобы определить те потоки, которые могут обратиться к драйверу режима ядра 150, требуется отдельный механизм обращения к этому драйверу, т.е. должен быть пройден этап аутентификации. В одном из вариантов реализации эти потоки могут быть порождены процессом антивирусного приложения, которое имеет информацию о способе аутентификации у драйвера режима ядра 150. Таким образом, все потоки в системе можно разделить на две части - те, которые располагают доступом к драйверу режима ядра 150 и все остальные. Все остальные потоки работают так, как будто в операционной системе находится только одно ядро ОС 120, которое и обслуживает все их запросы. Именно драйвер режима ядра 150 определяет, какой поток можно использовать в средстве 110 предоставления возможностей ядра. Образно говоря, драйвер позволяет "пробрасывать" эти потоки в средство 110 предоставления возможностей ядра, в то время как все остальные потоки работают с ядром ОС 120. Дополнительно отметим, что ядро ОС 120, также как и средство 110 предоставления возможностей ядра может быть как 32-битным, так и для 64-битным.

На фиг.2 изображено разделение процессов в компьютерной системе. Процесс антивирусного приложения 210 запускает потоки антивирусного приложения 220, которые могут обращаться к драйверу режима ядра на этапе 230 после аутентификации. Затем они приступают к работе со средством 110 предоставления возможностей ядра на этапе 240. Любые другие процессы 250 запускают собственные потоки 260, которые работают только с ядром ОС 270, что не приводит к снижению скорости работы системы в целом.

На фиг.3 показано обнаружение руткита при определении скрытых ресурсов в системе в качестве одного из вариантов реализации настоящей полезной модели. Например, на этапе 310 один из потоков антивирусного приложения запрашивает список процессов. Средство 110 предоставления возможностей ядра вернет ему более полный список, чем ядро ОС 120, так как руткит 160 использует перехваченную API функцию 140а для того, чтобы изменять возвращаемый список процессов (при этом исключив свой собственный процесс). Обнаружив несоответствие между списками, можно сделать вывод о том, что был обнаружен скрытый процесс на этапе 320. Затем антивирусное приложение может запросить файл скрытого процесса на этапе 330 для его антивирусной проверки на этапе 340. В том случае, если антивирусная проверка выявит присутствие руткита, он будет удален из системы.

С помощью работы подобной системы можно обойти такие методы перехватов, как сплайсинг любого рода (используется для перехвата вызова какой-нибудь API функции; суть метода состоит в замене первых нескольких байт функции инструкцией передающей управление коду-перехватчику), SSDT (System Service Descriptor Table) и Shadow SSDT перехваты, прерывания INT 2E для версии Windows 2000 (за счет создания переходников для Zw-функций, т.е. тех функций, которые производят перед выполнением действия проверки системы безопасности (прав пользователя), в то время как функции с префиксом Nt - нет) и MSR (специальные регистры процессоров архитектуры x86, наличие и назначение которых варьируется от модели к модели процессора), любые обратные вызовы (callback) и оповещения (notify), которые не будут работать при вызове функций в средстве 110 предоставления возможностей ядра (например, обратные вызовы на изменения в реестре).

Фиг.4 отображает процесс инициализации средства 110 предоставления возможностей ядра и драйвера режима ядра. На этапе 410 происходит инициализация драйвера режима ядра, затем происходит загрузка пути к файлу средства 110 предоставления возможностей ядра на этапе 420. В одном из вариантов реализации путь считывается из недокументированной переменной KeLoaderBlock. Такая переменная существует лишь некоторое время во время инициализации средства 110 предоставления возможностей ядра, поэтому инициализация на этапе 410 должна происходить как можно раньше. На этапе 430 происходит считывание средства 110 предоставления возможностей ядра с диска после того, как был загружен путь к файлу средства 110 предоставления возможностей ядра на предыдущем этапе. На этапе 440 средство 110 предоставления возможностей ядра размещается в памяти: выравниваются секции, глобальные переменные будут указывать в ядро ОС 120, а импортируемые функции в нужные модули. После чего на этапе 450 происходит его настройка нужным образом: создается своя таблица SSDT, необходимые переходники для функций, убираются обратные вызовы (callback) и оповещения (notify).

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

Как было отмечено выше, технологию отдельного ядра (например, в виде средства 110 предоставления возможностей ядра, как было описано выше) можно применять не только к образу ядра системы, но также и к различным системным драйверам. В частности, для доступа к диску используют системные порт-драйверы устройств (system-supplied storage port drivers). Например, в операционной системе Windows их два вида:

- SCSI Port Driver (scsiport.sys), Storport Driver (storport.sys)

- ATA Port Driver (ataport.sys/atapi. sys)

Например, на фиг.5 перехваты руткита могут быть расположены как на уровне управления разделами жесткого диска 520 (например, partmgr.sys), драйвера диска 530 (disk. sys), так и даже на уровне порт-драйвера 540 (atapi.sys). Таким образом, если не известно заранее на каком уровне могут находиться перехваты руткита, то обнаружить его становится невозможно.

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

Таким образом, можно инициализировать средство 560 использования функциональности порт-драйвера в той же манере, что использовалась и для средства 110 предоставления возможностей ядра, для доступа к расширенной функциональности жесткого диска 510. Использование порт-драйверов таким образом позволяет обходить перехваты руткитов, которые запрещают доступ к определенным секторам диска или возвращают подложное содержимое при чтении на самом низком уровне. Аутентификация у драйвера режима порт-драйвера 550 происходит так же, как и для драйвера режима ядра 150 на фиг.2.

Фиг.6 показывает вариант реализации настоящей полезной модели. Ядро ОС 120 отправляет обработанные результаты запросов (например, на предоставления списка ресурсов) на средство 630 сравнения, которое также соединено со средством 110 предоставления возможностей ядра через средство 620 доступа. Средство доступа отвечает за аутентификацию средства 630 сравнения на доступ к средству 110 предоставления возможностей ядра для того, чтобы к средству 110 предоставления возможностей ядра не получили доступ другие приложения или устройства в системе. Само средство 110 предоставления возможностей ядра реализует функции ядра ОС 120. В одном из вариантов реализации средство 620 доступа реализовано с помощью драйвера режима ядра 150. Получив результаты запросов от ядра ОС 120 и от средства 110 предоставления возможностей ядра, средство 630 сравнения делает вывод о наличии руткита в системе при расхождении полученных результатов.

В системе могут присутствовать драйверы устройств 640, которые обеспечивают доступ к устройствам 660, к таким как, например, жесткий диск. Средство 650 использования функциональности драйверов также обеспечивает доступ к устройствам 660, но только через средство 620 доступа с той же целью, что и для средства 110 предоставления возможностей ядра, т.е. для ограничения доступа. После получения результатов запросов на доступ от драйверов устройств 640 и от средства 650 использования функциональности драйверов, средство 630 сравнения сопоставляет полученные результаты. В том случае, если результаты расходятся, то делается вывод о нахождении руткита в системе.

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

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

2. Система по п.1, в которой средство доступа предназначено для аутентификации средства сравнения с целью дальнейшей передачи списка ресурсов на средство сравнения от средства предоставления возможностей ядра.

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

4. Система по п.1, которая также дополнительно содержит: драйвер устройства предназначен для предоставления доступа к аппаратным возможностям устройства в компьютерной системе, драйвер устройства также связан со средством сравнения; средство использования функциональности драйвера также связано с устройством в компьютерной системе и средством доступа, при этом средство использования функциональности драйвера предназначено для предоставления доступа к аппаратным возможностям устройства после подтверждения аутентификации от средства доступа; дополнительно средство доступа контролирует доступ к средству использования функциональности драйвера, используя аутентификацию; дополнительно средство сравнения предназначено для сравнения доступа к аппаратным возможностям устройства от драйвера устройства и от средства использования функциональности драйвера и при их различии делает вывод о наличии руткита.

5. Система по п.4, в которой устройством в компьютерной системе является жесткий диск.

6. Система по п.4, в которой средство доступа предназначено для аутентификации средства сравнения с целью дальнейшей передачи списка ресурсов на средство сравнения от средства использования функциональности ядра.