Казалось бы, что о user-mode руткитах уже все давно сказано, и добавить тут нечего. С распространением зловредных драйверов все внимание антивирусных специалистов и хакеров переключилось туда, поэтому ring-3, по крайней мере, на три года остался практически без внимания… [...]]]> Публикую статью автора priv8v. Мнение редакции может не совпадать с мнением автора и т.д. и т.п.

Казалось бы, что о user-mode руткитах уже все давно сказано, и добавить тут нечего. С распространением зловредных драйверов все внимание антивирусных специалистов и хакеров переключилось туда, поэтому ring-3, по крайней мере, на три года остался практически без внимания… А зря. Появились новые технологии, новые методы защиты и нападения. Если задуматься, то изменились даже некоторые цели у конкретных технологий, поменялось поведение зловредов на компьютере, изменился и их внешний облик — теперь некоторые из них имеют красивые кнопочки и «ищут вирусы». На этой ноте стоит прекратить ностальгировать и приступить непосредственно к изложению темы.

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

• зачем применять сегодня user-mode руткиты?
• целесообразно ли это?
• а они часом не вымерли?

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

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

• в статье не будет рассмотрен обход эмуляторов и поведенческих анализаторов;
• обход антивирусного эвристического/сигнатурного детекта также не рассматривается;
• основное внимание будет уделено сплайсингу;
• в статье будет использована анти-script-киддис защита;
• панды бамбук не курят, они им питаются;

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

Сложность написания

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

Обход HIPS

Каждая вторая антивирусная компания под «HIPS» понимает что-то свое (несмотря на то, что расшифровка аббревиатуры у всех одинаковая). У кого-то вообще этой технологии нет, у кого-то есть только галочка в настройках (типа «Да, по умолчанию использовать эту супер-HIPS»), но у многих эта технология присутствует и включает в себя анализ поведения и эмуляцию кода. Говоря простым языком, могут быть проблемы с установкой драйвера, т.к некоторые комбайны спрашивают совета у пользователя даже если драйвер пытается ставить доверенное приложение. Если вы не найдете какого-нибудь неведомого способа установки драйвера, то ядра вам не видать как своих ушей (и зеркало при проникновении в ring-0 не поможет). Хотя в последнее время и наблюдается некий мнимый упадок технологий в этой области, связанный с прогибом антивирусов под знания среднего юзера.

«Бельмо на глазу»

Если вы будете использовать какие-то давно известные и проверенные rootkit-технологии, то обязательно будете обнаружены даже простеньким антируткитом (например, пандой). Поэтому без чего-то нового наедятся скрыться от Gmer’a, или AVZ с его километровым логом, просто бессмысленно.

Права на установку драйвера

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

Различия систем

Прежде всего, это связано с увеличением популярности Windows 7 и х64-систем.

Современные антируткиты можно условно разделить на две категории:

• Рассчитанные на продвинутых пользователей. Это целые комбайны для убийства и извращений. Они показывают перехваты с подробной информацией о них, позволяют их снимать, могут работать с реестром, файловой системой, причем сами делают их разбор. В качестве примера можно привести Gmer или XueTr.
• Рассчитанные на User Classic — как правило, имеют пять кнопок, включая «выход» и «справка», еще две это «найти» и «уничтожить», а пятая кнопка не всегда и имеется. Подобные утилиты ничего не показывают пользователю, просто ищут скрытые на их взгляд файлы/ключи/процессы и предлагают их прибить. Образчиком этой категории может быть антируткит от Panda.

Пару слов необходимо сказать пару общих слов о том, какой антируткит, где ищет и что отображает пользователю: Rootkit Unhooker и Gmer просматривают на предмет хуков все процессы в системе и ищут перехваты во всех функциях (хотя могли бы проверять только критичные) – находят даже перехват MessageBox’a. Идентифицируют тип перехвата достаточно четко (…Jump, PushRet и т.д) и указывают полный путь до библиотеки с кодом перехватчика. С помощью XueTr можно получить аналогичную информацию, только метод перехвата будет описан не столь подробно (inline, и все тут…).

