Больше руткитов — «хороших» и разных. Опции

[Пастор]

Порой различия в стиле написания и применяемых принципах работы вредоносного программного обеспечения значительно отличается от образца к образцу. Одни делают ставку на полиморфизм, другие на руткит компоненту. Особенно в плане развития руткит технологий отличилось семейство ВПО TDL. Как известно, новое — это хорошо забытое старое. На заре развития персональных ЭВМ, основную массу ВПО составляли вирусы, которые подразделялись на два класса — файловые и загрузочные (были и комбинированные, например, печально известный OneHalf). Достойным продолжателем дела загрузочных вирусов является буткит TDSS (TDL-4), хоть и является троянской программой (не способной самостоятельно распространяться). Буткит – слово, образованное из слов бут (boot, загрузочная область) и руткит (rootkit, средство сокрытия признаков деятельности). Но прежде чем стать буткитом, TDL проделал большой путь.

TDL-1

Первая версия TDL была обнаружена Kaspersky Lab в апреле 2008 года, назван так по наличию многочисленных идентификаторов, начинающихся с символов 'tdl'. Дроппер TDL-1 содержал два главных файла: непосредственно драйвер-руткит clbdriver.sys и библиотеку clbdll.dll, в которой и находился основной функционал (полезная нагрузка). На тот момент методы перехвата функций были достаточно тривиальными и не отличались новаторством.

Основные функции маскировки, реализуемые clbdriver.sys:

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

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

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

TDL-2

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

TDL-3 (Olmarik)

Осенью 2009 года появилась третья версия, содержащая в себе множество технических новинок. Для получения управления после перезагрузки применялся метод инфицирования системных компонентов ОС (драйверов). Для заражения использовался мини-порт/порт драйвер диска, в более поздних модификациях TDL-3 случайным образом выбирал и заражал системные драйверы, подходящие по некоторым параметрам. В драйвер внедрялся небольшой участок вредоносного кода, который выполнял функции загрузчика, при этом исходный размер драйвера оставался неизменным. Исходные данные, которые замещались, сохранялись вместе с основным кодом в специально выделенном месте в конце жесткого диска. Последние несколько секторов диска организовывались в своеобразное зашифрованное хранилище данных со своей собственной файловой системой, для работы с ним создавалось виртуальное устройство. В этом хранилище так же располагались блоки данных конфигурации. TDL-3 перехватывал обращения к диску и в случае просмотра его «личных» секторов возвращал их содержимое в исходном, неизмененном виде. Блок данных конфигурации (config.ini) неизменен для всех трех версий, он содержит следующие данные:



[main] — идентификационные данные

Quote — цитаты из кинофильмов, мультфильмов и т.д., которые выводятся при подключении отладчика;

Version — версия;

Botid — идентификатор бота для административной панели;

AffId — идентификатор «партнерской программы»;

SubId — служит для идентификации сети бота при разделении ботнета на несколько подсетей;

Installdate — дата установки в системе;

Builddate — дата компиляции.

[injector] — сопоставление внедряемых модулей и процессов

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

[tdlcmd] — данные серверов

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

Wspservers — адреса серверов для работы с поисковыми сервисами;

Popupservers — адреса серверов для открытия страниц;

Version — версия полезной нагрузки.



Распространение TDL осуществлялось при помощи так называемых «партнерских программ» или «партнерок». Согласно Википедии, «партнерская программа — это форма делового сотрудничества между продавцом и партнерами при продаже какого-либо товара или предоставлении услуг; позволяет продавцу сократить расходы на привлечение конечного покупателя». В сфере киберкриминала товаром являются вредоносные программы, а услугами — привлечение пользователей на зараженные веб-ресурсы и заражение их компьютеров. Деньги при этом платятся за каждую успешную установку. Именно для этого используется поле AffId в config.ini, для того, что бы знать, кому в каком объеме выплачивать деньги за установку бота с заданным идентификатором. Также это позволяет оценивать эффективность работы той или иной «партнерки». Конечная установка могла производиться различными способами, например путем установки фальшивых кодеков, путем внедрения бота в кейгены для популярного ПО, или распространение посредством cвязки эксплойтов (exploit pack).

