Руткит TDSS, появившийся еще в 2008 году, со временем стал намного популярнее нашумевшего руткита Rustock, а по своему функционалу и сложности для анализа практически приблизился к буткиту. В бутките использовался механизм заражения загрузочной области диска, приводивший к загрузке вредоносного кода раньше операционной системы. TDSS взял на вооружение функцию заражения драйверов, которые обеспечивают его загрузку и работу на самых ранних этапах работы ОС. Как следствие, идентификация руткита TDSS в системе является нелегкой задачей, а его лечение — серьезной проблемой.

TDSS. Руткит-технологии

Начало. TDL-1

Первая версия TDSS была задетектирована «Лабораторией Касперского» 6 апреля 2008 года с вердиктом Rootkit.Win32.Clbd.a. Название вредоносной программы перекликалось с именем драйвера clbdriver.sys и именем динамической библиотеки clbdll.dll, в которых и находился основной зловредный функционал.

Все большое начинается с малого, и руткит-технологии первой версии TDSS — не исключение. Функционал драйвера довольно прост даже для 2008 года.

Примечательно, что со времен первой версии некоторые части руткита так и не менялись, а именно:

1. Идентификаторы "TDL”;
2. Функции заражения драйвера;
3. Использование файла конфигураций;
4. Формат работы с административной панелью.

 
Часть файла одной из первых версий руткита
TDSS - Rootkit.Win32.Clbd.o, — заражающего драйвер beep.sys

Основные функции данного руткита:

• защита критичных веток реестра путем их сокрытия;
• защита критичных файлов на диске путем их сокрытия;
• внедрение вредоносного кода в системные процессы из драйвера режима ядра;
• сокрытие сетевых портов TCP;
• выполнение некоторых функций (завершение процессов, завершение потоков, сокрытие загруженных DLL-модулей и др).

Файлы скрываются путем присоединения вредоносного фильтра в системный стек драйверов. Причем производится данное действие в цикле для каждого тома в системе. Данный метод позволяет убить сразу двух зайцев. Руткит не только скрывает на диске файлы, имена которых начинаются с букв «tdl», но и при попытке открыть том \Device\HarddiskVolumeX возвращается ошибка, что приводит к ошибкам в различных анти-руткитах, которым открытие данного тома необходимо для низкоуровнего разбора структур файловой системы.

Номер ошибки, возвращаемый вредоносной программой, — STATUS_TOO_MANY_SECRETS — свидетельствует о довольно своеобразном чувстве юмора вирусописателей. Этот номер стал своего рода отличительным знаком авторов.

Сокрытие сетевых портов также производится путем присоединения вредоносного фильтра в стек устройства \Device\Tcp.

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

 
Пример сплайсинга функций NtEnumerateKey и
NtFlushInstructionCache на зараженной системе

Интересной особенностью TDL-1 является перехват системной функции NtFlushInstructionCache. Именно с помощью ее вызова драйвер способен выполнять различные дополнительные команды, а именно:

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

 
Функция, исполняющая дополнительные команды руткита

Для сокрытия своего драйвера в системе руткит использует довольно тривиальную процедуру вычленения загруженного модуля из системного списка загруженных драйверов PsLoadedModuleList.

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

Сага продолжается. TDL-2

Анти-руткит технологии не стоят на месте, и в ответ на это развиваются и руткит-технологии. Новая модификация — TDSS (TDL-2) — появилась в начале 2009 года.

Стоит упомянуть о том, что было выявлено несколько модификаций руткита TDL-2 с обновленным функционалом, поэтому в разных описаниях информация может различаться.

Для затруднения анализа вредоносного драйвера авторы использовали механизмы обфускации и шифрования тела руткита. Кроме всего прочего, содержимое вредоносного файла разбавлено случайными словами из трагедии «Гамлет» Уильяма Шекспира, дабы сбить с толку вирусного аналитика.

 
Часть содержимого вредоносного файла,
разбавленного случайными словами

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

• IofCallDriver
• IofCompleteRequest
• NtFlushInstructionCache
• NtEnumerateKey
• bNtSaveKey (в некоторых версиях)
• NtSaveKeyEx (в некоторых версиях)
• NtQueryValueKey (в некоторых версиях)

 
Перехваченные функции операционной системы

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

