Rootkit. Принципы и механизмы работы

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

«Rootkit. Принципы и механизмы работы»

Выпускная квалификационная работа (бакалаврская работа)

по специальности «Прикладная математика и информатика»

Содержание

Введение

Глава 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 Обнаружение деятельности

Заключение

Литература

Введение

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

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

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

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

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

Руткиты предоставляют две основные функции: удаленное управление и подслушивание программ. Удаленное управление может включать управление файлами, перезагрузкой и синим экраном смерти (Blue Screen of Death, BSOD), доступ к командной оболочке (cmd.exe или /bin/sh). Подслушивание означает выяснение действий других. Это может быть перехват пакетов, нажатий клавиш, чтение электронных сообщений.

В системе Windows под RootKit принято считать программу, которая внедряется в систему и перехватывает системные функции, или производит замену системных библиотек. Перехват и модификация низкоуровневых API (Application Programming Interface) функций в первую очередь позволяет такой программе достаточно качественно маскировать свое присутствие в системе, защищая ее от обнаружения пользователем и антивирусным программным обеспечением. Кроме того, многие RootKit могут маскировать присутствие в системе любых описанных в его конфигурации процессов, папок и файлов на диске, ключей в реестре. Многие RootKit устанавливают в систему свои драйверы и сервисы (они естественно также являются «невидимыми»).

Глава 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 Захват таблицы импорта

Одним из простейших способов захвата является захват таблицы импорта. Прежде чем какое-либо приложение сможет использовать функцию из какой-либо библиотеки, оно должно получить адрес этой функции. Как было отмечено ранее, большинство Win32-приложений для этого используют таблицу импорта. Для каждой библиотеки DLL, применяемой приложением, в исполняемом файле приложения на диске есть структура IMAGEIMPORTDESCRIPTOR. Эта структура содержит имя импортируемой библиотеки и два указателя на массивы указателей на структуры IMAGEIMPORTBYNAME, в которых содержатся имена импортируемых функций.

Когда операционная система загружает приложение, она читает структуры IMAGEIMPORTDESCRIPTOR и загружает в память программы все упомянутые там библиотеки DLL. Как только библиотека загружена, операционная система заполняет один из массивов, ссылавшийся ранее на IMAGE IMPORTBY NAME, действительными адресами функций из DLL.

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

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

Рис. 1

Такой захват - это достаточно мощная и в то же время простая техника. Конечно, она имеет свои недостатки. Захват такого типа довольно легко обнаружить. Хотя, с другой стороны, эта техника используется очень часто, и даже операционная система задействует ее в процессе, называемом продвижением DLL (DLL forwarding). Таким образом, очень сложно отличить захват, выполненный злоумышленником, от вполне легального и безобидного.

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

2.1.2 Захват функции путем непосредственной модификации ее кода

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

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

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

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

До-ХР SP2 Коды Операций Инструкции

55 push ebp

8bec mov ebp,esp

После-ХР SP2 Коды Операций Инструкции

Bbff mov edi,edi

55 push ebp

8bec mov ebp, esp

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

В том случае, если версия операционной системы более ранняя, чем Windows ХР SP2, нужно переписать 3-байтовый пролог и еще 2 байта какой-либо инструкции. В соответствии с этим руткит должен быть способен дизассемблировать начало функции и определить длину инструкций, для того чтобы безошибочно сохранить инструкции, затронутые командой перехода. Для более поздних версий операционной системы компания Microsoft облегчила нам работу. Пролог занимает ровно 5 байт. В действительности компания Microsoft сделала это для того, чтобы иметь возможность обновления своих продуктов без перезагрузки.

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

Руткит сохраняет оригинальные байты функции в месте, называемом трамплином (trampoline). Функция, в которую происходит передача управления после захвата, называется функцией обхода (detour function). Итак, функция обхода вызывает функцию-трамплин, которая в свою очередь передает управление приблизительно на шестой байт целевой функции. Когда целевая функция завершается, она возвращает управление в функцию обхода, где вы легко можете изменить выходные данные. Рисунок 2 иллюстрирует этот процесс. Исходная функция на этом рисунке - это функция программы, которая изначально производит вызов целевой функции.

Рис. 2

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 Захват в режиме ядра

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

Ядро расположено в верхней части виртуальных адресов оперативной памяти. В компьютерах архитектуры Intel х86 оно обычно располагается, начиная с адреса 0x80000000 и выше. Если же при загрузке был использован ключ / 3GB, который позволяет использовать программам 3 Гбайт виртуальной памяти, то ядро располагается, начиная с адреса 0хС0000000.

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

Захват таблицы дескрипторов системных служб

Исполнительная система Windows работает в режиме ядра и предоставляет службы поддержки для всех подсистем окружения: Win32, POSIX и OS/2. Адреса этих системных служб перечислены в структуре ядра, называемой таблицей диспетчеризации системных служб (System Service Dispatch Table, SSDT). Имея номер системной службы, можно получить ее адрес из этой таблицы. Другая таблица, называемая таблицей параметров системных служб (System Service Parameter Table, SSPT), содержит общий размер передаваемых параметров для каждой службы.

Таблица дескрипторов системных служб, KeServiceDescriptorTable, экспортируется ядром. В ней есть указатель на часть таблицы SSDT, содержащую информацию об основных системных службах, реализованных в библиотеке Ntoskrnl.exe и являющихся основной частью ядра. В таблице KeServiceDescriptorTable есть также указатель на SSPT. Таблица SSDT содержит адреса отдельных функций, экспортируемых ядром. Каждый адрес занимает 4 байта. Для того чтобы вызвать определенную функцию, диспетчер системных служб KiSystemService просто умножает идентификационный номер желаемой функции на четыре, получая при этом смещение адреса функции в таблице SSDT. Заметьте, что таблица KeServiceDescriptorTable хранит и количество служб. Это число используется для определения максимального смещения в таблицах SSDT и SSPT. Каждый элемент таблицы SSPT имеет размер один байт и задает размер данных в байтах, которые соответствующая функция из SSDT принимает в качестве параметров.

