Самая полная история буткитов

Антивирусы 90-х очень серьезно относились к проблеме буткитов. Их авторы советовали не забывать дискету в дисководе А:, они всегда проверяли этот диск перед выключением компьютера. Внезапно "загрузочные вирусы" из прошлого в нашем объективном настоящем снова оказались на коне! Посмотрим, какого уровня развития они сейчас достигли.

Первооткрыватели жанра

Одним из первых вирусов для платформы IBM PC, работающих в среде MS-DOS, был Brain, созданный в 1986 году. Вирус Brain был не файловым, а загрузочным — он инфицировал 5-дюймовые дискеты, так как винчестеры тогда еще не были широко распространены. После заражения вредоносный код постепенно заполнял все свободное пространство дискеты, так что использовать ее становилось невозможно. Авторы Brain — братья Басит Фарух Алви и Амджад Фарух Алви из Пакистана, которые решили написать программу для защиты своих медицинских программ от пиратов. Они даже разместили в коде программы свои адреса и телефоны — чтобы получить средства удаления Brain.

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

В 1987 году из-под пера одного студента из Новой Зеландии вышел очередной вирус, заражающий MBR дискет и жестких дисков. Название ему дали Stoned, так как при загрузке компьютера вирус в одном случае из восьми выводил сообщение: «Your PC is now Stoned!» — «Ваш компьютер сейчас балдеет!». Кроме того, внутри кода вируса содержался призыв к легализации марихуаны (Legalise Marijuana). Stoned в начале 90-х годов долгое время беспокоил сисадминов по всему миру. Сам вирус по нынешним меркам был совсем маленьким — всего 512 байт (один сектор). Оригинальный сектор сохранялся в другом месте диска, его расположение было разным для дискеты и винчестера. В процессе работы перехватывалось прерывание 13h (дисковые операции BIOS), что позволяло определять моменты работы ОС с дискетой и заражать ее в это время. Тогда никто не мог предполагать, что спустя двадцать лет идеи, реализованные в Brain и Stoned, обретут свое второе рождение в виде буткитов — вредоносных программ, скрывающих свое присутствие в недрах операционной системы, получая управление до ее загрузки. Мало того, один из концептуальных проектов так и называется в честь своего предшественника — Stoned bootkit.

От концепта до «серийного» образца

Появлению in the Wild первых oбразцов malware, использующих технику получения управления до момента загрузки Windows, предшествовали несколько концептуальных наработок. Во-первых, это проект BootRoot (работал на системах Windows 2000/XP), представленный на конференции Black Hat USA 2005 Дереком Сёдером (Derek Soeder) и Райаном Пермехом (Ryan Permeh) из компании eEye Digital Security. Во-вторых — работа Vbootkit (демонстрация работы на Vista RC1/RC2) от Найтина и Вайпина Кумаров (Nitin и Vipin Kumar), индийских исследователей систем безопасности из компании NVlabs. Доклад о Vbootkit был представлен на конференциях Black Hat и Hack in the Box в 2007 году и демонстрировал возможность обхода защитных механизмов ОС Vista — проверку цифровых подписей загружаемых драйверов.

«Классическим» представителем буткитов принято считать Mebroot — вредонос, первые штаммы которого были обнаружены антивирусными компаниями в конце 2007 года. Mebroot использовал многочисленные заимствования из проекта BootRoot. Анализ первого поколения Mebroot (version 0) показал, что ботнет на его основе работал в тестовом режиме, о чем свидетельствует большое количество отладочных сообщений, отправляемых на управляющий сервер. Как отмечают некоторые реверсеры, в этой версии отчетливо прослеживалось использование при программировании метода copy-paste (присутствие некоторого количество багов) без четкого представления о работе отдельных участков кода. Несмотря на ошибки, Mebroot без колебаний можно отнести к разряду hi-tech-вредоносов.

В интернете Mebroot часто называют Sinowal, тогда как Sinowal (aka Torpig или Anserin) — известное с 2005 года семейство троянских программ, на базе которых формировался ботнет. Главная цель этого ботнета — кража информации для организации несанкционированных банковских операций. Так что Mebroot — это загрузчик Sinowal.