Обмен данными с управляющим серверами TDL производился по протоколу HTTPS, для этого злоумышленниками использовался самоподписанный сертификат безопасности (который находился на сервере), выданный вымышленной компанией Internet Widgits Pty Ltd. Использование HTTPS не позволяло антивирусам детектировать и блокировать сетевой трафик по содержимому пакетов. Кроме того, в TDL-3 GET запросы дополнительно шифровались с использованием симметричного алгоритма RC4.

Основная цель TDL — монетизация, на основе созданного с его помощью ботнета. TDL имел модульную структуру и позволял загружать дополнительные модули (в виде DLL) по сети. Одним из модулей, устанавливаемый TDL по умолчанию была библиотека tdlcmd.dll, выполняющая следующие задачи:

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

Список команд, поддерживаемых tldcmd.dll:

• DownloadCrypted — загрузить зашифрованный файл;
• DownloadAndExecute — загрузить и исполнить файл;
• DownloadCryptedAndExecute — загрузить зашифрованный файл, расшифровать и исполнить его;
• Download — загрузить файл;
• ConfigWrite — внести изменения в файл конфигурации.

Перехват пользовательских запросов с целью подмены выдачи производился для популярных поисковых систем, таких как Google, Yahoo, Bing и др. При каждом запросе к таким сайтам tdlcmd.dll генерирует запрос к серверу, указанному в поле Wspservers файла конфигурации. В ответ от сервера приходит ссылка на страницу, которую необходимо отобразить пользователю. Ссылка может вести как на вредоносный сайт (например, для установки другого ВПО), так и на легитимный (накрутка баннеров).

Интересная функция tdlcmd.dll — механизм для недобросовестного «продвижения» сайтов по ключевым словам (Black Seo). Для его работы в хранилище TDK создается файл keywords, содержащий слова, которые необходимо адресовать поисковой системе. Затем в выдаче поисковой системы выбирается сайт, указанный злоумышленниками. При этом, для убедительной имитации работы пользователя, использовался javascript, встраиваемый в браузер и имитирующий нажатие на соответствующие элементы управления (кнопки, ссылки и т.д.).

Еще одним способом монетизации была продажа части ботнета, именно в этих целях в config.ini находился параметр SubId. Продаже подлежали подсети ботнета количеством до 20 000 компьютеров. В остальном свой преступный бизнес создатели TDL вели сами.

Несмотря на некоторые уловки для защиты от потери управления, скрипты командного центра содержали в себе уязвимости, что позволило некоторым исследователям компьютерной безопасности успешно произвести взлом. Подробности одного из них доступны здесь. Согласно информации, полученной из баз данных взломанного сервера, общее количество компьютеров, заражённых руткитом TDL-3 в период с 12.08.2009 по 14.07.2010, составило более 16 000 000 компьютеров. Естественно, что это общее количество. Реально «живых» ботов было порядка 5 000 000. Большее их количество (43%), находилось в США. Это можно объяснить большей денежной отдачей от накрутки баннеров в этой стране.

TDL-4

