Пользователь
0,0
рейтинг
18 декабря 2012 в 16:42

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

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

TDL-1


Одна из первых версий руткита была обнаружена Kaspersky Lab в апреле 2008 года, она сохраняла в системе свой драйвер tdsserv.sys, от которого и произошло название TDSS. Впоследствии имя основного драйвера несколько раз менялось на clbdriver.sys, seneka*.sys, UACd*.sys, gaopdx*.sys, tdlserv.sys и другие.
Альтернативное наименование TDL произошло из-за наличия в коде многочисленных идентификаторов, начинающихся с символов 'tdl'. Дроппер TDL-1 содержал два главных файла: непосредственно драйвер-руткит и библиотеку, в которой и находился основной функционал (полезная нагрузка). На тот момент методы перехвата функций были достаточно тривиальными и не отличались новаторством, но позволяли обойти большинство средств антивирусной защиты.
Основные функции маскировки, реализуемые драйвером:

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

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

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

При инсталляции руткита для обхода поведенческой защиты использовалась следующая техника: вредоносный код размещается в системном кеше часто используемых библиотек \KnownDLLS, откуда вызывается легитимным системным приложением при использовании им одной из этих библиотек. Конкретно TDL-1 использовался патчинг библиотеки advapi32.dll, подгружаемой сервисом Microsoft Installer, в ходе инсталляции. Более новые версии использовали патчинг библиотеки msi.dll. Таким образом, вызов кода TDL-1 производился из контекста доверенного приложения. Подробнее о методах, используемых TDL-1 можно узнать в посте Алисы Шевченко.

TDL-2


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

TDL-3


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

[main] — идентификационные данные
Quote — цитаты из кинофильмов, мультфильмов и т.д., которые выводятся при подключении отладчика;
Version — версия;
Botid — идентификатор бота для административной панели;
AffId — идентификатор «партнерской программы»;
SubId — служит для идентификации сети бота при разделении ботнета на несколько подсетей;
Installdate — дата установки в системе;
Builddate — дата компиляции.
[injector] — сопоставление внедряемых модулей и процессов
содержит список пар значений вида: имя процесса (по умолчанию “*”, означает все процессы) — имя DLL (динамической библиотеки, которую следует подгружать к указанному процессу).
[tdlcmd] — данные серверов
Servers — адреса административных панелей руткита, обычно три адреса;
Wspservers — адреса серверов для работы с поисковыми сервисами;
Popupservers — адреса серверов для открытия страниц;
Version — версия полезной нагрузки.


Распространение TDL осуществлялось при помощи так называемых «партнерских программ» или «партнерок». Согласно Википедии, «партнерская программа — это форма делового сотрудничества между продавцом и партнерами при продаже какого-либо товара или предоставлении услуг; позволяет продавцу сократить расходы на привлечение конечного покупателя». В сфере киберкриминала товаром являются вредоносные программы, а услугами — привлечение пользователей на зараженные веб-ресурсы и заражение их компьютеров. Деньги при этом платятся за каждую успешную установку. Именно для этого используется поле AffId в config.ini, для того, что бы знать, кому в каком объеме выплачивать деньги за установку бота с заданным идентификатором. Также это позволяет оценивать эффективность работы той или иной «партнерки». За содействие в распространении TDL владельцы «партнерок» получают за 1000 установок вредоносной программы от 20 до 200 USD — в зависимости от географического положения компьютера-жертвы. Конечная установка могла производиться различными способами, например путем установки фальшивых кодеков, путем внедрения бота в кейгены для популярного ПО, или распространение посредством 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 вели сами.

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

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