Устанавливал Mebroot дроппер размером от 250 до 350 Кб в ранних версиях и до 430 Кб в более поздних. Ранняя версия дроппера заражала жесткий диск спустя 20 минут, а спустя еще 20 вызывала перезагрузку ОС. Прямой доступ к диску в этой версии осуществлялся стандартными функциями WinAPI, а именно вызовом CreateFile с открытием устройства \Device\Harddisk0\DR0 (в более поздних версиях — \??\RealHardDiskN и \??\PhysicalDriveN). Причем прямой доступ к диску осуществлялся из ring 3 (не ring 0!) при наличии прав администратора. Начиная с висты, прямой доступ к диску из пользовательского режима был заблокирован, и Mebroot version 1, активно распространяемый в феврале 2008-го уже в рабочем режиме, для записи использовал загрузку собственного драйвера, выполнявшего роль переходника к системному драйверу disk.sys.

Компоненты буткита размещались в следующих местах диска:

• сектор 0 — загрузчик;
• сектор 60 — патчер файлов ОС;
• сектор 61 — код, отвечающий за загрузку вредоносного драйвера;
• сектор 62 — оригинальная MBR из сектора 0;
• последние неиспользуемые сектора (около 650) — вредоносный драйвер.

Инициализация Mebroot при перезагрузке ОС происходила в несколько этапов (см. рис. 1):

Другие статьи в выпуске:

Хакер #176. Анонимность в интернете

• Содержание выпуска
• Подписка на «Хакер»-60%

1. Загрузчик выделял 2 килобайта памяти и перемещал свой код с адреса 0x7C00 в 0x0000.
2. Содержимое секторов 60 и 61 загружалось в выделенную область памяти.
3. Обработчик прерывания 13h перехватывался (устанавливался в адрес 0x004D).
4. По адресу 0x7C00 загружалась оригинальная MBR из сектора 62, и управление передавалось ей.
5. Перехватчик прерывания 13h отслеживал момент загрузки модуля osloader (часть ntldr) путем поиска определенной сигнатуры и модифицировал его.
6. Пропатченный osloader выполнял шелл-код (сектор 60), который искал и подменял в ntoskrnl.exe функцию nt!IoInitSystem.
7. Пропатченный ntoskrnl.exe выполнял шелл-код (сектор 61).
8. Шелл-код в ntoskrnl.exe выполнял загрузку вредоносного драйвера, хранившегося в последних секторах.

Mebroot довольно успешно скрывал свое присутствие в системе от антивирусных программ, так как не производил никаких изменений в файловой системе и реестре, за исключением сохраненной в зашифрованном виде полезной нагрузки. Она скачивалась вредоносным драйвером, реализующим скрытый канал передачи данных на основе перехвата функций NDIS драйвера сетевой подсистемы, что позволяло успешно обходить файрвол. Кроме того, драйвер отвечал за механизмы сокрытия и самозащиты, перехватывая функции две функции из disk.sys: IRPMJREAD и IRPMJWRITE. Первая позволяет скрывать истинное содержимое используемых буткитом секторов жесткого диска при их чтении, а вторая предотвращала перезапись MBR.

Для взаимодействия с управляющими серверами, кроме жестко заданного имени, использовался механизм динамического формирования доменных имен (DGA — Domain Generation Algorithm). В качестве исходных данных бралась текущая дата, получаемая из системы, а в поздних версиях — путем парсинга временных меток в ответах серверов Google. Канал передачи данных шифровался. Полезная нагрузка представляла собой зашифрованный контейнер, содержащий две DLL и инструкции, в какие процессы подгружать вторую из них (первая внедрялась в процесс services.exe). Контейнер подвергался расшифровке, затем снова шифровался другим ключом и сохранялся в каталоге %System% в виде файла, имя которого выбирается из имеющихся в этом каталоге файлов, а расширение случайное. DLL, внедренная в процессы браузеров, на лету модифицировала HTML-страницы банковских сайтов (путем внедрения iframe и jscript) и перехватывала банковские реквизиты доступа (логины и пароли), которые опять-таки в зашифрованном виде отправлялись на серверы злоумышленников.