Но анализировать перехваты в ring-3 умеют не все антируткиты (зачем руки-то марать?), к примеру, Vba32 AntiRootKit является одним из лучших на сегодняшний день антируткитов и находит хитрые заковырки в ядре, но в ring3 не видит ничего. Аналогично и DwShark.

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

1) Антируткит, как правило, не может распознать какой перехват «хороший», а какой нет. Под «хорошим» имеется в виду перехват, установленный каким-либо вполне законным приложением (например, антивирус). И весь груз ответственности за вынесения вердикта свой/чужой остается на долю пользователя, который это делает либо сам, либо с помощью коллективного разума на форуме. Именно поэтому имеет право на жизнь такой глупый способ маскировки как расположение внедренной dll по похожему на лигитимный пути, а не в папку темп или в system32 с рандомным названием. Чем плохо: C:\Program Files\Agnitum\нормальное_имя.dll – подсмотреть пути, подсмотреть названия и все. При этом к библиотеке можно даже через редактор ресурсов прилепить описание и в отчете антируткита будет видно именно оно.

2) Перехват можно сделать целевым – в определенном процессе/процессах. Или наоборот – внедряться во все процессы, кроме строго определенных. Благодаря этому про какие-то скрытые объекты антируткит не будет и знать – если в его приложение-дразнилку ничего не внедрено и не перехвачено, то и отличий от того, что спущено свыше (с уровня ядра, хотя правильнее будет сказать «сниже», но такого слова нет) с уровня ядра не будет, то есть в системе все будет видно со всех уровней, а раз ничего антируткит не нашел скрытого, то и панику поднимать не будет. Естественно, не защита от всех антируткитов, Gmer’а этим не смутить.

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

Перехватываемая API-функция: jmp good_library.address

good_library.address: jmp our_evil_library.address

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

4) Насколько много приложений работает с системой не прямыми вызовами API-функций, а, используя функции языка программирования, на котором они написаны? Много. Вызов API-функции несомненно будет, но не сразу, поэтому и перехват можно делать в этой самой надстройке. Наиболее наглядный пример можно привести из языка С: при перехвате функции printf в библиотеке msvcrt.dll перехват не углядел ни Gmer, ни Rootkit Unhooker, при этом XueTr гордо опознал перехват и даже имя перехваченной функции. Надеюсь, что данная мысль понятна без дальнейших примеров с другими языками.

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

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

Как вы уже догадались, вектор атаки будет направлен как раз на сделанное допущение:

• Библиотека патчится не только в памяти, но и на диске (предварительно скопированная).
• После отключения WFP оригинал заменяется патченной. В зависимости от того, как будет реализовано отключение WFP и как выполнен перехват (в скольких процессах, как сделана обработка и т.д) библиотека заменяется на патченную или только на время работы антируткита, или на относительно вечно (здесь можно послать привет установке глобальных перехватов в user-mode).

6) Если jmp отодвинуть от начала функции, к примеру, байт на 30, то Gmer все равно будет видеть перехват и правильно его отображать. Rootkit Unhooker перехват также будет видеть, но имя функции не отображает (будет показывать dll_name.dll+xxx).
Следует помнить, что Gmer ругается даже при изменении одного байта в функции.

7) Замаскировать перехватчик. Если адрес нашего обработчика на начале функции класть в стек, а потом выполнять ret или просто поставить на него jmp, то не стоит удивляться, если антируткит покажет, куда ведет перехват, но если адрес немного обработать (прибавить, отнять, поболтать по регистрам), то это даст результат – перехватчик не будет определен.

Выше были рассмотрено пассивное противодействие антируткитам, но известно, что лучшая защита это нападение…

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

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

Рассмотрим пару приемов этого противостояния.