Существует еще одна таблица, KeServiceDescriptorTableShadow, которая содержит адреса служб GDI и USER, реализованных в драйвере Win32k.sys ядра;

Диспетчер системных служб включается инструкцией INT 2Е или SYSENTER. В этот момент процесс переключается в режим ядра. Приложение может вызвать диспетчер системных служб KiSystemService непосредственно или через одну из подсистем окружения. Если используется какая-либо подсистема окружения (такая, как Win32), тогда сначала вызывается одна из функций Ntdll.dll, которая в свою очередь помещает в регистр ЕАХ номер системной службы, а в регистр EDX - адрес параметров функции в адресном пространстве пользователя. Диспетчер системных служб сверяет количество параметров и копирует их из пользовательского стека в стек ядра. После этого происходит вызов одной из служб из таблицы SSDT в соответствии с номером, находящемся в регистре ЕАХ.

Итак, если руткит будет загружен в систему как драйвер устройства, он сможет изменить таблицу SSDT так, что вместо Ntoskrnl.exe или Win32k.sys будет вызвана его функция. В результате, когда любое приложение пользовательского уровня попытается обратиться к ядру, на самом деле оно будет обращаться к руткиту. Таким образом, возможно возвращать приложениям отфильтрованную информацию о системе, полностью скрывая свое присутствие и информацию об используемых ресурсах.

Отключение защиты памяти для SSDT

Некоторые версии Windows выпускаются с включенной защитой от записи в некоторые участки памяти. В Windows ХР и Windows 2003 это стало нормой. Последние версии Windows делают таблицу SSDT доступной только для чтения, так как маловероятно, чтобы обычным программам могло бы понадобиться вносить в нее какие-либо изменения.

Защита от записи может явиться вашего руткита серьезной проблемой, если нужно, чтобы руткит фильтровал данные, возвращаемые определенными системными вызовами. Если попробовать произвести запись в таблицу SSDT, к которой имеется доступ только для чтения, результатом окажется синий экран. Но этого можно избежать. Диапазон адресов памяти можно описать в виде списка дескрипторов памяти (Memory Descriptor List, MDL). Элемент списка MDL содержит стартовый адрес, идентификатор процесса-владельца, размер в байтах и флаги. Для изменения флагов в памяти прежде всего нужно извлечь нужную информацию из таблицы KeServiceDescriptorTable, экспортируемой ядром. Необходимо получить базовый адрес таблицы SSDT и количество служб, прежде чем вызывать MmCreateMdl. После этого нужно построить MDL из не выгруженной на диск области памяти.

Чтобы производить запись в эту область, руткит устанавливает флаг MDL_ MAPPED_TO_SYSTEM_VA. Далее производится блокировка MDL-страниц памяти при помощи функции MmMapLockedPages. Теперь сюда можно произвоить запись, не опасаясь синего экрана.

Пример скрытия процессов путем захвата SSDT.

В операционной системе Windows используется функция ZwQuerySystemlnformation, которая предоставляет различную информацию о системе. Например, программа taskmgr.exe задействует эту функцию для получения списка процессов. Тип возвращаемой информации зависит от параметра SystemlnformationClass. Для получения списка процессов он устанавливается в 5, как описано в Microsoft Windows DDK.

Подменив функцию ZwQuerySystemlnformation в SSDT, руткит захватывает исходную функцию и получает возможность фильтровать возвращаемую ею информацию.

На рис. 3 показан формат расположения записей о процессах в буфере, возвращаемом функцией ZwQuerySystemlnformation.

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

Рис. 3

Буфер содержит структуры _SYSTEM_PROCESSES и соответствующие им структуры _SYSTEM_THREADS. Наиболее важным элементом структуры _SYSTEM_PROCESSES является поле UNICODE_STRING, содержащее имя процесса. В структуре имеются также два поля типа LARGE_INTEGER, содержащие время, проведенное процессом в режимах ядра и пользователя. При скрытии какого-либо процесса, необходимо перераспределить время, потраченное этим процессом, на все оставшиеся процессы из списка, так чтобы все суммарное время соответствовало 100 % времени работы процессора.

Для скрытия процессов нужно подменить в SSDT функцию ZwQuerySystemlnformation на свою, которая фильтрует процессы и добавляет отработанное время скрываемых процессов процессу простоя (Idle).

В SSDT есть множество других полезных функций, которые также можно захватить.

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

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

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

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

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

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

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

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

Рис. 4. Изменение хода исполнения программы

На рисунке 4 показано, как руткит изменяет ход исполнения программы, внедряя в нее свой код.

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

Эта техника очень мощна и, как правило, позволяет легко ускользать от защитного программного обеспечения.

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

Чаще всего модификации подвергается именно пролог функции. Это легко объяснимо, так как пролог функции легко отыскать в памяти. Конечно, на этом не стоит останавливаться, модификации можно производить по всему телу функции на любой глубине. Чем дальше от начала функции изменения, тем сложнее их обнаружить. Некоторые программы обнаружения руткитов проводят проверку только первых 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. Все устройства очень отличаются друг от друга, хотя для всех них существует один общий принцип: рано или поздно, так или иначе запускается загрузочный код. Этот код и называется встроенной микропрограммой. Микропрограмма находится в энергонезависимой памяти (то есть она не стирается, когда система выключается). Если вы не знаете, с чего начать, начните с загрузочного кода.

...