Вирусы (Руткиты)

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОЛЛЕДЖ ФГБОУ ВО «ЧЕЧЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Дипломная работа

По профессии: Мастер по обработке цифровой информации

Тема: Вирусы (Руткиты)

Грозный, 2018



Оглавление

Введение

1. Принципы работы руткита

1.1 Модификация исходного кода

1.2 Патчинг

2. Механизмы работы руткита

2.1 Захват в режиме пользователя

2.1.1 Захват таблицы импорта

2.1.2 Модификация машинного кода прикладной программы

2.1.3 Внедрение DLL в адресное пространство процесса

2.2 Механизмы работы руткита в режиме ядра (kernel mode)

2.2.1 Захват в режиме ядра

2.2.2 Модификация кода во время исполнения

2.2.3 Непосредственное манипулирование объектами ядра

2.2.4 Манипулирование аппаратурой

3. Методы обнаружения rootkit в системе

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

3.2 Обнаружение деятельности

3.3 Базовые методики поиска RootKit

Заключение

Список использованных источников

руткит захват ядро код



Введение

Руткит (англ. rootkit, т.е. «набор root'а») - программа или набор программ для скрытия следов присутствия злоумышленника или вредоносной программы в системе. Этот набор, как правило, включает в себя разнообразные утилиты для «заметания следов» вторжения в систему, делает незаметными сканеры, кейлоггеры (клавиатурный шпион), троянские программы, замещающие основные утилиты операционной системы.

Важно понимать, что руткит - это всего лишь технология. Сами по себе руткиты не являются чем-то плохим, они не всегда используются злодеями, плохие или хорошие намерения исходят от людей, их использующих. Существует великое множество легитимных коммерческих программ для удаленного управления и даже подслушивания, причем обнаружить некоторые из них невозможно. Во многих отношениях подобные программы можно назвать руткитами. Правоохранительные органы могут называть «руткитами» вполне легитимные программы-лазейки, устанавливаемые с разрешения суда. Большие корпорации также используют технологию руткитов для мониторинга и контроля парка своих компьютеров. Примеры программ, использующих перехват: Антивирус NOD32, утилиты Марка Руссиновича Filemon, Regmon,

Говоря о руткитах, непременно упоминают этимологию термина rootkit: “root” - привилегированный администратор UNIX-системы, “kit” - набор инструментов, rootkit - набор утилит для обеспечения «привилегированного» доступа злоумышленника к системе незаметно для настоящего администратора. Такие утилиты для UNIX появились в начале 90-х гг. и существуют до сих пор, но практически не развиваются.

У Windows-руткитов был более близкий по функционалу предшественник, чем UNIX-руткиты - а именно, стелс-вирусы для DOS. Стелс-вирусы появились около 1990 года. В отличие от UNIX-руткитов, основная задача которых - впустить злоумышленника в систему и маскировать его действия, стелс-вирусы DOS, заражая файлы, просто скрывали себя от пользователя и антивирусных программ.

Windows-руткиты появились десятью годами позже стелс-вирусов, и то, что их назвали именно руткитами, а не стелс-вирусами, заслуга исключительно Грега Хогланда (Greg Hoglund). Он был одним из первых, кто реализовал технику обхода системных механизмов защиты Windows в форме утилиты, нацеленной на сокрытие информации в системе. Результаты его работы были опубликованы в электронном журнале PHRACK. Утилита, названная автором NT Rootkit, впоследствии была применена во многих вредоносных программах и по сей день вдохновляет исследователей и руткитостроителей.

Статья Хогланда датирована 1999 годом. В ней он опирается на исследования ядра Windows, опубликованные годом раньше в форумах Usenet программистом из Шри-Ланки. Еще раньше, начиная с 1995 года, Джефри Рихтер (Jeffrey Richter) в своей книге «Advanced Windows» и четвертом ее издании «Programming Applications for Microsoft Windows» раскрывает технологии перехвата системных вызовов на уровне пользователя, которые будут впоследствии использованы во многих руткитах с точностью до приведенного в книге исходного кода.

Техники перехвата системных вызовов на уровне ядра общедоступно раскрыты в двух других классических книгах по программированию: С. Шрайбер «Недокументированные возможности Windows 2000», 2001 г. (Sven Schreiber Undocumented Windows 2000 secrets) и П. Дабак и др. «Недокументированные возможности Windows NT», 1999 г. (P. Dabak et al Undocumented Windows NT). Исследования системных механизмов защиты Windows продолжились, и вслед за NT Rootkit было выпущено еще несколько утилит, позволяющих скрывать объекты в операционной системе.

В 2000 году появился he4hook - проект русского программиста. Утилита не несла в себе вредоносного функционала, но являлась инструментом для сокрытия файлов и работала в режиме ядра. Помимо этого, утилита самим автором не обозначалась как руткит.

В 2002 году на свет появился Hacker Defender (HacDef). Это также лишь инструмент, но уже более мощный - при помощи него можно скрыть любой файл, процесс или ключ реестра, параметры гибко настраиваются в файле конфигурации. Работает преимущественно в режиме пользователя.

В 2003 году появились Vanquish и Haxdoor (он же A-311 Death и в модифицированном варианте Nuclear Grabber). Vanquish - инструмент, работающий в режиме пользователя и позволяющий скрывать файлы, директории, а также ключи реестра. Кроме того, в нем уже предусмотрена вредоносная функция - логгирование паролей. Haxdoor - это уже полноценный бэкдор, работающий в режиме ядра и использующий руткит-технологии для самомаскировки.

В 2004 году выпущена FU - утилита для скрытия процессов, которая реализовала принципиально новую технологию, основанную на изменении самих системных структур, а не путей доступа к ним.

Все перечисленные руткиты являются ключевыми в истории Windows-руткитов. Особенно стоит отметить HacDef, Haxdoor и FU, широко распространявшихся "в диком виде" в связке с вредоносными программами.

После длительного затишья в начале 2008 года появилась новая вредоносная программа, заражающая загрузочный сектор диска. В антивирусных базах разных производителей она именуется Sinowal, Mebroot, StealthMBR. Этот руткит, больше известный как «буткит» в силу своей «загрузочной» специфики, основан на коде концептуальной разработки eEye Bootroot (немного измененном) и представляет собой не столько самостоятельную вредоносную программу, сколько инструмент для сокрытия любого троянца.



1. Принципы работы руткита

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

1.1 Модификация исходного кода

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



1.2 Патчинг

Патч (заплата) - это специальная программа, которая вносит изменения в основную программу, например, исправляет допущенные ошибки или вносит дополнительные функции. Теоретически, можно пропатчить любую программу, добавив в нее дополнительные функции или изменив уже существующие. Например, можно пропатчить IE (Internet Explorer) так, чтобы он постепенно загружал из Интернета остальные части руткита, как только пользователь подключится к Интернету. Даже если на компьютере установлен брандмауэр, он не запретит действия Internet Explorer, поскольку будет «думать», что эти файлы скачивает сам пользователь. Пользователь же ничего не заметит, поскольку остальные функции браузера будут работать как обычно: он сможет просматривать Web-страницы, заходить на FTP и т. п. В некоторых случаях, если программа пропатчена неправильно, пользователь может догадаться, что происходит, по заметному «торможению» браузера или по ошибкам при запуске и завершении работы. Также патчинг может использоваться для изменения существующих функций программы. Очень часто патчи используются для удаления защиты программы или же получения каких-либо дополнительных возможностей. Например, если при запуске программа проверяет, зарегистрирована она или нет, можно пропатчить ее так, чтобы функция, отвечающая за проверку, всегда возвращала «наверх» положительный результат.

С патчингом можно бороться. Нужно установить на компьютер программу-ревизор. Ревизор вычислит CRC (контрольную сумму) всех файлов (точнее, всех системно-важных: если контролировать вообще все файлы, то системных ресурсов может не хватить) на жестком диске и запишет ее в свою базу данных. Даже если изменить один байт файла, изменится его контрольная сумма. Ревизор может постоянно находиться в памяти и контролировать содержимое системно-важных каталогов. Как только какая-то программа хочет модифицировать системный файл (как правило, это файлы из каталогов %WINDIR% и всех его подкаталогов, а также файлы каталогов Program Files на всех дисках), ревизор блокирует эту программу и спрашивает у вас, что делать дальше. Если устанавливается программа, полученная из надежного источника, можно разрешить установку, в противном случае нужно разобраться, откуда эта программа проникла в систему. Кроме режима монитора у современных ревизоров есть режим сканера. В этом режиме ревизор не находится постоянно в памяти, отнимая ресурсы, а запускается по вашему требованию и бьет тревогу, если CRC какого-либо системно-важного файла изменилась. Если это изменение не санкционировано, можно переустановить этот файл из резервной копии или дистрибутива, в противном случае ревизор внесет соответствующие изменения в свою базу данных, и больше не будет беспокоить.

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



2. Механизмы работы руткита

2.1 Захват в режиме пользователя

Операционная система Windows поддерживает три подсистемы окружения, Win32, POSIX и OS/2. Каждая из них предоставляет свой хорошо документированный набор API-функций. Через эти API-функции все процессы взаимодействуют с операционной системой. Не являются исключением и такие программы, как диспетчер задач, проводник Windows и редактор реестра. Исходя из этого, API-функции являются превосходной целью для руткита. Например, какая-то программа получает список файлов каталога и выполняет какие-то операции над ними. Эта программа может быть запущена в режиме пользователя, как обычное приложение, или же как служба. Предположим, что она является обычным Win32-пpилoжeниeм, значит, она будет пользоваться услугами таких библиотек, как Kernel32.dll, User32.dll, Gui32.dll и Advapi.dll, которые в конечном итоге производят вызов функций ядра. В подсистеме Win32, чтобы получить список файлов каталога, нужно в первую очередь вызвать функцию FindFirstFile, которая экспортируется библиотекой Kernel32.dll. В случае успешного завершения эта функция возвращает описатель файла.

Этот описатель используется в последующих вызовах функции FindNextFile для перечисления всех файлов и подкаталогов, содержащихся в данном каталоге. Функция FindNextFile тоже экспортируется библиотекой Kernel32.dll. Чтобы использовать эти функции, приложение загружает библиотеку Kemel32.dll в память во время исполнения и копирует адреса импортируемых функций в свою таблицу импорта (Import Address Table, I AT). Когда приложение вызывает функцию FindNextFile, происходит передача управления по адресу, который хранится в IAT. Дальше процесс продолжает выполняться уже в теле функции FindNextFile библиотеки Kernel32.dll. То же самое справедливо и для FindFirstFile.

Функция FindNextFile из Kernel32.dll на самом деле вызывает аналогичную функцию (NtQueryDirectoryFile) из Ntdll.dll. Та, в свою очередь, заносит в регистр ЕАХ номер системной службы режима ядра, которая и выполняет нужные действия. Помимо регистра ЕАХ, Ntdll.dll использует еще и регистр EDX, в который помещается адрес буфера в режиме пользователя, хранящего параметры функции FindNextFile. Далее Ntdll.dll вызывает прерывание INT 2Е или использует инструкцию SYSENTER для перехода в режим ядра. Следующий рисунок иллюстрирует последовательность вызовов функций.

Поскольку приложение загружает библиотеку Kernel32.dll в свое адресное пространство (между адресами 0x00010000 и 0x7FFE0000), то руткит может переписать любую функцию из Kernel32.dll или же изменить таблицу импорта приложения, если только он получит доступ к процессу. Это и называется захватом API-функций (API hooking). В данном примере руткит мог бы заменить код функции FindNextFile собственным кодом с целью скрыть какие-либо файлы либо просто изменить нормальный ход исполнения функции. Можно было бы также изменить таблицу импорта приложения, так чтобы вместо функций из Kernel32.dll она указывала на функции, находящиеся в теле руткита. Путем захвата API-функций можно скрыть процесс или сетевой порт, перенаправить запись файла в другой файл, предотвратить открытие описателя определенного процесса приложением и даже больше.

2.1.1 Захват таблицы импорта

Данная методика описана в книге Рихтера и является одной из классических. Идея метода проста - RootKit находит в памяти таблицу импорта программы и исправляет адреса интересующих его функций на адреса своих перехватчиков (естественно, он предварительно где-то у себя запоминает правильные адреса). В момент вызова API функции программа считывает ее адрес из таблицы импорта и передает по этому адресу управление. Методика универсальна, но у нее есть существенный недостаток (и его хорошо видно на схеме) - перехватываются только статически импортируемые функции. Но есть и плюс - методика очень проста в реализации и есть масса примеров, демонстрирующих ее реализацию. Поиск таблицы импорта в памяти не представляет особой сложности, поскольку для этого существуют специализированные API функции, позволяющие работать с образом программы в памяти. Исходный текст такого перехватчика на языке C занимает несколько листов печатного текста;

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



2.1.2 Модификация машинного кода прикладной программы

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

Рис.3 Модификация машинного кода прикладной программы

2.1.3 Внедрение DLL в адресное пространство процесса

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

Внедрение DLL с помощью реестра

В операционных системах Windows NT/2000/ХР/2003 существует ключ реестра HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\

CumntVersion\Win-dows\AppInit_DLLs. Руткит может установить в качестве значения этого ключа одну из своих библиотек DLL, которая модифицирует IAT целевого процесса или изменяет непосредственно файл kernel32.dll или ntdll.dll. Когда загружается любое приложение, использующее библиотеку user32.dll, все библиотеки DLL, перечисленные в этом разделе реестра, тоже загружаются в адресное пространство этого приложения.

Загрузка каждой из этих библиотек происходит вызовом LoadLibrary. При загрузке каждой библиотеки DLL ее функция DllMain вызывается с параметром DLLPROCESSATTACH. Существует всего четыре варианта загрузки DLL в адресное пространство процесса, но интересует именно вариант с DLLPROCESSATTACH. В момент загрузки DLL с этим параметром руткит должен произвести захват нужных ему функций. С этого момента каждое приложение, которое использует библиотеку user32.dll, а таких большинство (за исключением некоторых консольных приложений), можно будет очень легко обмануть, захватив API-функции. Будет возможность скрывать присутствие файлов, записей в реестре и т. д.

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

Внедрение DLL путем захвата Windows-сообщений

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

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

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

ННООК SetWindowsHookEx(int idHook, HOOKPROC Ipfn, HINSTANCE hMod, DWORD dwThreadld);

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

Если процесс А делает вызов SetWindowsHookEx(WH_KEYBOARD, myKeyBrdFuncAd, myDllHandle, 0), например, в тот момент, когда процесс В вот-вот получит сообщение от клавиатуры, в адресное пространство процесса В будет загружена библиотека DLL, указанная в параметре myDllHandle и содержащая функцию myKeyBrdFuncAd. И снова библиотека DLL, являющаяся частью руткита, получит возможность захватывать IAT в адресном пространстве процесса или реализовывать захват функций путем непосредственной модификации их кода.

Внедрение DLL с помощью удаленных потоков

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

HANDLE CreateRemoteThread (HANDLE hProcess,

LPSECURITY_ATTRIBUTES lpThreadAttributes,

SIZE_T dwStackSize,

LPTHREAD_START_ROUTINE 1pStartAddress,

LPVOID IpParameter,

DWORD dwCreationFlags,

LPDWORD lpThreadld);

Первый параметр - это описатель процесса, в котором создается поток. Для получения этого описателя загрузчик руткита может воспользоваться функцией OpenProcess, в качестве параметра ей нужно передать идентификатор процесса (Process Identifier, PID). Функция OpenProcess имеет следующий прототип:

HANDLE OpenProcess

(DWORD dwDesiredAccess,

BOOL blnheritHandle,

DWORD dwProcessId);

Используя программу Taskmgr.exe, можно узнать PID процесса. Естественно, получить его можно и программным способом.

Второй и седьмой параметры функции CreateRemoteThread устанавливаются в NULL, третий и шестой - в 0. Остались четвертый и пятый параметры, они для атаки самые важные. Загрузчик руткита должен передать в качестве четвертого параметра адрес функции LoadLibrary в целевом процессе. Можно воспользоваться адресом LoadLibrary загрузочного приложения. Это сработает, только если целевой процесс импортирует какие-либо функции из библиотеки Kernel32.dll, в которой и находится функция LoadLibrary. Итак, чтобы получить нужный адрес, необходимо воспользоваться функцией GetProcAddress:

GetProcAddress(GetModuleHandle(TEXT( «Kernel32")), "LoadLibraryA");

Приведенный ранее код получает адрес LoadLibrary из процесса, выполняющего внедрение. Можно, не опасаясь, воспользоваться этим адресом, так как библиотека Kernel32.dll располагается в целевом процессе по тем же самым виртуальным адресам, что и в процессе, выполняющем внедрение. (Это обычное явление. Изменение адресной базы библиотеки требует дополнительных временных затрат, и Microsoft, естественно, старается их избежать.) Функция LoadLibrary имеет тот же самый формат, что и функция THREAD_START_ROUTINE,поэтому она может быть использована в качестве четвертого параметра CreateRemoteThread. Последний пятый параметр - это адрес аргумента, который будет передан функции LoadLibrary. Нельзя просто передать сюда адрес строки, содержащей имя DLL, так как эта строка на самом деле находится в адресном пространстве приложения, выполняющего внедрение, следовательно, этот адрес не имеет смысла для целевого процесса. Существуют две функции, позволяющие загрузчику руткита обойти это препятствие. При помощи функции VirtualAllocEx можно выделить память в адресном пространстве целевого процесса:

LPVOID VirtualА11осЕх

(HANDLE hProcess,

LPVOID lpAddress,

SIZE_T dwSize,

DWORD flAllocationType, DWORD flProtect);

Чтобы записать имя DLL в память, которая была только что выделена функцией VirtualAllocEx, можно воспользоваться функцией WriteProcessMemory. Она имеет следующий прототип:

BOOL WriteProcessMemory (HANDLE hProcess,

LPVOID lpBaseAddress, LPCV0I0 lpBuffer,

SIZE_T nSize,

SIZE_T* lpNumberOfBytesWritten);

Данные захваты (захват IAT и захват функций путем непосредственной модификации их кода) вполне типичны и для их реализации требуется получить доступ к адресному пространству целевого приложения. Обычные способы сделать это - внедрение DLL или создание удаленного программного потока.

2.2 Механизмы работы руткита в режиме ядра (kernel mode)

2.2.1 Захват в режиме ядра

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

Рисунок 1.Схема перехвата функций в режиме ядра

Основное взаимодействие с ядром производится через ntdll.dll, большинство функций которой являются переходниками, обращающимся к ядру через прерывание INT 2Eh (следует заметить, что прикладной программе ничто не мешает напрямую вызывать INT 2Eh). Дальнейшее обращение к функциям ядра основана на структуре, именуемой KeServiceDescriptorTable (или сокращенно SDT), расположенной в ntoskrnl.exe. SDT - это таблица, содержащая адреса точек входа сервисов ядра NT. Описание функций и методик перехвата можно найти в книге Свена Шрайбера «Недокументированные возможности Windows 2000», там же приведена схема взаимодействия, послужившая прототипом для приведенной здесь схемы. Упрощенно можно сказать, что для перехвата функций необходимо написать драйвер, который произведет модификацию таблицы SDT. Перед модификацией драйверу необходимо сохранить адреса перехватываемых функций и записать в таблицу SDT адреса своих обработчиков.

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

2.2.2 Модификация кода во время исполнения

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

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

Ход исполнения программы может быть изменен несколькими способами. Самое очевидное - просто изменить исходные коды программы и перекомпилировать ее. Обычно так поступают разработчики. Второй способ состоит в изменении уже откомпилированной программы, то есть в модификации ее двоичного образа. Так делают взломщики программного обеспечения, чтобы преодолеть защиту от копирования. Еще можно изменить данные в памяти запущенной программы. Хорошим примером здесь являются «игровые тренеры», изменяющие игру для того, например, чтобы получить бонус в 10 миллионов золотых монет. Изменение логики работы программы проще, чем замена системных файлов своими троянскими файлами. Подправив всего несколько байтов, можно отключить большинство функций защиты. Естественно, для этого вы должны иметь возможность читать из защищенных областей памяти и писать в них. Так как руткиты работают в режиме ядра, у нас есть полный доступ ко всей памяти системы, и проблем здесь возникать не должно.

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

Внедрение кода обхода

Технику захвата вызовов функций удобно использовать для изменения поведения программ, но у нее существует один недостаток. Чтобы осуществить захват, приходится вносить изменения в таблицы вызовов, что легко обнаруживается антивирусами и другим защитным программным обеспечением. Лучшим решением здесь является внедрение инструкции перехода в саму функцию, чтобы передать оттуда управление в код руткита. К тому же модификация всего одной функции избавит вас от необходимости осуществлять захват всех таблиц, в которых есть ссылки на данную функцию. Эта техника, которая называется внедрением кода обхода (detour patching), позволяет передать управление за пределы функции.

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

Разновидности метода модификации кода

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

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

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

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

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

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

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

2.2.3 Непосредственное манипулирование объектами ядра

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

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

Существует другой полезный прием - непосредственное манипулирование объектами ядра (Direct Kernel Object Manipulation, DKOM).

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

Достоинства и недостатки DKOM

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

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

Что собой представляет объект изнутри, какова его структура? Зачастую этот вопрос является самым сложным.

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

Изменился ли объект после изменения основной версии операционной системы (например, при переходе от Windows 2000 к Windows ХР) или при выходе очередного пакета обновлений? Многие объекты имеют разную структуру в различных версиях операционной системы.

Когда используется объект? Имеется в виду не время обращения к объекту, а состояние системы и компьютера в момент обращения. Это важно, так как некоторые области памяти и некоторые функции недоступны на определенных уровнях запроса прерывания (IRQL).

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

Несмотря на все эти ограничения, DKOM можно использовать для того, чтобы:

скрывать процессы;

скрывать драйверы устройств;

скрывать порты;

повышать уровень привилегий потоков, а следовательно, и процессов;

уничтожать улики.

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

Операционные системы Windows NT/2000/XP/2003 хранят информацию о запущенных процессах и потоках в объектах. К этим объектам и обращаются утилиты типа Taskmgr.exe, чтобы отобразить список исполняющихся процессов компьютера. Все обращения происходят через функцию ZwQuerySystemlnformation. Модифицировав эти объекты, можно скрывать процессы, повышать уровень их привилегий и выполнять другие действия.

2.2.4 Манипулирование аппаратурой

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

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

Но не все компьютеры - это те «персональные компьютеры», которые мы знаем. Многие компьютеры - это небольшие встроенные системы, решающие достаточно специфические задачи. Эти системы повсюду вокруг нас, но в большинстве случаев мы их просто не замечаем.

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

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

Почему все-таки аппаратура?

Непосредственная работа с устройствами имеет как свои достоинства, так и недостатки. С одной стороны, руткит находится уровнем «ниже» всего остального. Это означает, что имеется намного больше возможностей контролировать систему и оставаться невидимым (настолько невидимым, насколько захочется). Это означает прямой доступ к периферийному оборудованию, дисковым контроллерам, USB-устройствам, процессорам, а также к встроенным микропрограммам устройств. С другой стороны, работать напрямую с аппаратурой сложнее, к тому же руткит должен быть специально разработан под конкретную аппаратную конфигурацию. Другими словами, он будет плохо переносимым. Нужно хорошо взвесить все «за» и «против», прежде чем принять решение об использовании данной технологии.

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

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

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

Модификация микропрограмм

Современная аппаратура устроена так, что процессор всегда начинает работу с выполнения программы, сохраненной в микросхеме памяти. Например, персональный компьютер начинает свою работу с выполнения программы, находящейся в микросхеме BIOS. Все устройства очень отличаются друг от друга, хотя для всех них существует один общий принцип: рано или поздно, так или иначе запускается загрузочный код. Этот код и называется встроенной микропрограммой. Микропрограмма находится в энергонезависимой памяти (то есть она не стирается, когда система выключается). Если вы не знаете, с чего начать, начните с загрузочного кода.

Учитывая, что микропрограмма очень важна для нормального функционирования системы, руткит не должен оказывать на нее негативного влияния. Наоборот, руткит должен наделять существующий код новыми возможностями. Это легко сделать, если восстановить исходную микропрограмму утилитой наподобие IDA-Pro См. www.datarescue.com. и найти подходящее место, куда можно внести исправления. Объем микропрограммы ограничен, так что если размер руткита недостаточно мал, чтобы поместиться в свободное место на микросхеме памяти, то придется еще и переписать некоторые фрагменты микропрограммы. Иногда случается, что в микропрограмме предусмотрены возможности, которые никогда не используются устройством, или же существуют секции с «лишними» в данных условиях данными. Именно эти фрагменты могут быть кандидатами на перезапись.

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

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



3. Методы обнаружения rootkit в системе

Рассмотрим базовые методики поиска RootKit: Сравнение двух «снимков» системы (например, списка файлов на диске). Первый снимок делается на проверяемой системе, второй - после загрузки с CD или подключения исследуемого HDD к заведомо чистому компьютеру. Подобная методика гарантированно позволит обнаружить любой RootKit, который маскирует на диске свои файлы. Сравнение данных, возвращаемых API функциями разного уровня и (или) получаемых низкоуровневыми методами (например, прямым чтением диска и анализом файлов реестра). Данная методика не требует перезагрузки исследуемого ПК и реализована в бесплатной утилите RootkitRevealer от SysInternals (#"_Toc245220976">8 Заключение Описанные выше базовые методики перехвата функций поясняют основные принципы работы RootKit. Однако следует помнить, что разработчики RootKit-технологий не стоят на месте, в результате постоянно появляются новые разработки, подходы и методы.

Практика показывает, что разработчики вредоносных программ (вирусов, троянских программ, шпионского ПО) все чаще начинают использовать RootKit-технологии, что существенно затрудняет обнаружение и удаление созданных ими вредоносных программ. Чаще всего применяются методики перехвата функций в режиме пользователя, но в последнее время появились весьма эффективные реализации с применением драйверов. В этом плане по моей статистике наиболее «знаменит» Backdoor.Win32.Haxdoor, который устанавливает в систему несколько драйверов, что позволяет ему достаточно эффективно маскироваться от обнаружения пользователем.

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



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

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

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

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

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

3.2 Обнаружение деятельности

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



3.3 Базовые методики поиска RootKit

1. Сравнение двух «снимков» системы (например, списка файлов на диске). Первый снимок делается на проверяемой системе, второй - после загрузки с CD или подключения исследуемого HDD к заведомо чистому компьютеру. Подобная методика гарантированно позволит обнаружить любой RootKit, который маскирует на диске свои файлы.

2. Сравнение данных, возвращаемых API функциями разного уровня и (или) получаемых низкоуровневыми методами (например, прямым чтением диска и анализом файлов реестра). Данная методика не требует перезагрузки исследуемого ПК и реализована в бесплатной утилите RootkitRevealer от SysInternals. Другим примером может случить утилита KLister (www.rootkit.com) для построения списка запущенных процессов, которая состоит из драйвера и консольной программы, использующей этот драйвер;

3. Анализ в памяти функций основных библиотек на предмет наличия изменений их машинного кода. Данный метод наиболее эффективен для борьбы с RootKit в пользовательском режиме. Подобная методика позволяет не только обнаружить перехват функций, но и восстановить нормальную работу поврежденных функций. Кроме того, сравнение «снимков» системы, полученных до и после восстановления функций API во многих случаях позволяет обнаружить маскирующиеся процессы, сервисы и драйверы. Данная методика не требует перезагрузки и один из вариантов реализован в утилите AVZ;

4. Анализ и восстановление ServiceDescriptorTable. Данная методика позволяет бороться с рядом перехватчиков, работающих в режиме ядра (собственно, с перехватчиками, основанными на правке SDT). Практическая реализация - утилита SDTRestore. Однако восстановление SDT окажет воздействие на работу всей системы и может привести к очень неприятным последствиям (в простейшем случае - полное зависание системы с выходом на BSoD, в худшем - непредсказуемое нарушение нормальной работы приложений, перехватывающих NativeAPI для реализации своих функций).



Заключение

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

Практика показывает, что разработчики вредоносных программ (вирусов, троянских программ, шпионского ПО) все чаще начинают использовать RootKit-технологии, что существенно затрудняет обнаружение и удаление созданных ими вредоносных программ. Чаще всего применяются методики перехвата функций в режиме пользователя, но в последнее время появились весьма эффективные реализации с применением драйверов. В этом плане по моей статистике наиболее «знаменит» Backdoor.Win32.Haxdoor, который устанавливает в систему несколько драйверов, что позволяет ему достаточно эффективно маскироваться от обнаружения пользователем.



Список использованных источников

1. Козлов Д.А., Парандовский А.А., Парандовский А.К. Энциклопедия компьютерных вирусов. - М.: "СОЛОН-Р", 2013.

2. Г. Хоглунд, Дж. Батлер 2015 - Руткиты. Внедрение в ядро Windows.

3. Д. Колиснеченко 2014 - Руткиты под Windows: Теория и практика программирования.

4. Галатенко В., Информационная безопасность, "Открытые системы", N 4,5,6, 2014

5. Касперский Е.В. Компьютерное zловредство / Е.В. Касперский - СПб.: Питер, 2014. -208с.

6. А. Алексеев "Информатика 2015" Москва, "Дрофа" 2015