Блокировка запуска и работы

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

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

Так что все достаточно интересно.

Прекращение работы

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

int HideXueTr = 0; // флаг было ли уже скрыто окно или нет
  // ..... code.... 
if (!HideXueTr) {
  HWND XueTr = FindWindow (NULL, "XuеTr 0.39");
    if (XueTr) {
                  MessаgeBox (0, "XueTr найден и будет скрыт!", "OK", MB_OK);
                  ShоwWindow (XueTr, SW_HIDE); // скрываем окно
                  HideXueTr = 1; // взводим флаг
               }
      }

В данном примере показана блокировка уже активного XueTr: находится по имени главного окна, после чего окно скрывается, причем только один раз. Пропажа окна будет воспринята пользователем как «глюк», и XueTr будет запущен повторно, при этом он больше скрываться не будет в виду того, что никакие перехваты он показать уже не сможет, все данные поступают в скрытое окно, а в новом можно будет только обозреть сервисы и файловую систему. Антируткит работает, но показывает «местами», что будет воспринято пользователем как несовместимость с его ОС, глюками, неумением работать с этой программой и т.д, но никаких подозрений у него не возникнет.

При глюках обычно тянет на философию, чем и предлагаю заняться. Поразмышляем…

В логике работы всех антируткитов присутствует следующая аксиома: если скрытый — значит руткит. Соответственно найденный скрытый объект выделяется всеми цветами радуги (в данном случае для меня все цвета это красный) и уведомляет пользователя о том, что руткит найден. Далее в работе антируткитов имеется небольшая, но существенная разница, о которой мы уже говорили выше, а именно подробность отчета. Те утилиты, которые дают подробный отчет, покажут все что смогут (перехваты, перехватчик) и сам скрытый объект выделят, а те, что попроще в общении с пользователем просто покажут руткит и на выбор предложат: «Удавить его? Утопить его? Стереть в порошок?». В целом, подход, конечно, правильный, но при большом желании и везении можно использовать его слабое место, ведь не все то золото, что блестит — не все то руткит, что скрывается, тем более в данном случае между словами «скрывается» и «скрыт» нет никакой разницы. По сути, руткиту (назовем так код, который что-то скрывает) нет никакой разницы, что скрывать — что ему сказали прятать, то он и прячет. Скажут скрывать readme.txt, и будет это делать. К чему это? А все к тому… В расчете на применение антируткита или при нахождении его активности (например, процесса) в системе, можно скрыть что-то специально для него. Возьмем и легким движением руки сделаем процесс/файл антивируса злостным руткитом, причем сам антивирус будет сильно удивлен, если вдруг прознает это, а вот антируткит будет этому только рад. Раз руткит — приговор «Расстрел!». Особым цинизмом будет скрытие процесса/файла самого антируткита от него же. McAfee Rootkit Detective при обнаружении скрытого процесса предлагает только два способа борьбы с ним — завершить или переименовать. При скрытии его самого, прекрасно себя переименовывает. Панда также не ожидает, что ему подложат такую свинью и предлагает два варианта: удалять руткит и не удалять руткит. При выборе первого варианта мишка с успехом самовыпиливается: после перезагрузки бамбуковый мишка начинает использовать бамбук по назначению.

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

Закончить статью хотелось бы пожеланиями разработчикам антируткитов:

1) Еще больше рандомизировать (а тем, у кого этого нет — сделать) имена файлов/путей/окон/размера/и т.д.

2) Сделать более читабельной информацию об установленном перехвате:

• улучшить распознавание имен функций;
• информацию о перехвате выводить не только набором байт, но и мнемоникой вида jmp xxx, а при невозможности определить четко перехватчик, выводить мнемоникой весь код установленного перехвата, например:

xor eax, eax
mov eax, xxx
push eax
ret