Разработчики TDL продолжают идти в ногу со временем. На этот раз их взор устремился на неохваченные ранее 64 битные системы. Во-первых — появилось разделение рабочих файлов на 32 и 64 разрядные версии. Во-вторых — в очередной раз изменился алгоритм запуска после перезагрузки. Ранее подобный алгоритм применялся в ВПО Sinowal, достаточно известном своими новациями сотрудникам антивирусных компаний. Теперь TDL версии 4 заражал главную загрузочную запись (MBR). Данный способ позволяет ему загружаться раньше операционной системы, сразу после старта компьютера. Таким образом, TDL-4 из руткита «мутировал» в буткит. Как и ранее, компоненты TDL-4, хранились в специальной области жесткого диска, зашифрованные алгоритмом RC4. Код в MBR передавал управление компоненту ldr16 (из хранилища). После передачи управления ldr16 производил перехват функций работы с жестким диском (ОС еще не загружена). Для загрузки TDL-4 использовалась подмена файла kdcom.dll (путем установки перехватчика на Int 13h и поиска определенной сигнатуры kdcom.dll), который необходим для инициализации ядра операционной системы на стадии загрузки. Вместо kdcom.dll в итоге загружался вредоносный компонент ldr32 или ldr64 (из хранилища) в зависимости от разрядности целевой ОС. Бинарный код ldr32 и ldr64 практически идентичен, так как они скомпилированы из одного исходного кода. Но, кроме разницы в коде, в 64 битных системах, начиная с Windows 2003 x64 (XP x64 и далее Vista, Seven), появилось несколько технологий, направленных на защиту от вредоносного воздействия. Одна из них — Patch Guard, которая отслеживает изменение критических объектов ядра ОС, таких как:

• таблица глобальных дескрипторов — GDT;
• таблица дескрипторов прерываний — IDT;
• таблица дескрипторов системных сервисов — SSDT;
• некоторые системные файлы, например, NTOSKRNL.EXE, NDIS.SYS, HAL.DLL;
• служебные MSR регистры STAR/LSTAR/CSTAR/SFMASK.

При загрузке, в рамках Patch Guard, ОС подсчитывает контрольные суммы для указанных выше объектов, сохраняет их и периодически проверяет соответствие текущих значений с сохраненными. Обнаружив модификацию объектов (по изменению контрольной суммы), ОС аварийно завершает свою работу с отображением BSOD. Кроме Patch Guard, появился еще один защитный механизм — обязательная проверка цифровой подписи для загружаемых системой драйверов. Однако примененный алгоритм загрузки позволил успешно обойти оба вышеуказанных механизма, так как TDL-4 получает управление до загрузки ОС. Для обхода проверки целостности файла kdcom.dll, ldr16 на некоторое время изменял Boot Configuration Data (BCD), ветку реестра, которая используется менеджером загрузки Windows и поддерживается, начиная с Windows Vista (этот механизм заменил собой boot.ini). BCD имел три различных опции загрузки:

• BcdLibraryBoolean_DisableIntegrityCheck – принудительное отключение проверки (чаще всего используется для отладочных целей);
• BcdOSLoaderBoolean_WinPEMode – отключение в режиме установки или восстановления ОС;
• BcdLibraryBoolean_AllowPrereleaseSignatures – разрешить загружать модули, имеющие тестовую цифровую подпись.

TDL-4 переключал режим загрузки в BcdOSLoaderBoolean_WinPEMode. После успешной загрузки ldr32 (ldr64) производил загрузку основных модулей (руткит и полезная нагрузка) и данный режим отключался. Сама техника перехвата функций была аналогична примененной в TDL-3. В совокупности с заражением MBR, это позволило надежно скрыть свое функционирование от антивирусных средств того времени.



Следует отметить, что разработчики TDL-4 несколько раз сталкивались с проблемами некорректной работы после установки обновлений от Microsft. В феврале 2010 вышло неплановое обновление от Microsoft MS10-015. Данный патч устранял уязвимость, которая позволяет локально повысить свои привилегии, и вносил модификации непосредственно в ядро ОС. После этого патча некоторые пользователи стали жаловаться на появление BSOD. Позже выяснилось, что указанные компьютеры были заражены TDL-4 и BSOD вызывала его некорректная загрузка. Это связано с использованием неявных вызовов WinAPI функций по их смещению в памяти, при обновлении произошли модификации, в результате чего, адреса функций стали другими, и код TDL перестал работать, как задумано. Из-за этой ошибки разработчиков численность ботнета значительно сократилась, особенно в США, где основная масса пользователей пользуется лицензионной Windows с включенным механизмом обновления (источник).