Продолжение здесь.
@nuklearlord
карма
83,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (17)

  • +4
    Читая статью, вдруг подумал: а каково читать такое автору TDL и прочих зверушек? Что чувствуют? Гордость от того что их труды оказались живучи? Злость что их зверушку препарировали и выяснили то что они так хитро пытались спрятать? Или удовлетворение вида: «ха, а вы еще не всё знаете...»

    А в целом статья познавательная, спасибо.
  • 0
    Интересно способны ли подобного рода буткиты обнаружить и преодолеть защиту типа Shadow Defender?
    • 0
      В продолжении будет про буткиты, они загружаются ДО операционной системы, поэтому, я думаю, обойдут Shadow Defender. Защиту от установки подписанных драйверов TDSS (TDL-3) точно обходит.
  • 0
    А в EFI буткиты ещё не научились встраивать?
    • 0
      Лично я не слышал, но есть же концептуальное ВПО, заражающее BIOS, так что не думаю, что это очень сложно реализовать. Просто пока работают старые-добрые методы, в этом нет необходимости.
  • 0
    На тему писалось много и самого разного уровня: от профессиональных обзоров, до статей для масс. Ещё раз попробуем свести всё вместе? Ну-ну…

    TDL1 и TDL2 — уже история более чем трёхлетней давности. TDL3 тоже доживает свой век. Про TDL4, ZeroAccess и прочее злободневное (но тоже уже порядком изжёванное) — ни слова.

    Давайте ещё про Win.CIH поговорим, чего уж там…
    • +6
      Об этом будет далее написано. Не хотите жевать — не жуйте =) Тут полно людей, которые с удовольствием почитают мою писанину. Собственно говоря, я и начал писать, потому что заеб устал искать, где все будет в одном месте написано. Особенно, если учесть, что большинство толковых отчетов — на английском языке.
      • 0
        Плохо искали, значит. Начните с блогов Касперского и ДрВеба.

        Впрочем, Вы правы: будем рассматривать Вашу статью как Ваш личный блокнот. Кому это будет интересно — посмотрим, оценка покажет.

        Имхо, статья ни о чём — но это моё мнение.
        • +1
          <сарказм>Спасибо, что подсказали, не знал</сарказм> Ключевая информация — в одном месте, а не в десятках статей на нескольких сайтах.
          • +1
            Что же тут такого ключевого и нужного, что бы париться, собирать всё в одном месте?
            Популярная беллетристика, не более того…
            • 0
              Большое спасибо. Не все же такие благодарные читатели, как вы. Кое-кто и мою « беллетристику» читает =)
  • 0
    очень нравится ваш цикл статей. продолжайте в том же духе, спасибо!
  • +3
    Уважаемые читатели, большое вам спасибо за поддержку. Естественно, на этом ресурсе есть пользователи, которым по каким-то причинам (каким, мне так никто и не высказал) не нравится мое творчество. Я здесь пишу не ради рейтинга или кармы. Во-первых, мне интересно в этом разбираться, причем не так детально, как описывают сотрудники антивирусных компаний. Во-вторых, я буду только рад, если кто-то начнет понимать какие-то моменты лучше. Конечно, мне немного неприятно, когда мои опусы называют никому не нужными, но по голосованию я вижу, что это не так. Так что, уважаемые товарищи критики, можете продолжать свои выпады. Только не отожествляете свое мнение с мнением большинства заинтересованных людей. А я продолжу растекаться словом по экрану ваших мониторов =)
  • 0
    TDL-3 перехватывал обращения к диску и в случае просмотра его «личных» секторов возвращал их содержимое в исходном, неизмененном виде.
    Где хранилось исходное содержимое перезаписаных секторов?
    • 0
      Да, здесь неоднозначность — если кто-то пытается прочитать содержимое зараженного драйвера – руткит возвращает данные соответствующие оригинальному, а если приложение пытается прочитать область данных файловой системы руткита, то он возвращает буфер, забитый нулями. Поправил, спасибо за вопрос.
  • 0
    Ссылка может вести как на вредоносный сайт (например, для установки другого ВПО)

    Непонятно, зачем переадресовывать на сайт для загрузки впо, если можно выполнить команду DownloadAndExecute
  • 0
    Например, для организации партнерки — в случае, если у злоумышленников нет конечного exe файла для распространения, или этот файл должен меняться все время (в зависимости от географического расположения), или при использовании server-side полиморфизма. Таким образом, логика распространения переносится на сервер и нет необходимости постоянно менять боту свой конфиг. Кроме того, вредоносный сайт может не устанавливать ВПО, а использоваться как средство увода паролей, то есть представлять собой копию страницы авторизации легитимного сайта.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.