По ходу развития версий Mebroot видно, что его разработчики пристально следили за выпуском средств лечения от производителей антивирусов, анализировали используемые методы обнаружения и оперативно реагировали выпуском новых версий, снова невидимых для антивирусов и с апгрейдом алгоритмов самозащиты. Так, в версии марта 2008 года перехватывались уже все функции из disk.sys, а за их изменением следил отдельный поток (watchdog). Если какая-либо антивирусная утилита пыталась «вернуть все как было», перехваты восстанавливались и диск заражался повторно.

В апреле 2009 года Mebroot уже освоил и новомодную на тот момент Windows Vista.

И снова концепты

Детальный анализ кода Mebroot можно найти на сайте stoned-vienna.com авторства Питера Клайснера (Peter Kleissner), который, видимо, под впечатлением от обнаруженного, решил замутить свой буткит с блекджеком и шлюхами, в смысле — принялся за разработку своего проекта Stoned Bootkit, представленного на Black Hat USA 2009. Сам Питер Клайснер утверждает, что его проект носит чисто исследовательский характер и помогает сотрудникам антивирусных лабораторий разрабатывать новые методы противодействия таким видам малвари. В конечном итоге проект Stoned Bootkit стал настолько популярным, что его полные последние версии, под давлением антивирусных компаний, не выкладываются в открытый доступ, а public lite версия довольно сильно урезана в плане функциональности. Как показали дальнейшие события, Stoned Bootkit стал отличной отправной точкой для многих злоумышленников, которые решили наделить свои поделки функциями буткита. Вот, например, Whistler Bootkit. Какие-то предприимчивые товарищи взяли Stoned v2 Alpha 3 от 20 октября 2009 года, подрихтовали напильником и в начале 2010 года стали предлагать к продаже. В качестве рекламы в одном из блогов была размещена информация о новом интересном бутките, который запускал вредоносные файлы из каталога C:\System Volume Information с правами NT-AUTHORITY\SYSTEM.

В том же 2009 году Найтин и Вайпин Кумары в рамках прошедшей в Дубае конференции Hack In The Box продемонстрировали Vbootkit версии 2.0, на этот раз заточенный под Windows 7 x64. Примененные в нем методы позволили успешно нейтрализовать действие механизмов PatchGuard и Driver Signing Policy, которые не давали модифицировать ряд системных объектов для реализации перехватов функций и загружать неподписанные драйверы, чтобы получить возможность выполнения кода в режиме ядра. Поначалу выложенные под лицензией GPL исходные коды проекта Vbootkit постигла участь исходников Stoned Bootkit — они точно так же были выпилены, дабы не плодить очередную толпу скрипткиддисов. Однако заинтересованные в теме лица необходимые для своей черной работы материалы все равно успели получить, и все заверте...

Кроме собственно проекта Stoned Bootkit, на сайте stoned-vienna.com в разделе статей находятся несколько материалов, посвященных исследованию и анализу некоторых образцов malware. Вот, например, анализ одной из китайских поделок — товарищи из КНР внимательно изучили Mebroot и прикрутили функции буткита к своему трояну со звучным названием Ghost Shadow, сокращенный аналитиками Microsoft до Ghodow. Получившийся гибрид, обнаруженный Symantec в марте 2010 года, известен под названием Trojan.Mebratix.B. Хотя отдельные участки его кода начисто слизаны с Mebroot, некоторые особенности были достаточно интересными. Так, для уменьшения вероятности обнаружения по изменению MBR Mebratix не переписывал его целиком, а лишь изменял аргументы инструкции mov, находящейся по смещению 00D0h от начала загрузочного кода таким образом, чтобы чтение сектора и передача управления происходила не в первый сектор загрузочного раздела, а во второй сектор диска, содержащий продолжение Mebratix. Эта часть загрузочного кода выполняла чтение 59 секторов жесткого диска (начиная со второго сектора) в память. В этих секторах хранились все остальные компоненты буткита, причем сектора со второго по четвертый были зашифрованы с помощью операции Xor, ключ для которой вычисляется динамически на каждой итерации получения очередного значения байта. Начиная с пятого сектора хранился драйвер размером около 17 Кб. Назначение драйвера буткита — внедрение кода пользовательского режима в процесс explorer.exe и установка перехватов на обработчики IRP-запросов типа IRPMJREAD/IRPMJWRITE драйвера класса диска Disk.sys. Указанные перехваты обеспечивали защиту секторов диска, в которых хранились компоненты буткита, от попыток чтения или перезаписи.