Перехват функции NtEnumerateKey все также используется для сокрытия конфигурационных данных руткита и его критичных веток реестра.

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

Перехват функции NtFlushInstructionCache служит для предоставления компонентам вредоносной программы доступа в режим ядра.

Перехват системных функций IofCallDriver и IofCompleteRequest позволяет вредоносному драйверу фильтровать системные IRP-пакеты. Так обеспечивается функционал ограничения доступа и сокрытия файлов руткита. В ОС Windows система ввода/вывода построена на унифицированном интерфейсе и является сердцем операционной системы. Менеджер ввода/вывода соединяет приложения и системные компоненты с различными устройствами. Большинство запросов ввода/вывода представлены в виде специальных IRP-пакетов (I/O request packet). Таким образом, перехватив указанные выше функции, можно фильтровать различные пакеты ввода/вывода в системе, например, операции открытия файлов. Причем, если перехват IofCallDriver предоставляет возможность отфильтровать пакет до его обработки системой, то перехват IofCompleteRequest позволяет отменить успешную операцию, например, открытия файла.

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

В перехвате IofCompleteRequest возвращается ошибка STATUS_SECRET_TOO_LONG и отменяется успешная операция.

Также руткит использует трюк с системной веткой реестра ServiceGroupOrder. Данная ветка реестра отвечает за порядок загрузки драйверов. Если руткитом найден какой-либо драйвер, у которого группа загрузки установлена первой в списке, перед System Reserved, то запись этого сервиса в реестре исправляется таким образом, чтобы сервис стартовал намного позже. Это еще один метод противодействия анти-руткит-технологиям.

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

Конец ли? TDL-3

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

Для закрепления руткита в операционной системе авторы избрали довольно известный путь — файловый вирус, а именно вирус, который заражает системные компоненты ОС. Для заражения используется мини-порт/порт драйвер диска. Данный метод позволяет руткиту загружаться практически сразу после старта операционной системы.

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

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

 
Точка входа atapi.sys до заражения

 
Точка входа зараженного atapi.sys

Основная цель этого маленького загрузчика — подгрузить в память основное тело руткита, находящееся в последних секторах диска, и передать ему управление.

 
Основное тело руткита на диске с меткой «TDL3»

Но на этом сюрпризы не заканчиваются. TDL-3 использует свою собственную реализацию шифрованной файловой системы, в которой хранятся его конфигурационные данные и дополнительные библиотеки пользовательского режима. Поэтому как таковая файловая система FAT или NTFS ему не нужна.

 
Пример конфигурации руткита, расположенной в последних секторах диска

Одна из основных целей любого руткита — это блокирование и/или сокрытие критичных данных вредоносной программы. Для этих целей TDL-3 использует технику подмены объекта, обслуживающего системное устройство.

 
Стек дискового устройства

Все функции, обслуживающие данное устройство, ведут в функцию-перехватчик вредоносного драйвера:

Так руткит фильтрует обращения к секторам диска, в которых расположены критически важные для него данные. В случае попытки чтения зараженного драйвера (в нашем случае atapi.sys) клиенту возвращается содержимое файла до заражения.

TDL-3 — технологически сложная и хорошо продуманная вредоносная программа. Авторы следят за новейшими разработками антивирусных компаний и мгновенно реагируют на них, выпуская новую исправленную версию руткита (на данный момент последней является версия 3.273). Поэтому в ближайшее время следует ожидать изменения руткит-функционала в сторону более эффективного противодействия антируткит-технологиям.

TDSS онлайн

В начале марта 2010 года «Лабораторией Касперского» был зафиксирован необычайный всплеск активности TDSS.

 
Количество ежедневно детектируемых вариантов руткита TDSS
и его компонентов (по данным Kaspersky Security Network)

Столь активное распространение TDSS послужило причиной более подробного анализа данного руткита. О результатах этого анализа и пойдет речь далее.

«The Partnerka»

