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

Насколько вообще оправдано [...]]]> Ни для кого не секрет, что в некоторых легальных продуктах используются руткит-технологии.

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

Насколько вообще оправдано использование руткит-технологий в легальном программном обеспечении? Насколько при использовании таких технологий в легальных продуктах велик риск компрометации операционной системы и пользовательских данных? Насколько тонка грань между легальными и киберкриминальными методами?

Дальше

Казалось бы, что о 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 подгружать…

Для дальнейшего понимания сути поста надо запомнить [...]]]> Пришлось мне тут анализировать один элементарный руткит, никак не срасталось у нашего анти-руткита кое-что с ним. Ерунда в принципе, бага не критичная, но разобраться все-таки стоило. В последнее время не часто выпадает возможность проанализировать что-либо, но тут повезло, можно немного отвлечься от процесса исследования/кодинга.

Для дальнейшего понимания сути поста надо запомнить то, что дата компиляции дроппера — 27 февраля 2011 года, т.е. сэмпл далеко не старый.

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

Вот такой код я обнаружил в драйвере:

char __cdecl IsDebug()
{
  UNICODE_STRING DestinationString; // [sp+4h] [bp-Ch]@4
  PVOID Object; // [sp+Ch] [bp-4h]@4
 
  if ( KdDebuggerEnabledAddr && *(_BYTE *)KdDebuggerEnabledAddr )
    return 1;
  RtlInitUnicodeString(&DestinationString, L"\\Driver\\NTICE");
  if ( !ObReferenceObjectByName(&DestinationString, 0x40u, 0, 0x1F01FFu, IoDriverObjectType, 0, 0, &Object) )
  {
    ObfDereferenceObject(Object);
    return 1;
  }
  return 0;
}

Способ, основанный на проверке переменной KdDebuggerEnabled, известен очень давно, однако, проверка на наличие в системе активного отладчика Soft(Win)Ice (наличие драйвера NTICE) — это что-то из ряда вон выходящее. Неужели авторы думают, что антивирусные лаборатории до сих пор используют этот устаревший инструмент?

Что ж, живы еще олдскул разработчики в родных селениях!

Мешать антивирусному продукту можно различными способами. Можно использовать руткит-технологии [...]]]> Борьба с вредоносными программами осложнена не только тем, что их необходимо обнаружить, но и тем, что после обнаружения необходимо провести корректное лечение найденного вредоносного кода и его модулей. Детектируемые объекты совершенно не желают быть обнаруженными и уничтоженными, поэтому они активно сопротивляются лечению.

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

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

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

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

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

Авторы данного руткита подошли к вопросу о перепроверке MBR с интересной стороны. На ранней стадии загрузки операционной системы запускается поток в режиме ядра, который в цикле проверяет наличие в памяти системного процесса explorer.exe и ожидает его завершения. После инициации перезагрузки операционная система завершает все процессы, в том числе и explorer.exe. Схематично этот код выглядит так:

NTSTATUS InitThreadWithExplorer(...)
{
        // выделяем память под MBR
        status = AllocateAndZeroMemory( &g_MainMbrBuf, 512, 0, ' kdD' );
 
        // читаем зараженный MBR в глобальный буфер
        status = SendIrpMjRead( g_MainMbrBuf ); 
 
        // запускаем поток, который находит explorer.exe и ждет
        status = RunSystemThread( FindExplorerWaitAndCallOnReboot, ... );
}
 
NTSTATUS FindExplorerWaitAndCallOnReboot(...)
{
        // запускаем цикл поиска explorer.exe
        do
        {
                explorerpid = ReturnProcessPidByName( L"explorer.exe" );
 
                // если найден explorer.exe, то выходим из цикла
                if ( explorerpid )
                        break;
        } while(...);
 
        // получаем объект процесса explorer.exe по его идентификатору
        status = PsLookupProcessByProcessId( explorerpid, &pProcess  );
 
        // ожидаем завершения процесса explorer.exe
        KeWaitForMultipleObjects( 2, &Objects, WaitAny, 0, 0, 0, 0, 0 )
 
        // если explorer.exe завершился, то вызываем функцию проверки MBR
        CallOnReboot(...);
}

Функция CallOnReboot сравнивает текущий MBR с эталоном (зараженной загрузочной записью). Делается это для того, чтобы на момент перезагрузки системы восстановить вылеченную антивирусом загрузочную запись:

NTSTATUS CallOnReboot(...)
{
        pMBR = 0;
 
        // выделяем память под MBR
        status = AllocateAndZeroMemory( &pMBR, 512, 0, ' kdD' );
 
        // читаем MBR
        status = SendIrpMjRead( pMBR );
 
        i = 0;
 
        // запускаем цикл проверки
        do
        {
                k = i;
                l = i;
 
                // если какой-либо байт MBR отличается, то выходим из цикла
                if ( *(_BYTE *)(pMBR + i) != *(_BYTE *)(g_MainMbrBuf + i) )
                        break;
 
                k = i++ + 1;
 
        } while ( l < 432 );
 
        // если был найден отличающийся байт
        if ( k < 432 )
        {
                // копируем в pMBR зараженный MBR
                memmove( pMBR, g_MainMbrBuf, 432 );
 
                // перезаписываем вылеченный MBR
                status = SendIrpMjWrite( pMBR );
        }
}

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

Оригинал