Любитель культовых фильмов

Знамя hi-tech-вредоносов успешно подхватило семейство TDL, трансформировавшееся в буткит в версии TDL4 (aka Tidserv или Olmarik по ESET — и где они такие названия берут?). Интересный факт о TDL: у авторов отличное чувство юмора, в коде встречаются отладочные строки — цитаты из культовых кинопроизведений («Бойцовский клуб», «Симпсоны», «Страх и ненависть в Лас-Вегасе», «Форест Гамп», «Звездные войны» и другие). По непроверенной информации, за созданием TDL первых трех версий стоял человек с ником Tyler Durden, а TDL расшифровывался как Tyler Durden Loader (хотя с равным успехом он мог бы расшифровываться как Trojan DownLoader — версии такие версии). Предполагают, что Tyler Durden был одним из сотрудников компании Comodo. Бизнес на базе TDL3 было решено свернуть после взлома сотрудниками Esage Lab командных серверов TDL3 и партнерской программы Dogma Million, что привело к утечке базы клиентов, которая сначала ходила в привате, а потом попала в руки отдела К летом 2010 года. TDL4 разрабатывался другими кодерами из исходников третьей версии, купленной за 65 тысяч долларов.

Так или иначе, в июле 2010-го выходит TDL4 0.01, а уже в августе 2010-го — TDL4 0.02 с поддержкой x64 операционных систем, став первым образцом malware такого вида, обнаруженным In The Wild. Проект Stoned Bootkit получил поддержку платформ x64 только в 2011 году.

Подхватив удачную идею Mebroot о хранении своих компонентов вне файловой системы, разработчик TDL еще в третьей версии развил ее до концепции хранилища с виртуальной файловой системой. Доступ к хранилищу обеспечивался драйвером-руткитом, который, кроме того что обладал функциями сокрытия и самозащиты, создавал виртуальное устройство, что позволяло при работе с файлами использовать стандартные функции WinAPI, такие как CreateFile(), WriteFile(), ReadFile(). Компоненты TDL4 хранились в специальной области (размером не более 8 Мб) в конце жесткого диска. В зашифрованном алгоритмом RC4 хранилище размещались основные модули с именами ldr16, ldr32, ldr64, конфигурационный файл, а также другие модули, загружаемые по сети. Код в MBR передавал управление компоненту ldr16. После передачи управления ldr16 перехватывал функции работы с жестким диском. Для загрузки TDL4 использовалась подмена файла kdcom.dll (путем установки перехватчика на Int 13h и поиска определенной сигнатуры kdcom.dll), который необходим для инициализации ядра на стадии загрузки. Вместо kdcom.dll в итоге загружался вредоносный компонент ldr32 или ldr64 в зависимости от разрядности целевой ОС. Бинарный код ldr32 и ldr64 практически идентичен, так как он скомпилирован из одних исходников.

Версия TDL4 0.03, вышедшая в сентябре 2010-го, для повышения своих привилегий в системе использовала эксплуатацию уязвимости в Task Scheduler, закрытую патчем MS10-092. При этом Windows XP не заражалась, в ней дроппер просто завершал свою работу.

Новые горизонты

Существующие до 2011 года буткиты изменяли компоненты ОС в процессе загрузки, перехватив прерывания BIOS 13h. А между тем эта техника использовалась еще во времена MS-DOS, и ей свойственны определенные недостатки: перехваченный обработчик исполняется только до загрузки ядра, так как далее прерывания BIOS уже не используются, кроме того, сигнатурный поиск нужного модуля может не сработать, если искомый паттерн будет находиться между двумя секторами. Поэтому два студента Австрийского университета прикладных наук Вольфганг Этлингер (Wolfgang Ettlinger) и Стефан Фибек (Stefan Viehbëck) пораскинули мозгами и пришли к выводу, что можно задействовать такую фичу, как многоядерность современных процессоров. Пускай загрузка происходит на одном ядре, а на втором в это время будет крутиться вредоносный код, который и будет патчить компоненты ОС. Прототип буткита, построенного на этом принципе, был представлен на NinjaCon 2011 под кодовым названием EvilCore. В общих чертах алгоритм работы его был следующим:

