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

в 14:51, , рубрики: bootkit, cyberthreat, Malware, rootkit, tdl, tdss, Вирусы (и антивирусы), информационная безопасность, метки: , , , , ,

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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js