Распространение руткита TDSS обеспечили партнерские программы, которые в настоящее время являются самым популярным методом кооперации злоумышленников в целях незаконного обогащения. Согласно Википедии, «партнерская программа — это форма делового сотрудничества между продавцом и партнерами при продаже какого-либо товара или предоставлении услуг; позволяет продавцу сократить расходы на привлечение конечного покупателя» ru.wikipedia.org. Для киберпреступников, участвующих в партнерской программе, товаром могут являться вредоносные программы, а услугами — привлечение пользователей на зараженные веб-ресурсы и заражение их компьютеров. Существует большое количество самых разнообразных партнерских программ, но в нашем случае речь идет «партнерках», распространяющих вредоносные программы и/или фальшивые антивирусы.

Количество страниц, найденных поисковой системой Google по запросу «партнерка»

Примечательно, что при участии в «партнерке» по распространению какой-либо вредоносной программы партнера не ограничивают в средствах. Чем больше компьютеров он заразит, тем больше денег получит. Поэтому для установки вредоносных программ на компьютеры пользователей большинство партнеров используют разнообразные наборы эксплойтов, червей и вирусы. Так, вызвавший в начале прошлого года эпидемию компьютерный червь Worm.Win32.Kido (Conficker) содержал функцию загрузки и запуска файла партнерской программы Traffic Converter, распространяющей фальшивые антивирусы.

Большинство партнерских программ, распространяющих вредоносный код, работают по схеме Pay-Per-Install (PPI, оплата за установку), при которой выплаты партнеру зависят от количества установок вредоносной программы и географического положения зараженных компьютеров.

 
Сайт партнерской программы «PMSoftware»,
распространяющей фальшивые антивирусы и TDSS.
Выплаты за установку зависят от географического положения жертвы.

AffId

Поскольку руткит TDSS распространяется через «партнерку», в его функционал встроен механизм передачи информации о партнере, который осуществил установку руткита на компьютер пользователя. Данная информация хранится в файле конфигурации руткита и указывается числом, присвоенным полю AffId.

Часть файла конфигурации руткита TDSS,
содержащая идентификатор партнера в поле AffId

Идентификатор AffId передается административной панели для указания, что на данную машину версия руткита была установлена конкретным партнером, и что платить за установку надо именно ему. При этом географическое положение зараженного компьютера определяется административной панелью на основании IP-адреса, с которого был передан идентификатор.

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

 
Предложение установить кодек для просмотра видео

Партнеры 10438 и 11418 предлагают пользователям установить генератор ключей для популярных программ, вместе с которым загружается руткит.

 
Страничка для загрузки TDSS вместе с программой для взлома

Партнер с AffId 20273 заражает компьютеры пользователей с помощью эксплойтов (Drive-by-Download), а руткиты с идентификатором 00123 были загружены на машины, входящие в два разных ботнета Zbot (ZeuS). Последнее может означать, что хозяин у данных ботнетов один.

Connect

Адреса административной панели, с которыми соединяется TDSS при первом запуске на зараженном компьютере, также указаны в файле конфигурации. Как правило, в каждом файле три таких адреса. Всего для третьей версии руткита известно 33 адреса. Административные панели расположены в Китае, Люксембурге, Гонконге, Голландии и России. Формат обращения к ним такой:

GUID — уникальный идентификатор зараженного компьютера

AffId — идентификатор партнера

Status — статус текущей задачи

erType — тип ошибки во время работы руткита

erCode — тип ошибки

OS — версия операционной системы зараженного компьютера

Работа с административной панелью осуществляется по протоколу HTTPS, при этом на серверной части используется подписанный самими злоумышленниками сертификат безопасности, выданный несуществующей компанией Internet Widgits Pty Ltd (для разработчиков этот сертификат используется как пример стандартного сертификата при работе с SSL).

 
Стандартный сертификат безопасности для C&C

Работа по протоколу HTTPS с использованием стандартного сертификата преследует две цели:

1. Помешать антивирусным решениям детектировать и блокировать сетевой трафик по специфическому содержимому пакетов.
2. Не дать возможности подделать управляющую панель для перехвата управления построенным ботнетом.

Помимо работы по защищенному соединению, третья версия TDSS использует также алгоритмы шифрования GET-запросов. Сначала запрос шифруется на доменном имени административной панели по алгоритму RC4, а затем кодируется в BASE64. И если GET-запросы TDSS предыдущих версий антивирусные решения могли перехватить и распознать, то GET-запросы третьей версии руткита распознать практически невозможно, так как рассмотрение каждого GET-запроса, отправляемого с компьютера пользователя, требует большой вычислительной нагрузки.