• после загрузки вредоносной MBR EvilCore отключается режим Symmetric Multi Processing, который ограничивает число процессорных ядер в ОС;
• уменьшается размер памяти, доступный ОС;
• код переносится в конец физической памяти, не используемой ОС, сам при этом продолжает выполняться в кеше CPU;
• на ядре CPU0 управление передается загрузчику ОС, а на CPU1 продолжает выполняться код EvilCore в режиме ядра и с полным доступом ко всей физической памяти.

А вот как происходит изменение кода ядра:

• в точку входа вставляется бесконечный цикл в виде инструкции jmp;
• пока CPU0 работает вхолостую, можно производить необходимые модификации;
• после изменения бесконечный цикл вставляется в следующий блок кода;
• точка входа восстанавливается.

Пример патча приведен на рис. 2.

При демонстрации прототипа указывалось на следующие недостатки: минус одно ядро в task manager (палево!) и снижение производительности. Первая проблема легко решается, доступ к памяти есть, поэтому число CPU можно просто подправить. Решение второй тоже тривиально: после патча компонентов ОС завершить выполнение вредоносного кода и освободить ядро процессора. Пока эти наработки в «массы» не пошли, поэтому в настоящее время образцов malware, созданных по подобию EvilCore, в «диком виде» не выявлено.

Продолжатели дела TDL

TDL со временем приобрел много приемников. Очередная киберпреступная группировка (будем называть ее Pragma, такие идентификаторы содержались в их коде) прибрала к рукам исходники TDL3 и TDL4 и стала клепать свои альтернативные версии этих вредоносов под названием SST или MaxSS (Olmasco по ESET). Преемственность кодов TDL привела к тому, что в классификации многих антивирусных вендоров царит полная неразбериха и, по сути, разные семейства продолжают именоваться как их предок (TDL, TDSS или Tidserv). Продажа кодов TDL4 не привела к его исчезновению, этот проект продолжил развиваться параллельно проекту SST.

TDL3 based вариант SST (с заражением драйвера) распространялся с начала 2011 года до начала лета, когда пошли загрузки тестовой версии SST на базе TDL4 с заражением MBR. На то, что это тестовая версия, указывал большой объем трассировочных логов, отправляемых на C&C во время установки, а также многочисленные сообщения об ошибках, которые буткит отправлял во время своей работы. Из фишек сотрудники компании Microsoft отметили очень интересный способ «резервного» канала восстановления связи SST со своими командными серверами. Конфигурационный файл с их адресами содержался в файлах формата JPG, которые размещались на хостинге imageshack.us. Ссылки на такие изображения содержались в постах, опубликованных на популярных блогерских площадках livejournal.com и wordpress.com.

Так или иначе, тестовая версия в августе была заменена новой и содержала в себе уже несколько иной способ получения управления при загрузке (см. рис. 3). Исполняемый код MBR не изменялся вовсе, а хранилище файлов организовывалось не просто в последних секторах диска, а в виде отдельного раздела размером до 15 Мб. Флаг активного раздела изменялся с загрузочного раздела ОС на раздел SST. Файловая система раздела с хранилищем в целом повторяла ФС TDL4, однако содержала некоторые улучшения, в частности было убрано ограничение на 15 файлов, а сами файлы в заголовке содержали контрольную сумму CRC32. Это позволяло реализовать в ФС проверку на целостность, в случае обнаружения повреждений файл удалялся из хранилища.

В конце года на сцену выходит форк TDL-4 под неблагозвучным названием Pihar, который по своим характеристикам почти не отличался от оригинального TDL-4. В нем был применен ряд мер, изменяющих сигнатурные характеристики компонентов. Например, шифровался не раздел целиком, а только файл конфигурации. В заголовке этого файла, кстати, присутствовала строка [PurpleHaze] — по всей видимости отсылка к песне легендарного Джимми Хендрикса.

Дроппер Pihar использовал для своей установки метод DLL hijacking с применением легального установщика Adobe Flash Player. Эту же фишку использовал ZeroAccess, разве что имена библиотек различались (ncrypt.dll вместо msimg32.dll).