3) Выполнять сравнение библиотек в system32 и в dllcache. Для повышения точности определения чистоты библиотеки можно носить с собой в массиве т.н базу чистых — хэш суммы проверяемых библиотек с разных систем (хотя бы популярных). Размер базы будет следующим: количество_проверяемых_в_системе_библиотек * количество_популярных_систем.

4) Выполнять поиск перехватов не только в своем процессе/некоторых, а во всех.

5) Научиться (тем, кто не умеет) опознавать перехваты, установленные антивирусными программами. Тут, собственно, три основных пути:

• иметь на борту базу чистых;
• проверять подписи (хотя в свете последних событий тут следует быть осторожным);
• подгружать базу чистых из «облака»;

6) Для получения слепка файлов/процессов/ключей из user-mode для последующего сравнения со списком из ядра, пользоваться не консольной программой, а чем-то имитирующим обычную программу — нужно хотя бы user32.dll подгружать…

Документацию можно загрузить в двух форматах, как обычный апдейт и в формате .chm:

WDKDocs_08072009.exe

wdkchm_08072009.exe

We are pleased to announce the release of the Windows Driver Kit Version 7.0.0. This latest production release of the WDK is now available for download on Connect.

In this WDK release, the WDK is delivering the latest updates to create drivers for: • Windows 7 • Windows Vista • Windows [...]]]>

Hello WDK Program Participants:

We are pleased to announce the release of the Windows Driver Kit Version 7.0.0. This latest production release of the WDK is now available for download on Connect.

In this WDK release, the WDK is delivering the latest updates to create drivers for:
• Windows 7
• Windows Vista
• Windows XP
• Windows Server 2008 R2
• Windows Server 2008
• Windows Server 2003

A few of the highlights in this release are:
• A number of additional headers
• Update of KMDF and UMDF to Version 1.9
• Co-installers for WinUSB v2 added
• Update of DIFx redistributable files
• Addition of Offreg DLLs
• Sample additions in 1394, Audio, Biometric, Build, Bus, File System, HID, Input, Network, Print, Sensors, Storage, WMI, WPD, and general samples
• Tools added in Biometrics, Bluetooth, Driver Coverage, Enhanced Storage, Test tools, Networking, Print and general tools
• Improvements to PFD and Static Driver Verifier
• Updated documentation

This release is available as a download only. The image posted is a DVD image and the recommended approach is to download and burn a DVD.

Thank you for your continued support!

Regards,
The Windows Driver Kit (WDK) team

Доступен для загрузки на Windows Connect

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

В режиме пользователя можно использовать функцию ExitWindowsEx (она ведет в NtShutdownSystem):

BOOL WINAPI ExitWindowsEx(
                                       __in UINT    uFlags,
                                       __in DWORD dwReason
);

Все достаточно подробно описано в MSDN и, конечно, не забываем про включенную Shutdown привилегию.

Давайте рассмотрим варианты, которые нам доступны из режима ядра. Один из них — это использование функции NtShutdownSystem. Конечно, она недокументированная. Реализация для Windows XP выглядит так (вот такой забавный switch, видимо из-за оптимизаций):

NTSTATUS __stdcall NtShutdownSystem(SHUTDOWN_ACTION Action)
{
        POWER_ACTION SystemAction;
 
        if ( Action )
        {
                if ( Action == 1 ) // ShutdownReboot
                {
                        SystemAction = 5; // PowerActionShutdownReset
                }
                else // ShutdownPowerOff
                {
                        if ( Action != 2 )
                                return STATUS_INVALID_PARAMETER;
                        SystemAction = 6; // PowerActionShutdownOff
                }
        }
        else // ShutdownNoReboot
        {
                SystemAction = 4; // PowerActionShutdown
        }
 
        return NtSetSystemPowerState(SystemAction, PowerSystemSleeping3, 0xC0000004u);
}