Пример шифрования HTTP GET-запроса TDSS

C&C

Разные версии TDSS использовали разные наборы скриптов и базы данных для управления ботами и хранения информации о них. Так, при работе TDL-2 использовался движок SENEKA (некоторые антивирусы так и назвали эту версию TDSS), а в настоящее время ботнет TDSS работает под управлением DM-Engine. Зная формат пакетов и алгоритм шифрования, можно послать специальный запрос к панели управления ботнетом, чтобы получить не только исходящие команды для инфицированных компьютеров, но и информацию о построении административной панели и содержимом ее базы данных. Специально создавая ошибки в запросах к административной панели, можно узнать о размещении и именах файлов, которые обслуживают ботнет.

Пример расположения файлов на административной панели управления TDSS

Зная формат запросов и параметры ботов, можно также выяснить, как эти параметры обрабатываются административной панелью.

Таблица работы административной панели над параметрами, передаваемыми TDSS

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

Blind SQL Injection

База данных, установленная на панели управления, ведет себя очень тихо и не позволяет получать сообщения о выполнении запросов к ней. Однако с помощью метода «cлепой инъекции» можно проанализировать результаты запросов на основании временной задержки получения HTTP-ответа. Основная проблема при использовании данного метода – это правильный подбор имен таблиц и полей, хранящихся в базе данных. Поскольку злоумышленник, разрабатывавший административную панель, использовал имена полей и таблиц, коррелирующие с названиями запросов ботов, восстановить их нетрудно.

Так, поле GUID в запросе TDSS к административной панели в коде бота именовалось SystemId, а имя таблицы, в которой хранятся все идентификаторы зараженных компьютеров, логично называется Systems. Все идентификаторы партнеров AffId хранятся в таблице Affiliates. Воспользовавшись уязвимыми числовыми полями, отправляемыми TDSS на панель управления, можно сформировать следующий запрос: в случае если количество записей SystemId, в которых содержатся идентификаторы зараженных компьютеров, больше одного, то вернуть единицу, иначе выполнить вычисление хеш-функции MD5 20 миллионов раз.

Запрос к базе данных панели управлении TDSS

Данный запрос зашифровывается, при этом в качестве ключа используется имя административной панели. После отправки запроса ответ от административной панели о его выполнении возвращается в течение секунды. Если изменить данный запрос для ста тысяч зараженных компьютеров (в случае если количество записей SystemId, в которых содержатся идентификаторы зараженных компьютеров, больше ста тысяч…и т.д.), ответ придет в течение десяти секунд.

Измененный запрос к базе данных панели управления TDSS

Формируя таким образом запросы, можно установить, что панель управления на домене 873hgf7xx60.com обслуживает 243 инфицированных компьютера, а панель на домене zz87jhfda88.com — всего 119.

На начало июня TDSS распространяли около 2000 партнеров.

Запрос к базе данных панели управлении TDSS
(В случае если количество записей AffId, в которых содержатся
идентификаторы партнеров, больше 1691, то вернуть единицу,
иначе выполнить вычисление хеш-функции MD5 20 миллионов раз)

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

From Kernel to User mode

Технология связи руткита TDSS с внешним миром не менялась с первых версий. Так, руткит читает файл config.ini, в котором по умолчанию обычно указаны следующие данные:

[main] — основная секция, идентифицирующая руткит в системе.

• Quote — цитаты из кинофильмов, мультфильмов и т.д., которые выводятся при подключении отладчика.
• Version — версия установленного руткита.
• Botid — идентификатор бота для административной панели.
• AffId — идентификатор партнера.
• SubId — по умолчанию ноль, служит для дополнительной идентификации бота при разделении ботнета.
• Installdate — дата установки руткита в системе.
• Builddate — дата сборки руткита.

[injector] — секция, указывающая на полезную нагрузку руткита.

• Первое поле содержит имя процессов (по умолчанию "*”, означает все процессы).
• Второе поле указывает на имя динамической библиотеки, которую следует подгружать к указанным процессам.

[tdlcmd] — секция полезной нагрузки.

• Servers — адреса административных панелей руткита, обычно три адреса.
• Wspservers — адреса серверов для работы с поисковыми сервисами.