В апреле 2011 кода Microsoft выпустило обновление KB2506014, задачей которого было внести несколько изменений в модуль winloader.exe 64 разрядных версий ОС для противодействия загрузке не подписанных драйверов. В результате BCD лишился опции BcdOSLoaderBoolean_WinPEMode, которую использовал TDL-4 для своей загрузки. Его разработчики отреагировали выпуском обновленной версии TDL-4, в которой вместо переключения в режим WinPE модифицировалась процедура I_CheckImageHashInCatalog. С помощью этой процедуры проверяется целостность модулей, загружаемых программой winload.exe. TDL-4 менял алгоритм ее работы, что бы при несовпадении хэшей все равно возвращался результат, что все верно. Правда, данный механизм работал не совсем стабильно (источник).



В работе новой версии TDL остался неизменным способ распространения — с помощью партнерских программ. По сравнению с предыдущей версией произошло обновление алгоритма шифрования протокола, используемого для связи с командным центром. Вместо RC4 стал использоваться «самопальный» алгоритм шифрования с использованием операции XOR. В конфигурационном файле появился новый параметр bsh — идентификатор, который выставляется управляющим сервером при первом соединении с ним бота. Шифрование протокола теперь осуществлялось на его основе. Таким образом, поток данных от каждого бота шифровался разными ключами, что еще более усложнило процедуру мониторинга трафика средствами обнаружения ВПО антивирусных компаний.



TDL-4 обзавелся своеобразной «антивирусной» компонентой, которая удаляет около 20 вредоносных программ, например, Gbot, ZeuS, Clishmic, Optima и др. Такой «антивирус» помогает бороться с конкурентами, а так же уменьшить вероятность обнаружения, вызванное присутствием на зараженном компьютере других вредоносных программ.



Арсенал «полезных нагрузок» пополнился модулем SOCKS прокси. Наличие такого модуля позволяет анонимно посещать ресурсы Сети. В сети можно найти большое количество сайтов, предлагающих на платной основе услуги предоставления IP адресов анонимных прокси, большинство из которых как раз являются адресами зараженных ВПО компьютеров.



Несмотря на предпринятые злоумышленниками меры по защите управляющих серверов ботнета, зная протокол общения TDL-4 с управляющими серверами, антивирусные компании получили статистику по количеству зараженных компьютеров. Анализ полученных данных выявил около 60 доменных имен командных центров, которые по технологии Double Fast Flux перенаправлялись на три различных сервера.



Термин «Fast Flux» (дословно переводиться как 'быстрое течение' или 'поток') относится к быстрому многократному внесению изменений в записи DNS, что приводит к постоянному изменению IP-адреса, к которому относится доменное имя. Сама по себе технология Fast Flux не является «вредоносной», так как не использует какие-либо уязвимости DNS и обычно используется для распределения нагрузки на сервера. В классической схеме одному доменному имени соответствуют несколько десятков IP адресов, которые меняются каждые несколько минут (схема Single Fast Flux). Это уже делает неэффективным блокировку трафика ботов по IP адресам. Злоумышленники же несколько усовершенствовали схему — сервер DNS возвращает не конечный адрес самого командного центра, а адрес одного из большого количества зараженных компьютеров, каждый из которых представляет собой прокси на реальный управляющий сервер (схема Double Fast Flux). Базы данных MySQL, поддерживающие работу ботнета, функционировали на 3 серверах, расположенных в Молдавии, Литве и США. Согласно информации из этих БД, за три первых месяца 2011 года TDL-4 было заражено около 4,5 миллионов компьютеров по всему миру, около 28% из них находились в США.