В 2012 году компания Damballa представила аналитический отчет под названием «A New Iteration of the TDSS/TDL4 Malware Using DGA-based Command-and-Control». В нем говорилось, что обнаружен трафик, аналогичный по своим параметрам семейству TDL. Он был выявлен с помощью автоматизированной системы «Плеяды» (Pleiades), предназначенной для обнаружения малвари, использующей механизм DGA для связи со своими C&C. Дальнейший анализ показал, что это действительно новая модификация TDL4, его алгоритм генерации доменных имен назвали DGAv14.

По информации ресурса kernelmode.info, потомки TDL4 с обфусцированным конфигом (осмысленные имена вида ldr16, ldr32, ldr64 заменены числовыми строками) встречаются в интернете до сих пор.

Самый сложный, но не самый скрытный

Звание одного из самых навороченных буткитов следует отдать Gapz. Чего стоит один только модуль режима ядра, содержащий собственную реализацию стека TCP/IP-протокола, что позволяет ему обойти проверку локальных IPS/IDS при взаимодействии с сетью! Интересная особенность вредоносного кода режима ядра заключается в том, что он не имеет структуры исполняемого PE-файла. Вместо этого он разбит на несколько функциональных блоков, имеющих собственные заголовки. В процессе загрузки Gapz анализирует заголовок каждого блока и вызывает его функцию инициализации, которая, в свою очередь, выделяет память и заполняет их указателями на функции блока, а также различными структурами данных. Блоки модулей могли размещаться в секторах или до первого, или после последнего раздела. Хранилище payload представляло собой файл (содержимое зашифровано AES-256) в каталоге System Volume Information системного диска с именем из случайных hex-значений. Файловая система хранилища — FAT32, реализация которой взята из опенсорсного проекта FullFAT.

Gapz имеет несколько версий, различающихся методами загрузки, летом 2012-го заражалась MBR, а осенью — VBR, причем довольно интересным способом. VBR тома NTFS содержит в себе структуру данных, называемую BIOS Parameter Block (BPB), где указываются параметры тома. В BPB есть поле HiddenSectors, которое указывает на начало Initial Program Loader (IPL) — кода, на который передается управление после VBR. IPL отвечает за поиск загрузчика в файловой системе тома NTFS и его запуск. Изменением 4-байтового поля HiddenSectors Gapz добивается того, что код VBR передает управление не на IPL, а на свой код (см. рис. 4). Нечто подобное использовал Mebratix (изменение нескольких байт в MBR для получения управления и затруднения своего обнаружения).

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

Вездесущие китайцы

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

Свежий дроппер китайского трояна Guntior (известен с 2010 года), обнаруженный летом 2013 года сотрудниками компании Sophos, порадовал очередным трюком обхода проактивной защиты при своей инсталляции в систему. Сам дроппер спроектирован и собран таким образом, что может запускаться и как исполняемый файл EXE, и как динамическая библиотека DLL. Под именем msimg32.dll он копируется в каталог %Temp% и выставляет флаг в заголовке файла, указывающий, что это DLL. Также в каталог %Temp% сохраняется копия файла HelpCtr.exe (он импортирует функции из msimg32.dll), который отвечает за отображение «Справки и поддержки» в Windows. Но это еще не все — для запуска HelpCtr.exe переменная окружения PATH изменялась так, чтобы каталог %Temp% располагался раньше, чем каталог %System%. Сам HelpCtr.ex вызывался на исполнение путем отправки сообщения WMHOTKEY окну ShellTryWnd (по умолчанию справка вызывается комбинацией <Win + F1>). Таким образом, дроппер msimg32.dll подгружался легитимным файлом HelpCtr.exe (метод dll hijacking), и не вызывал срабатывания проактивной защиты антивирусов. После отработки файлы в %Temp% удалялись, а переменная PATH восстанавливалась к исходному виду. Еще из отличительных особенностей можно отметить наличие обширного списка процессов антивирусов и защитного ПО, которые подлежат немедленному завершению. Буткит-компонент Guntior создан на базе исходных кодов Stoned Bootkit (в Китае вообще любят заимствовать уже работающие готовые решения). Механизм сокрытия и самозащиты полностью аналогичен Mebroot ранних версий — перехват IRPMJREAD и IRPMJWRITE в disk.sys.

Слив года

