В этой статье мы произведем разбор зловреда Trojan-Clicker.Win32.Whistler.a. Примечателен он тем, что является буткитом. А именно — заражает загрузочную область жесткого диска. Большая часть обзора будет посвящена реверсу именно этой компоненты трояна.
Весь функционал этого зловреда рассредоточен по нескольким файлам, которые изначально содержатся в дроппере, заливаемом на пользовательскую машину. Заражение системы начинается именно с дроппера. Он представляет собой довольно стандартный PE-файл, скомпилированный в Microsoft Visual Studio 5.0 (подсистема GUI). Код не зашифрован и не обфусцирован, следовательно, отлично поддается разбору. Упакованные данные содержатся в секции .rdata и в оверлее.
После запуска Whistler производит попытку обнаружить виртуальную машину VMWare с помощью метода RedPill. Он заключается в чтении данных по определенному порту и сравнению их с эталонным значением. При выполнении кода на реальном процессоре в пользовательском режиме (Ring 3) использование привилегированной инструкции «in» вызовет исключение, а на виртуальной машине… а на ней все зависит от алгоритма эмуляции.
Далее, в случае успешного прохождения проверки, с помощью APIфункции VirtualAlloc выделяется память, в которой происходит расшифровка внутреннего файла. После этого вызывается CreateThread с указателем на дешифрованный код. На этом функционал дроппера заканчивается — он остается ждать завершения только что запущенного потока с помощью WaitForSingleObject.
Таким образом, в памяти, выделенной динамически, выполняется совершенно иной файл, нежели тот, который присутствует на диске. В самом начале его работы вызываются проверки на наличие отладчика, различных программ для мониторинга и т.д. В частности, наличие знаменитого Process Explorer’а от Руссиновича прекрасно палится с помощью вызова FindWindowW("PROCMON_WINDOW_CLASS"), а о работающем TrueCrypt’е свидетельствует наличие устройства «TrueCrypt», что может быть проверено с помощью CreateFileW("\.\ TrueCrypt", …). После этого начинается самое интересное — взаимодействие с жестким диском напрямую. Прежде чем переходить к рассмотрению этого этапа, напомню читателям о том, как происходит загрузка компьютера.
Загрузка компьютера
После подачи питания на материнскую плату весь стартовый код BIOS’а копируется в оперативную память по старшим адресам с помощью специальной микросхемы. Далее процессор инициализируется определенными значениями регистров CR0, EDX, EFlags, IP. Регистр IP принимает значение FFF0h, и именно с этого адреса начинается исполнение стартового кода BIOS, который инициализирует всю аппаратуру, находит устройство загрузки и т.д. Значение сегментного регистра CS при этом — 0xF000. После того, как проверки увенчаются успехом (в частности, проверка на наличие сигнатуры 0xAA55 в конце сектора), загрузчик читает нулевой сектор харда и копирует его по адресу 7C00h.
Сектор — минимально адресуемая ячейка жесткого диска. Прочитать меньше, чем один сектор , невозможно. На большинстве винтов размер сектора составляет 200h байт, новые жесткие диски обладают большим размером сектора, но они пока не сильно распространены. А теперь отвечу на вопрос: «А как же процессор узнает о том, сколько логических дисков существует на компьютере, какую систему ему загружать и откуда?» Итак, нулевой сектор жесткого диска содержит так называемую «главную загрузочную запись» или, иначе говоря, MBR (Master Boot Record). Она целиком занимает весь сектор — 512 байт.
MBR содержит машинный код, исполняемый процессором, информацию о четырех разделах диска и сигнатуру 0xAA55 в самом конце. Исполнение начинается с нулевого смещения сектора. Структуру MBR можно описать следующим образом. Сигнатура используется загрузчиком для проверки корректности MBR, в случае неудачи работа компьютера приостанавливается. Каждый раздел также описывается отдельной структурой. Байт признака активности может быть равен либо 0, либо 0x80. Если он равен 0x80, то раздел считается активным, загрузчик считывает его первые 0x200 байт и передает туда управление. Поле «тип раздела» описывает форматирование конкретного раздела и может принимать множество значений (приведены не все возможные значения).
Таким образом, больше четырех разделов на одном жестком диске существовать не может. Однако же Windows позволяет делить диск хоть на двадцать частей — так в чем же дело? Оказывается, что расширенный раздел (код типа раздела — 7) помимо собственно содержимого раздела содержит еще и указатель на следующий раздел. Следовательно, образуется связанный список из расширенных разделов. Их количество ограничивается только свободным неразмеченным пространством. Подытожим все вышесказанное с помощью схемы (см. картинку «Схема разбиения жесткого диска на разделы с помощью MBR»). Таким образом, полный алгоритм загрузки компьютера следующий : код в MBR проверяет работоспособность жесткого диска, затем ищет раздел с выставленным признаком активности 0x80, просматривая таблицу разделов, и передает управление на нулевой байт последнего.
Следует отметить, что после включения компьютера процессор работает в режиме реальных адресов (real-address mode). Он значительно отличается от защищенного режима (protected mode), который используется при функционировании большинства современных операционных систем (Linux, Windows, FreeBSD и т.д.). В реальном режиме отсутствует страничная адресация, так называемые кольца защиты, обработка исключений, а регистры GDTR, LDTR, CR3 не используются.
Таблица векторов прерываний расположена по нулевому физическому адресу и заполнена самим BIOS’ом. Обращение к памяти происходит через пару «сегмент-смещение», которая преобразуется в физический адрес. Поясню на примере:
- Процессор пытается исполнить инструкцию mov eax, [1000:FFFF];
- Значение сегмента сдвигается влево на 4 бит — 0x1000 << 4 = 0x10000;
- Смещение складывается со сдвинутым сегментом и получается конечный физический адрес — 0x10000 + 0xFFFF = 0x1FFFF;
Вернемся к Whistler’у
После прочтения столь долгой и нудной теории ты, я думаю, созрел продолжить изучение нашего сегодняшнего героя. Итак, он переписывает MBR на свой собственный, обращаясь к устройству .PhysicalDriveX через функцию CreateFile. Потом он находит самый последний раздел и пишет свои данные в неразмеченную область, находящуюся за последним разделом. А именно — туда записывается оригинальный MBR, идентификационные данные Whistler’а, по которым можно будет определить факт заражения системы, и четыре PE’шника. Один из них — тот, что сейчас описывается. Другой — драйвер. Два последних — exe’шники, отвечающие непосредственно за функционал. На этом функциональность файла, исполняемого из памяти, заканчивается. Пришло время рассмотреть сам зараженный MBR.
Для его разбора я использовал бесплатную виртуальную машину Bochs for Windows со встроенным отладчиком. Она использует полностью программную эмуляцию. Ее интересной особенностью является возможность отладки виртуальной машины с самого старта компьютера. То есть она позволяет пройти под отладчиком весь MBR и загрузочный код системы и без проблем отладить стартовый код BIOS’а. Разумеется, это отладка не кода реальной железки, а всего лишь BIOS’а виртуальной машины, но оценить качественную картину загрузки компьютера помогает.
Итак, cначала парсится таблица разделов и находятся элементы, записанные в неразмеченную область, туда же и передается управление. Тут-то и начинается самое интересное — перехватывается прерывание int 13h, оригинальный MBR восстанавливается и на него передается управление. В перехватчике int 13h производится поиск сигнатуры из NTLDR в прочитанном фрагменте. Сверка сигнатуры видна на скриншоте: сначала производится поиск байта 0xB8 с помощью инструкции REPNE SCASB, а в случае успеха дальнейшее сравнение происходит с помощью CMP. Далее, если нужный фрагмент NTLDR’а найден, производится перехват функции BlLoadBootDrivers путем замены части инструкции. После выставления сплайсинга управление возвращается в систему.
Буткит получит управление только после вызова вышеупомянутой функции. Затем производится поиск базы ядра и сплайсинг инструкции, вызывающей функцию IoInitSystem. Перехват установлен таким образом, что буткит получит управление как сразу после вызова IoInitSystem, так и после ее завершения. Таким способом Whistler определяет, что система успешно проинициализировалась и загружает свой драйвер, упомянутый выше. Этот драйвер маппится в память и запускается как системный поток. Таким образом на запущенной инфицированной системе окажется работающий драйвер, образ и информация для которого отсутствует у ОС. На этом функциональность инфицированного MBR’а заканчивается, и в работу вступает драйвер.
Драйвер построен на основе Stoned Bootkit FrameWork, который бесплатен и находится под лицензией «European Union Public License». Основное его назначение — считывать из неразмеченной области харда файлы, которые несут «полезную нагрузку», и скрыто запускать их.
Работа с диском ведется при помощи объекта .physicaldrive0, а вот запуск PE’шников происходит весьма любопытным способом — при помощи APC. APC — Asynchronous Procedure Call — функция, которая нарушает естественный ход выполнения потока. Когда планировщик Windows переключает контекст на поток, он смотрит на наличие APCфункций в очереди потока, и если они есть, то вызывает сначала их, а потом уже и сам поток. Первым делом драйвер инжектит шеллкод в winlogon.exe, используя KeStackAttachProcess для присоединения к процессу. Потом с помощью функции KeInitializeApc инициализируется сама APC-функция, которая затем добавляется в очередь с помощью KeInsertQueueApc, что обеспечивает запуск шеллкода в контексте системного процесса. Этот код запускает два оставшихся файла, которые были сохранены на диск драйвером по следующему пути: «\??C: System Volume InformationMicrosoft».
Так как насчет функционала?
Пройдя столь длинный путь по разбору Whistler’а, я подошел к самому главному — вредоносному функционалу, то есть тому, ради чего и делался зловред. Как видно из названия, он кликает по разнообразным ссылкам, увеличивая им рейтинг. Сами файлы представляют собой обычные приложения, написанные в Microsoft Visual Studio. Все данные хранятся в оверлее за последней секцией. Сдампив адресное пространство процесса, я получил просто россыпь урлов, которые указывают на страницу banner3.php на разных сайтах.
Заключение
Вот и все. Пожалуй, еще стоит отметить, что этот зловред не будет работать на последних операционных системах семейства Windows, в частности, на Windows 7, так как там несколько иначе построена загрузка системы. А вот на Windows XP все прекрасно отработает. Кстати, для анализа этого вируса помимо виртуалки Bochs я еще использовал связку VMWare и PETools для получения дампа и, конечно же, Hiew для визуального просмотра. Дизассемблер IDA в комплекте с Hex-Rays просто незаменим при детальном анализе драйверов и незащищенных PE'шников. Кстати, можешь попробовать открыть свой жесткий диск, начиная с нулевого сектора, просто запустив Hiew и передав ему в качестве параметра командной строки .physicaldriveX.