Наиболее интересным нововведением стало появление «полезной нагрузки» kad.dll, предназначенной для обмена информацией между ботами TDL-4 посредством сети P2P. Ботнеты, использующие P2P, уже не редкость, однако большинство их реализаций основывались на своей собственной закрытой сети. TDL-4 же использует уже существующую публичную сеть обмена файлами Kad. В данном случае архитектура P2P сети была частично децентрализованной (подробнее тут). Библиотека kad.dll загружала список пиров (bootstrap list) с одного из командных серверов в виде файла nodes.dat. На одном из компьютеров сети Kad, («чистом» или «зараженном»), размещался файл ktzerules, который содержал в зашифрованном виде список команд ботам и снабжен цифровой подписью. Перечень команд, которые могли находиться в ktzerules:

• SearchCfg — поиск нового файла ktzerules в сети Kad;
• LoadExe — загрузить и запустить исполняемый файл;
• ConfigWrite — внести запись в cfg.ini;
• Search — искать файл в сети Kad;
• Publish — опубликовать файл в сети Kad;
• Knock — загрузить с C&C новый файл nodes.dat, содержащий список IP-адресов серверов и клиентов сети Kad, в том числе зараженных TDSS компьютеров.

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



Начиная с мая 2012 года, в составе TDL-4 появился DGA. Кстати, DGA с точки зрения технической реализации намного проще, чем развертывание сетевой инфраструктуры управляющих серверов по технологии Double Fast Flux. Естественно, что этим тут же воспользовались антивирусные компании для сбора статистики текущего распространения через sinkhole маршрутизатор. Исследователи Kaspersky Lab выявили 85 серверов и 418 уникальных доменов, обслуживающих версию TDL-4 c DGA. Наибольшее количество C&C обнаружено в России (26 хостов), Румынии (15) и Голландии (12).

Мысли вслух

Как видно, создатели TDL пошли по более трудоемкому пути, написание руткитов уровня ядра — довольно нетривиальная задача. Во всем этом угадывается некий «олд скул», то есть, злоумышленники не только преследуют финансовые цели, но и некоторым образом постоянно доказывают антивирусным компаниям и фирме Microsoft, что «их кун-фу лучше». Применяемые разработчиками TDL методы опережают в своем развитии способы противодействия антивирусов и компонентов защиты ОС. В то же время большинство атак APT, направленных на получение конфиденциальной информации, довольствуется простой методикой подписи кода, для обхода средств защиты, не используя какое-либо сокрытие. В этом есть определенный экономический смысл. Разработчики TDL минимизируют убытки, сами разрабатывают код, не используют краденые сертификаты для подписи, используют распространенные эксплоиты. Их метод — продолжительная работа в условиях невидимости. За кибершпионами же стоят люди с очень большими деньгами (не обязательно государства, просто конкуренты). Здесь превалирует принцип — быстро «слил» нужную информацию и исчез. В процессе кражи секретов немаловажную роль играет то, что сам факт кражи не должен быть обнаружен. Поэтому там и краденые подписи крупных вендоров, и zero-day уязвимости и другие «дорогие» штучки. То есть более простые техники обхода (в техническом смысле — купил, скомпилировал, работает) по немаленьким ценам. С другой стороны, если брать за основу цифру в 20$ за 1000 установок в рамках «партнерской» программы и цифру в 20 миллионов заражений с 2009 по 2011 годы (16 TDL-3 и 4 TDL-4), получается, что создатели TDL тратят порядка 200 тысяч долларов в год только на распространение. То есть деньги у них имеются. Также следует отметить, что для монетизации прибыли TDSS использует методы, «крадущие» вычислительные мощности зараженных компьютеров, но не наносят пользователю финансовый вред непосредственно. Эти методы — накрутка баннеров, Black Seo, предоставление сервиса анонимизации — вероятно выбраны, что бы правоохранительные органы были меньше заинтересованы в расследовании. Плюс сама группа, судя по всему, русскоязычная, поэтому компьютеры в странах бывшего СССР, по возможности, не заражаются.

nuklearlord

[hook]

Качаем улиту GMER, сканируем и удаляем эти злосчастные руткиты.