Carberp. Новости об этом банковском трояне публикуются с завидной регулярностью. Весной благодаря совместным усилиям Службы безопасности Украины (СБУ) и Федеральной службы безопасности России (ФСБ) на территории Украины были задержаны распространители и разработчики Carberp. А летом его исходные тексты утекли в паблик. Около 5 Гб исходных текстов (2 Гб в архиве) оказались доступными для загрузки любым желающим. Среди исходников отдельный интерес представляет код буткита. Carberp изначально не имел своей bootkit-составляющей до 2011 года, когда разработчики купили фреймворк Rovnix. Кроме того, архив содержит часть исходных текстов буткитов Stoned и Sinowal.

Фреймворк Rovnix известен с 2011 года, тогда он использовался в качестве загрузчика трояна Mayachok (Cidox). Главная особенность Rovnix — заражение не MBR, а загрузочного сектора системного раздела с файловой системой NTFS, также называемого Volume Boot Record (VBR). Дроппер Mayachok несет в себе как 32-битный, так и 64-битный драйвер Rovnix. На диске сохранялся соответствующий драйвер в зависимости от разрядности пользовательской ОС. Он мог быть записан как в начало диска (до первого активного раздела), если там достаточно места, так и в его конец. Анализируя загрузочную запись, троянец находил место для своего размещения и перезаписывал имеющийся там код. Оригинальный код упаковывался при помощи библиотеки aPlib и дописывался следом. Номер начального сектора размещенного на диске драйвера и его размер также «прошивался» в тело зараженной VBR. На момент обнаружения Mayachok сотрудники антивирусных компаний не знали, что буткит был сторонним компонентом и, по всей вероятности, был куплен. Это установили только после обнаружения трояна Carberp с аналогичным модулем. В начале 2012 года ESET обнаружила модификацию Rovnix, оснащенную полиморфным генератором вредоносного кода, размещаемого в VBR, а также реализацией зашифрованного при помощи алгоритма RC6 хранилища файлов. Любопытно, что в качестве файловой системы использовалась модификация VFAT.

Rovnix стал первым представителем VBR-буткитов. И, проводя аналогии с ситуацией после слива исходников Zeus (кстати, разработчики Carberp их активно использовали), следует ожидать всплеска разработок boot-компонентов на его основе.

Что день грядущий нам готовит?

На волне распространения MBR- и VBR-заразы все дружно вспомнили про UEFI. Единичные случаи малвари, модифицирующей BIOS (Mebromi в 2011 году), объясняются тем, что производителей BIOS большое количество и писать код под значительное многообразие прошивок вообще не вариант. Другое дело — UIFI, где все унифицировано. С другой стороны, UEFI написан на языке Си, что подразумевает наличие многочисленных ошибок переполнения буфера. Итальянец Андреа Алльеви (Andrea Allievi), ведущий исследователь компании ITSEC в области ИТ-безопасности , продемонстрировал в сентябре 2012 года уязвимость механизма загрузки Windows 8, разработав первый полноценный UEFI-буткит для этой платформы. Исследователи ITSEC нашли уязвимость в UEFI и использовали ее для замены UEFI bootloader на свой собственный. В результате механизмы защиты Kernel Patch Protection и Driver Signature Enforcement успешно обходятся. Весной 2013 года на конференции HITB (Hack in the Box) Себастьян Качмарек (Sébastien Kaczmarek) из QuarksLab представил доклад «Dreamboot: A UEFI Bootkit» и продемонстрировал работу очередного концепта буткита для Windows 8. Исходники проекта Dreamboot доступны на github.com.

Следует отметить, что все эти наработки функционируют при отключенной функции SecureBoot, что позволило компании Microsoft с новыми силами заняться ее продвижением. Однако популярность Windows 8 на десктопах пока крайне мала, программировать под UEFI — одно удовольствие (не ассемблер все-таки, а Си), а это значит, что у создателей буткитов еще есть время не раз и не два попользоваться ресурсами компьютеров ничего не подозревающих граждан, а иной раз и залезть им в карман. Поскольку рядовой пользователь сам не в состоянии отправить подозрительные файлы на анализ (хотя бы потому, что к файлам буткитов, как правило, из ОС доступ получить нельзя), хочется пожелать, чтобы сисадмины корпоративных сетей внимательнее относились к мониторингу подозрительной сетевой активности (на шлюзе проще всего отследить, что какая-то гадость стучится в интернет), а антивирусные компании более оперативно реагировали на появление новых угроз такого типа.