Опубликовано в журнале Хакер #171 (апрель 2013)
Со временем некоторые вредоносные программы становятся своеобразными брендами в среде киберандеграунда. Как правило, они имеют широкое распространение по сравнению с другими вредоносами и используют различные технологичные фишки. К таковым можно отнести семейства Sality, Conficker, Waledac, Zeus, TDL и множество других. Как бы ни боролись с такими угрозами антивирусные компании, как говорится — иногда они возвращаются. В логичности использования раскрученного имени злоумышленникам не откажешь. Разбирая функционал очередной «зверушки», невольно задаешь себе вопрос — а когда это все началось? И выясняется, что и ни год, и ни два назад. Об одном таком семействе и будет рассказано далее.
Начало
История ZeroAccess (aka MAX++) началась в июне в 2009 год. Именно тогда был обнаружен образец вредоносной программы, который использовал путь вида \?globalrootDevice__max++>[8 digit hex code].dll, а в драйвере ядра имел строку «f:VC5releaseZeroAccess.pdb». Так что название ZeroAccess — авторское. Но, как известно, некоторые антивирусные вендоры противятся называть вредоносы согласно задумке авторов, поэтому MAX++ также известен под названиями Smiscer и Sirefef. Версия 2009 года прятала свой бинарный код в альтернативных потоках (Alternate Data Streams — ADS) файловой системы NTFS под названиями win32k.sys:1 и win32k.sys:2, которые прописывались в системе как сервисы. Первый из этих файлов был приманкой, в случае, если антивирусное ПО пыталось получить доступ к нему, ZeroAccess немедленно завершал сканирующий процесс. Впоследствии, использование техники слежения за специально созданными объектами ОС для «убийства» антивирусов, стало его отличительной особенностью.
Сводный брат TDL3
В январе 2010 создатели ZeroAccess принялись распространять новую версию своего детища. Для этого задействовались ресурсы сети Ecatel компании RBN. Отличительным признаком новой версии ZeroAccess, было явное заимствование идей TDL3, а именно — запуск через заражение драйвера и использование скрытого хранилища для своих компонентов.
Установка в систему начиналась с файла-дроппера, например, с именем keygen.exe. Для нормальной работы необходимы были права администратора, что в условиях маскировки под кейген для любимой игрушки не было особой проблемой. При установке на диск никаких временных рабочих файлов не извлекалось, все манипуляции происходили в памяти. Для старта при загрузке ОС использовалась методика загрузки при помощи функции ZwLoadDriver(). Перво-наперво выбирался существующий в системе драйвер-жертва, подпадающий под несколько необходимых признаков: имя драйвера должно было находится в диапазоне от Ndis.sys до Win32k.sys, размер — более 0x4C10 байт, IMAGE_OPTIONAL_HEADER->Export Table.RVA выставлен в NULL (драйвер ничего не экспортирует). Так же драйвер не должен был запускаться при загрузке системы, это проверялось по флагу Start (0 — не загружать) в ветке реестра services. Выбрав подходящий драйвер, ZeroAccess целиком переписывал его своим кодом, предварительно отключив SFC. Далее создавалась запись в реестре о новом сервисе со случайным именем и параметрами Type = 0x1, Start = 0x3. Хитрость заключалась в том, что ImagePath для сервиса выставлялся в *, а для * при помощи функции ZwCreateSymbolicLinkObject() создавался симлинк на перезаписанный драйвер. Указанный сервис и стартовал путем вызова ZwLoadDriver(). Запущенный руткит регистрировался через вызов IoCreateDriver() в качестве драйвера ОС, для перехвата операции ввод/вывода на уровне IRP пакетов драйверов минипорта дисковой подсистемы. Далее создавалось виртуальное устройство с фиксированным именем ??C2CAD972#4079#4fd3#A68D#AD34CC121074, к которому подмонтировался ранее созданный файл хранилища под именем %system%Config[random symbols].sav. Теперь дроппер мог обращаться к своему хранилищу через виртуальное устройство. После форматирования хранилища в сжатый том NTFS при помощи функций библиотеки fmifs.dll, туда сохранялись все остальные компоненты, включая копию чистого драйвера. Структура файлов приведена на рисунке.
Функция руткита заключалась в сокрытии содержимого перезаписанного драйвера, при попытке его чтения, руткит демонстрировал сохраненный исходный файл. Помимо этого руткит инициировал запуск инжектора B48DADF8.sys, который внедрял основной модуль-DLL с именем мax++.00.x86, в адресное пространство браузера посредством APC. Можно заметить, что в ходе работы функции непосредственного запуска вообще не используются, дабы не вызывать срабатываний проактивной защиты антивирусов. Основной модуль имел функции связи с командным центром и подмены поисковой выдачи для перенаправления пользователя на вредоносные сайты, предлагающие загрузить фэйковый антивирус (FakeAV). Параметры подключения брались из файлов в хранилище с названиями, похожими на CLSID, например {49B474EB-92D0-464f-B1DD-1F37AABF9D95}. По информации Symantec между 1 июля 2009 и 30 июня 2010 было произведено около 43 миллионов установок поддельных антивирусов. С учетом стоимости такого «подарка» от 30$ до 100$, вырисовывается, что этот бизнес был достаточно прибыльным.
Некоторые специалисты, например, представитель компании Webroot Джейкс Эразмус (Jacques Erasmus), говорят, что исходные коды TDL3 были проданы разработчикам ZeroAccess. Произошло это примерно в конце 2009 — начале 2010 годов. Так что не исключено, что версия TDL3 с Z00clicker.dll и ZeroAcess — результаты сторонней разработки на базе исходного кода TDL3. В тоже время сотрудники лаборатории Касперского заявляют, что никакой связи между TDL3 и ZeroAcess нет. По их словам, скорее, речь может идти о reverse engineering и заимствовании идей TDL3.
В 2011 году появилась обновленная версия. Для загрузки руткита использовался все тот же метод запуска через ZwLoadDriver() с небольшими изменениями. Теперь драйвера выбирались из диапазона от classpnp.sys до win32k.sys, размером больше чем 0x7410. В коде дроппера присутствовала проверка на выполнение в 64-разрядной среде, в этом случае выполнение сразу завершалось. Имя устройства для обращения к хранилищу имело вид \?ACPI#PNP0303#2&da1a3ff&0 (могло меняться от релиза к релизу). Файл хранилища размером 16 мегабайт %system%Config[random symbols] на этот раз не был сжат, а шифровался 128 битным статическим ключом RC4, расшифровка производилась на лету драйвером руткита при обращении к файлам, содержавшимся в хранилище. Появилась ярко выраженная модульная структура,
модули загружались с удаленного сервера. Для связи с командным центром устанавливалось соединение на порт 13620. Сами запросы и ответы передавались в зашифрованном виде.
Работа в x64 и трюки самозащиты
Вплоть до апреля 2011 года 64-разрядные версии ОС не заражались ZeroAccess. В мае это досадное упущение было исправлено, но не сказать, что бы очень технологично. Дело в том, что для x86 алгоритм работы был аналогичен предыдущей версии и руткит работал на уровне ядра. В противовес этому в среде x64 все работало в usermode.
Как известно, в Windows, начиная с Vista, появился UAC — компонент системы, который запрашивает подтверждение действий, требующих прав администратора. UAC конечно несколько повысил уровень безопасности Windows, но, как всегда, злобные хакеры все испортили. В UAC жестко прописаны многие системные программы, как доверенные (например, explorer.exe), поэтому код, который приводит к срабатыванию для других приложений, для них не работает при настройке по умолчанию. Эта особенность была использована в дроппере ZeroAccess для того, что бы поднять свои привилегии в системе до уровня администратора, окно UAC при этом пользователю не показывалось (со временем этот баг был исправлен).
Для обхода средств мониторинга трафика в заголовке HTTP запроса HOST использовалось сгенерированное при помощи Domain Generator Algorithm (DGA) доменное имя в зоне .cn, реально оно не резолвится серверами DNS. В ответ на запрос с неправильным заголовком HOST сервер возвращал пустой ответ. То есть сервер точно так же генерировал значение и сравнивал его с поступившим от бота. Эти действия представляли собой некую систему псевдоаутентификации, которая защищала сервер, например, от сканирования поисковыми роботами.
Так как процедура установки для x86 уже была описана (заражение драйвера), заострять внимание на ней не будем. Стоит лишь отметить очередную смену формата хранилища в июле, теперь это был не файл, а каталог вида C:WINDOWS$NtUninstallKBxxxxx$, где xxxxx — 5 сгенерированных цифр. Такое наименование было выбрано с целью маскировки под рабочую директорию обновления ОС Windows. Доступ к ней блокировался путем создания символической ссылки с $NtUninstallKBxxxxx$ на %systemroot%system32config, а так же выставлением правил ACL. Каждый файл внутри директории шифровался RC4, ключ не был определен в коде, а генерировался, используя некоторые параметры ОС.
Краткое описание загружаемых из Интернета компонентов:
@00000001 — резервная копия дроппера;
@80000000 — модуль трекинга, предназначен для сбора статистики заражений, информация о зараженной системе отправлялась на counter.yadro.ru;
@800000c0 — поддельная библиотека mswsock.dll для перехвата функций WinSocks, их мониторинг позволял красть пароли и логины FTP, а также производить внедрение JavaScript в HTML страницы;
@000000c0 — модуль внедряет JavaScript для изменения выдачи поисковых запросов и отправляет данные FTP аккаунтов на удаленный сервер;
@800000cb — модуль внедряется в svchost.exe и используется для накрутки посещаемости (click fraud);
@800000cf — модуль связи с командным центром, внедряется в winlogon.exe, а затем в браузер, установленный на компьютере. В адресном пространстве браузера выполняется код, связывающийся по фиксированным IP адресам и порту 13620 с командным центром. Список IP находится в файле с именем, похожим на CLSID.
В режиме x64 никаких инноваций не наблюдалось. Загрузочный модуль сохранялся как %windir%system32consrv.dll, для его запуска правилась ветка реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerSubSystems, в значение ключа «Windows» вставлялась строка «consrv:ConServerDllInitialization». Для маскировки своих файлов в качестве хранилища использовалась системная директория Global Assembly Cache (GAC) вида $windirassembly, которая используется для отображения установленных компонентов .Net и не показывает непосредственно свое содержимое в Explorer, что не прокатывает в FAR и TotalCommander. Для хранилища создавался каталог $windirassemblytmp, где и размещались в зашифрованном виде модули.
Интересная фишка данной версии ZeroAccess — использование техники «ловли на живца» для обламывания антивирусов. Кроме своего основного драйвера-руткита, ZeroAccess имел дополнительный драйвер ядра для создания «приманки» — объекта, на который «клевали» антивирусные средств защиты. Этот драйвер создавал устройство Devicesvchost.exe и сохранял подставной PE файл как Devicesvchost.exesvchost.exe, доступ к которому мониторился руткитом. Если какое-либо приложение пыталось обратиться к нему, то ZeroAccess немедленно завершал его. Для завершения потока приложения, в него методом APC инжектировалось около двухсот байт кода, который вызывал ExitProcess(). Но это было еще не все, что бы предотвратить последующие запуски завершенного приложения, для его исполняемого файла ZeroAccess сбрасывал правила доступа ACL, разрешающие чтение и выполнение файла. Таким образом, один раз попавшись на крючок, антивирус больше не мог запуститься.
Даешь P2P!
С целью повысить живучесть, разработчики стали использовать различные ухищрения. Основной упор был на возможность работы ZeroAccess при любых правах доступа, а так же противодействие блокированию командных центров. При запуске в Windows Vista/Seven происходила попытка повысить свои права. Так как баг с обходом UAC через инжект в explorer.exe был пофикшен, для поднятия прав стал использовался DLL hijacking, его сущность — ОС сначала ищет необходимую DLL в текущей директории, а потом в системной, поэтому, разместив в директории легитимной программы DLL с именем, совпадающим с именем одной из импортируемых библиотек, можно добиться запуска вредоносного кода. Для реализации этого метода на борту дроппера, во внедренном CAB файле,
присутствовал файл fp.exe. Это был легальный онлайн инсталятор Adobe Flash Player, снабженный, к тому же, цифровой подписью VeriSign. Инсталлятор сохранялся под именем FlashPlayerInstaller.exe в каталог temp, в этот же каталог предварительно помещался файл msimg32.dll, имя которого совпадает с одной из импортируемых DLL.
Руткит x86 режима, как и прежде, расставлял в системе ловушки. Теперь это был сервис, запускавший файл systemroot3439254774:153289011.exe, при этом файл 3439254774 был нулевого размера, а 153289011.exe хранился в ADS и брался из wsc32.
В 64 разрядном режиме Windows Vista/Seven, если были права администратора, использовалась схема с consrv.dll и $windirassembly. Если же таких прав не было, это не было фатально, в том числе в среде XP. Ведь самое главное нововведение – файл «X», реализующий P2P на базе протокола TCP для распространения своих модулей, а так же bootstrap list с названием «@», каталоги «U» и «L», размещались в местах, доступных на запись с пользовательскими правами:
XP — %UserProfile%Application Data[8 digit hex code];
Vista/Seven — %UserProfile%AppDataLocal[8 digit hex code].
Частично децентрализованные P2P сети предполагают загрузку bootstrap list с заранее известных серверов, так работает uTorrrent. В такой системе существует слабое место — достаточно заблокировать доступ к серверам, содержащим bootstrap list. Поэтому malware зачастую использует полностью децентрализованную схему. Полностью децентрализованная P2P сеть применительно к malware подразумевает, что распространение будет проходить в два этапа. На первом этапе распространяется бот с пустым bootstrap list или вообще без функций P2P, он периодически обращается к командному центру, который фиксирует IP адрес бота. Кроме непосредственно IP адреса, операторов ботнета интересует информация, не находится ли бот за шлюзом (gateway) или сетевым экраном (firewall). Если это не так, значит, бот может выступать в роли супер пира (super peer, super node), то есть к нему могут подключаться другие пиры. Как только набрано необходимое количество суперпиров, их список заносится в bootstrap list, и новая версия бота с ним начинает распространяться злоумышленниками. После распространения все боты обмениваются информацией о своих соседях и формируют свой собственный bootstrap list. В результате этого возникает P2P сеть. Она устойчива к пропаданию определенного количества ботов, так как список соседей постоянно меняется. В ходе обмена боты также обмениваются информацией о своей версии. Если бот обнаруживает, что он или его модули «устарели», происходит закачка новой версии с одного из соседей. При закачке, как правило, проверяется цифровая подпись файла, чтобы исключить возможность распространения «посторонних» файлов. Таким образом, все боты в P2P поддерживают себя в актуальном состоянии.
Запуск «X» файла прописывался в параметре Shell ветки HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWinlogon. Таким образом, функционирование ZeroAccess поддерживалось из-под учетной записи с ограниченными правами, пусть даже и без руткит функций.
По данным компании Sophos, активное распространение P2P TCP-based версии началось в сентябре-ноябре 2011, тогда как первые сэмплы появились в конце июля. Антивирусные аналитики отмечают, что данная версия загружала два основных вида полезной нагрузки — click fraud и spambot, которые легко определить по используемым портам (21810, 22292 и 34354, 34355 соответственно).
Bootstrap list содержал 256 значений IP адресов, для каждого из которых указывалась timestamp (POSIX) последнего обращения. Все пакеты P2P сети шифровались по алгоритму RC4 статическим ключом.
Поддерживались следующие типы команд:
«getL» — запрос на получение bootstrap list;
«retL» — ответ с содержимым bootstrap list;
«getF» — запрос на получение файла;
«setF» — ответ с содержимым файла;
«srv?» — запрос на получение списка файлов.
Кстати, тип команды — это не строка, а 4 байтовое слово, их так легче сравнивать. Название файла модуля из восьми HEX символов тоже кодировалось 4 байтами.
Для каждой ноды в текущем bootstrap list, посылалась команда «getL». Удаленный компьютер должен был ответить командой «retL» и переслать свой bootstrap list. Результирующий список, созданный на основе текущего и присланного, содержал ноды с временем обращения, наиболее близким к текущему. В ответ на запрос «srv?» отправлялся список файлов, каждая запись в списке содержала два поля: имя файла из 4 байт и timestamp создания файла. При обнаружении «свежих» файлов, происходило их обновление командами «getF», «setF». Каждый загружаемый модуль должен был содержать в себе ресурс «33333», содержащий цифровую подпись RSA с ключом 512 бит. Подпись проверялась перед запуском файла.
В протоколе P2P имелись некоторые недостатки реализации. Сформировав bootstrap list из 256 IP с заведомо большими значением timestamp, чем текущее время, было возможно «отравить» bootstrap list всех нод, что привело бы к невозможности распространять модули по сети P2P. Если в хранилище поместить произвольный файл (замечание — значение поля milliseconds в структуре time_field фала должно было быть при этом равным нулю), он выкачивался удаленными пирами, хоть его запуск и был невозможен из-за проверки подписи. Это позволяло создать нагрузку на сеть и тем самым привлечь внимание к аномальному сетевому трафику на компьютере с дальнейшим обнаружением и удалением ZeroAccess. Указанные недостатки были исправлены в следующей реализации P2P.
Помаши руткиту ручкой
Май 2012 — вот и кончилось время, когда в составе ZeroAccess был драйвер ядерного уровня, теперь вся работа происходила в usermode. Заглянув в содержимое CAB файла можно обнаружить, что из него исчезли компоненты rtk32 и rtk64, зато добавились w32, w64, e32, e64.
Руткит компонент нет, соответственно драйвер Windows в этой версии не перезаписываются, для запуска при загрузке системы может использоваться один из двух методов — техника COM hijacking, которая использует системный реестр, и модификация файла services.exe.
При помощи COM hijacking запускается на выполнение файл с именем «n» (n32 или n64), который отвечает за работу сети P2P. Дроппером создаются два идентичных файла «n» в следующих двух местах:
%Windir%installer[UID];
%UserProfile%local settingsapplication data[UID] (для XP и ниже) или %UserProfile%AppDataLocal[UID] (для Vista и выше).
Здесь UID — значение, генерируемое дроппером на основе хеша MD5 от времени создания системного диска и отформатированное, что бы выглядеть, как CLSID, например {e051c979-bddd-5d1f-8953-4b8c940e9b4d}. В указанных каталогах также создаются подкаталоги «U» (для дополнительных модулей) и «L» (для временных файлов), а также файл «@» (s32 или s64).
Один файл «n» использует hijacking COM объекта, ассоциированного с WMI, при этом модифицируется следующий ключ реестра: HKCRCLSID{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}InprocServer32.
Другой файл «n» использует для запуска COM объект в ветке:
HKCUSoftwareClassesclsid{42aedc87-2188-41fd-b9a3-0c966feabec1}.
Модификация файла services.exe производилась интересным образом: в файл вставлялся небольшой шелл-код (w32 или w64), который вызовом функции ZwQueryEaFile() подгружал «хвост» вредоносного кода (e32 или e64) из Extended Attributes файла, предварительно сохраненного туда при помощи ZwSetEaFile(). Функционал PE файлов в компонентах e32 и e64 был идентичен n32 и n64.
Более поздние версии прячут свои файлы внутри C:$Recycle.Bin или С:RECYCLER,
где создавался каталог с именем, соответствующему CLSID пользователя компьютера. Если были права администратора, создавался еще каталог с CLSID S-1-5-18 (LOCAL_SYSTEM). Внутри создавался подкаталог со случайным именем, образованным хэшированием MD5 текущего времени. Для старта каждой из двух копий файла «n» создавались следующие COM объекты:
HKCUSoftwareClassesclsid{fbeb8a05-beee-4442-804e-409d6c4515e9} — для пользователя с ограниченными правами;
HKCRCLSID{5839FCA9-774D-42A1-ACDA-D6A79037F57F} — для пользователя с правами администратора.
Алгоритм работы P2P сети претерпел некоторые изменения. В зависимости от разрядности ОС использовались разные порты: 16464 и 16470 для x32, 16465 и 16471 для x64. Таким образом, организовывалось 4 независимых P2P сети, в каждой из которой использовался свой RSA ключ, длина которого была увеличена с 512 до 1024 бит. Как и прежде, существовало разделение по типу полезной нагрузки, порты 16464 и 16465 использовались релизом с click fraud payload, 16470 и 16471 — релизом с bitcoin miner payload.
Если раньше P2P использовал только TCP, то теперь список IP-адресов запрашивался по UDP, а список файлов (модулей) — по ТСР. Команда «retL» теперь возвращала только 16 значений из своего bootstrap list (противодействие «отравлению» bootstrap list), в этом же блоке данных передавались сведения о имеющихся модулях. В bootstrap list теперь указывалось не абсолютное значение timestamp, а разница между текущим временем и временем последнего обращения. Сведения об используемых модулях передавались в виде заголовка, состоящего из полей File name, Timestamp, Size. К заголовку прилагалась цифровая подпись (хэш MD5, зашифрованный закрытым ключом злоумышленников). Подпись проверялась на корректность при загрузке и сохранялась в Extended Attributes файла. Таким образом, криптографическая защита от постороннего вмешательства имелась как на уровне содержимого (как и в предыдущей версии, ресурс «33333», содержащий цифровую подпись), так и на уровне имени, даты создания и размера файла. Сам файл при передаче шифровался RC4 ключом. Для принудительной смены bootstrap list была введена команда NewL, которая могла использоваться при обнаружении злоумышленниками sinkhole антивирусной компании в списке пиров, для восстановления status quo. Все указанные отличия от реализации P2P предыдущей версии были призваны устранить потенциальную возможность нарушить работу ботнета.
Состав загружаемых модулей разнится для разных версий. Например, версия click fraud с портом P2P 16464 обычно выкачивает три файла:
800000cb.@ — модуль click fraud, регистрирует класс с именем z00clicker3;
00000001.@ — dll, используемая в качестве хранилища ресурсов (данные для 800000cb.@);
80000000.@ — модуль трекинга, предназначен для сбора статистики заражений, информация о зараженной системе отправляется на livecounter.co/count.php.
Версия с bitcoin miner использовала несколько иной набор модулей:
000000cb.@ — модуль click fraud;
80000000.@ — модуль трекинга;
80000032.@, 80000064.@ — модуль bitcoin miner (x32 и x64);
00000004.@, 00000008.@ — dll, используемая в качестве хранилища ресурсов (данные для 80000032.@ и 80000064.@).
Кроме указанных, отмечена загрузка модулей перенаправления поисковых запросов, рассылки спама и загрузки произвольных файлов.
Заключение
Пример ZeroAccess хорошо иллюстрирует принцип бритвы Оккама — не умножайте сущности без надобности, или по-простому — не усложняйте. Начавшись, как технологичная разработка и потеряв в ходе своей эволюции руткит составляющую, ZeroAccess, тем не менее, успешно продолжает существовать, и даже обзавелся такой модной фичей, как P2P.
По оценкам компании Sophos количество заражений компьютеров ботом ZeroAccess на конец августа 2012 составляло более 9 миллионов, а активных ботов около 1 миллиона. В отчете лаборатории Kindsight Security «Malware Report» за 3 квартал 2012 года говорится уже о 2.2 миллионах зараженных систем, из которых 685 тысяч (31 %) находятся в США. По мнению экспертов, ботнет на основе ZeroAccess был самым активным в 2012 году.
В свете этих цифр, думаю, уже не у кого не осталось сомнений, что ZeroAcces — это не ноль без палочки. Пусть Ring-0 уже и не используется, но «Access» к вычислительным мощностям ничего не подозревающих пользователей продолжает приносить злоумышленниками кучу вечнозеленых американских бумажек. А это значит, антивирусным компаниям есть над чем работать. Читателям же хочется в очередной раз напомнить — спасение вашего железного друга от троянской напасти полностью на вашей совести, будьте бдительны.
Автор: nuklearlord