typedef enum _POWER_ACTION {
        PowerActionNone            = 0,
        PowerActionReserved,
        PowerActionSleep,
        PowerActionHibernate,
        PowerActionShutdown,
        PowerActionShutdownReset,
        PowerActionShutdownOff,
        PowerActionWarmEject
} POWER_ACTION, *PPOWER_ACTION;

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

Следующий вариант — это использовать функцию HalReturnToFirmware. Она также описана в MSDN.

VOID HalReturnToFirmware(IN FIRMWARE_REENTRY Routine);

На вход функция может принимать параметр HalRebootRoutine, что нам собственно и нужно. Честно говоря, меня смущает то, что написано в MSDN:

Requirements

Versions: Available in Microsoft Windows Server 2003 and Windows XP.

DLL: Requires Hal.dll.

Под рукой у меня нет Hal.dll от Windows 2000, так что проверить экспортируется ли она или нет, я не могу, а память меня подводит.

Третий вариант — это спровоцировать BSOD. Шучу, шучу, но близко к правде. Вызовем KeBugcheckEx с параметром POWER_FAILURE_SIMULATE. KeBugcheckEx — это обыкновенная обертка над KeBugcheck2:

int __stdcall KeBugCheck2(int BugCheckCode, )
{
 
        if ( BugCheckCode == POWER_FAILURE_SIMULATE )
        {
                KiScanBugCheckCallbackList();
                HalReturnToFirmware(3); // HalRebootRoutine
        }
}

Знакомая картина, но помнится мне, что на каких-то системах вместо перезагрузки я получал самый натуральный BSOD с POWER_FAILURE_SIMULATE. Однако поехали дальше.

Мне, как любителю минимализма хотелось чего-нибудь быстрого, без проверок. Хоп и готово. Не знаю, что может быть быстрее этого:

WRITE_PORT_UCHAR( (PUCHAR )0x64, 0xFE ); // пишем RESET
                                         // в контроллер клавиатуры

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

Кто какие способы знает еще?

С:\path1\path2\path3>build -g BUILD: Compile and Link for x86 BUILD: Loading c:\winddk\6001\build.dat… BUILD: Computing Include file dependencies: BUILD: Start time: Fri Feb 06 [...]]]> Рано или поздно драйверописатель сталкивается с необходимостью использовать в своем проекте чужой код. Обычно, для сборки драйвера используется утилита BUILD, идущая в поставке WDK. Буквально недавно я столкнулся с очевидной проблемой данного инструмента:

С:\path1\path2\path3>build -g
BUILD: Compile and Link for x86
BUILD: Loading c:\winddk\6001\build.dat…
BUILD: Computing Include file dependencies:
BUILD: Start time: Fri Feb 06 15:50:51 2009
errors in directory С:\path1\path2\path3

Ignoring invalid directory prefix in SOURCES= entry: D:\somepath1\somepath2\somepath3\somepath4\somepath5\file.c

Поиск в гугле вывел меня на ветку форума OSR Online:

«Welcome to the wonderful world of BUILD. It can only deal with source code in the same or parent directory of the «sources» file. It cannot use source files from arbitrary locations.»

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

1. Чужой код должен быть реализован в виде статической библиотеки. У этого способа есть как очевидные плюсы, так и очевидные минусы. Одним из минусов я считаю то, что разработчику, который пишет код для вас, придется часто собирать эту самую библиотеку или это должна делать build-машина.
2. Использовать преимущества современных систем управления версиями. Проблема решается выкачиванием нужного проекта в директорию, которая доступна инструменту BUILD. Свою проблему я решил именно так. Конечно, не стоит забывать и о синхронизации выкаченных файлов.

Иногда на форумах появляются вопросы, в которых люди спрашивают можно ли управлять инструментом BUILD. В MSDN есть отдельный раздел, посвященный этой утилите: Win32 and COM Development -> Windows Driver Kit -> Driver Development Tools -> Tools for Building Drivers -> Build. Подраздел Build Utility Macros самый интересный.