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

Эта мировая тенденция имеет своё отражение и в контексте современной России. Пример с бразильскими троянами-банкерами вполне соответствует нашей ситуации — с той лишь разницей, что русские разработчики вредоносных программ в целом более изобретательны и профессиональны относительно мирового уровня, и «поделками» на Visual Basic дело в данном случае не ограничивается.

Система ДБО, онлайн-банкинг, банк-клиент — средства дистанционного банковского обслуживания.

За последние 1–2 года распространённость различных систем электронной коммерции в России достигла критической массы, начав привлекать внимание организованной преступности. Если пару лет назад большинство троянов-банкеров, в том числе и разработанных в России, были «заточены» под интернет-системы зарубежных банков, то теперь всё чаще производятся атаки и на российские системы электронных платежей (Webmoney, Yandex.Money), системы собственной разработки отдельных банков, а также универсальные платформы для систем ДБО (Inter-PRO Client, BS-Client, iBank и других). Тенденция появления эффективных схем атаки на универсальные платформы ДБО заслуживает особого внимания, так как она ставит под угрозу практически все российские банки и коммерческие организации.

Цель данной статьи — осветить современные тенденции в области атак на системы электронной коммерции. В первой части статьи приводится обзор технологий и схем атаки. Во второй части описаны результаты анализа шпионской программы Ibank, обеспечивающей атаку на целый ряд популярных систем ДБО российского производства.

Обзор методов атаки Технологии

СКЗИ — средство криптографической защиты информации.

Большинство современных систем электронных платежей реализованы на основе технологии «тонкого клиента». Пользователь работает с онлайн-банкингом как с обычным веб-сайтом, а аутентификация пользователя и шифрование трафика обеспечивается с помощью отдельного приложения. В роли этого приложения может выступать одна из доступных на рынке платформ ДБО, таких как BS-Client (BSS) или Inter-PRO (Сигнал-КОМ), либо система собственной разработки банка. Платформа ДБО, в свою очередь, опирается на систему криптопровайдера с государственной аккредитацией (СКЗИ), такую как «Агава» или «Бикрипт», для обеспечения шифрования по алгоритмам ГОСТ.

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

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

Логин, пароль, ключевые файлы

Вход в интернет-систему банка с использованием логина, пароля и секретного ключа является классической реализацией двухфакторной аутентификации. Это наиболее уязвимая схема защиты. Несмотря на то, что универсальные платформы для систем ДБО позволяют подключать дополнительные средства защиты, такие как аппаратные ключи, защита с использованием логина, пароля и сертификата остаётся «вариантом по умолчанию», и именно он используется в большинстве реализаций онлайн-банкинга.

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

Захват файлов ключей может быть реализован с помощью следующих техник:

• непосредственное копирование файлов ключей;

• копирование ключей путём перехвата файловых операций в контексте браузера или целевой программы;

• экспорт сертификатов из хранилища браузера;

• перехват сертификатов в момент их использования пользователем.

Файлы ключей в большинстве систем не защищены от копирования, если только речь не идет об аппаратных средствах защиты, таких как eToken PRO. При экспорте сертификатов из хранилища браузера троян может при необходимости подбирать пароль на экспорт, установленный пользователем.

Захват логина и пароля может быть реализован следующими способами:

• перехват всех нажатий клавиш в системе;

• перехват нажатий клавиш в контексте браузера или целевой программы;

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

• перехват HTTP-запросов к целевому банку с последующим извлечением логина и пароля из полей HTTP-запроса.

Для отсева лишней информации шпионская программа может осуществлять поиск таких объектов, как заголовки окон интернет-банка, названия полей ввода, элементы URL и т. п. Идентификация ключевых файлов может осуществляться по имени, части пути или по сигнатуре — например, ключевые файлы универсальной системы ДБО iBank идентифицируются троянами по сигнатуре iBKS в момент обращения к ним пользователя.

Аппаратные ключи

Аппаратный ключ, или «токен», — персональное электронное устройство, участвующее в процессах защиты информации пользователя (таких как аутентификация и шифрование данных).

Аппаратные ключи («токены») используются в качестве средства для усиления защиты. Существует несколько классов аппаратных ключей, реализующих принципиально разные схемы защиты. С точки зрения атаки разница между классами аппаратных ключей играет незначительную роль. В частности, обобщённый метод атаки на все виды аппаратных ключей заключается в перехвате инициированной пользователем транзакции с подстановкой в неё данных для совершения несанкционированного перевода на счёт атакующего.

Рассмотрим более подробно техники атаки на два наиболее популярных класса аппаратных ключей: «токены», реализующие генерацию одноразовых паролей (на примере eToken PASS), и аппаратные ключи, реализующие хранение секретных ключей и аппаратные криптовычисления (на примере eToken PRO).

Аппаратный ключ eToken PASS представляет собой брелок, реализующий выдачу одноразового пароля по запросу пользователя. Полученный пароль может использоваться для дополнительной защиты авторизации и/или отдельных действий пользователя. Верификация пароля осуществляется на стороне сервера.

Для обхода этой схемы защиты, помимо вышеописанного метода «подмены данных транзакции», возможен также вариант перехвата одноразового пароля. В частности, после ввода пользователем сеансового пароля троянская программа отображает сообщение об ошибке или блокирует действия пользователя, тем временем инициируя злонамеренную транзакцию с использованием захваченного пароля.

Аппаратный ключ eToken PRO обеспечивает защищённое хранение секретного ключа пользователя, а при необходимости и выполнение криптографических вычислений на микросхеме устройства. В данном случае получение секретного ключа затруднено — таким образом, атакующий не может получить все необходимые данные для удалённого доступа к системе банка.

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

В ряде случаев задача сводится к более простой — например, если аппаратный ключ используется только на этапе авторизации в качестве секретного ключа, трафик шифруется по стандартному алгоритму SSL, а к открытому сеансу прикреплён постоянный идентификатор, то возможно сымитировать ложную транзакцию путём отправки серверу системы стандартных HTTP-запросов с использованием идентификатора открытого сеанса. Таким образом, атака возможна в любом случае, а степень её сложности всецело зависит от деталей реализации конкретной схемы защиты.

Одноразовые пароли

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

В предыдущем разделе описан один из вариантов реализации этой защиты — с использованием генератора одноразовых паролей eToken PASS. Второй вариант, более популярный в силу его дешевизны, заключается в предоставлении пользователю массива одноразовых паролей — например, в виде пластиковой карты с заштрихованными кодами. Такой метод дополнительной защиты используется в системе «Телебанк» ВТБ24.

Стандартная техника атаки в данном случае идентична атаке на eToken PRO: троян перехватывает очередной переменный код, введённый пользователем, отображает сообщение об ошибке и использует полученный код для проведения нелегальной транзакции.

SSL и шифрование

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

Чтение и модификация открытых данных SSL-трафика могут производиться при помощи перехвата стандартных функций библиотеки Wininet для браузера Internet Explorer, функций PR_Read/PR_Write библиотеки nspr4.dll для браузера Mozilla и неэкспортируемой функции из библиотеки opera.dll для браузера Opera.

Проверка IP-адреса клиента

В качестве дополнительной меры защиты на сервере ДБО может быть реализована проверка IP-адреса пользователя перед аутентификацией. В таком случае атакующий не сможет удалённо подключиться к интернет-банку, даже имея логин, пароль и ключи легитимного пользователя.

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

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

Мишени

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

Наиболее популярными мишенями для финансового мошенничества являются следующие социально-экономические классы:

• клиенты банков;

• пользователи электронных платёжных систем;

• малый и средний бизнес;

• крупные коммерческие организации;

• банки и другие финансовые учреждения;

• системы денежных переводов.

ЭПС — электронная платёжная система, например Webmoney, Yandex.Money, Paypal.

Клиенты банков и пользователи ЭПС представляют собой наиболее лёгкую добычу, но и наименее популярную в силу их низкой платёжеспособности. Кроме того, отъём денег у основной массы населения интернета проще осуществить путём прямого вымогательства — что и делают при помощи троянов-вымогателей, таких как SMS-блокировщики рабочего стола и шифровальщики файлов. Тем не менее в среде мелких киберворишек по-прежнему пользуются популярностью зарубежные пользователи интернет-банков, привлекательность которых обусловлена экономическим разрывом между странами жертвы и атакующего.

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

Внутри инфраструктуры финансовых учреждений также используются автоматизированные финансовые системы. С точки зрения механизмов атаки система для внутреннего использования практически ничем не отличается от клиентской ДБО: в обоих случаях атака производится методом внедрения трояна на обычный компьютер.

СДП — система денежных платежей, например Western Union, Contact.

«Дроп» («money mule») — лицо, сознательно или вследствие обмана играющее роль посредника при обналичивании украденных денежных средств.

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

Схемы

При совершении финансовых махинаций злоумышленники чаще всего применяют одну из трёх типовых схем атаки.

1. Кража данных для входа в систему

Классическая схема атаки заключается в краже с компьютера пользователя полного комплекта аутентификационных данных и дальнейшем использовании этих данных атакующим для удалённого подключения к системе банка или ЭПС с целью осуществления нелегального перевода. Если на стороне сервера осуществляется проверка IP-адреса, то соединение атакующего туннелируется через компьютер легитимного пользователя.

Это самая простая схема атаки, однако она возможна только при низком (а в современных российских реалиях — «стандартном») уровне защиты целевой системы.

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

2. Атака изнутри компьютера «жертвы»

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

В качестве платформы для реализации этой схемы часто используется троян Zeus (Zbot), для которого за дополнительную плату доступен модуль удалённого доступа по протоколу VNC. При этом, если адрес целевого компьютера недоступен из интернета, троянская программа может обеспечить обратный канал связи для доступа атакующего.

3. «Автозалив»

Третья схема атаки подразумевает автоматизацию предыдущей схемы. Автоматизация осуществляется преимущественно для систем на основе технологии «тонкий клиент», так как в этом случае задача сводится к модификации данных HTML-страниц и HTTP-запросов и, таким образом, может быть компактно описана в файле конфигурации и передана троянской программе.

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

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

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

Анализ вредоносной программы Ibank

Троян Ibank представляет собой шпионскую программу массового распространения, предназначенную для реализации атак на российские системы электронной коммерции. Целевые системы включают в себя популярные универсальные платформы для построения систем ДБО, системы собственной разработки отдельных банков, электронную платёжную систему WebMoney и ряд СКЗИ.

Ibank примечателен по следующим причинам:

• это самый универсальный шпион конфиденциальной информации, относящейся к платёжным системам;

• это первый троян-банкер, разработанный для атак на российские банки;

• в настоящий момент троян Ibank активно распространяется: ежедневно обнаруживается, по данным нескольких антивирусных компаний, от 5 до 20 новых версий трояна.

Но главная особенность данного трояна заключается в том, что он широко используется в качестве инструмента для целевых финансовых атак, часто в связке с трояном Zeus. При этом Ibank используется для первоначального получения информации о платёжных системах, а Zeus — в качестве универсального инструмента для управления заражённым компьютером, в том числе для обеспечения удалённого доступа к нему.

Общие сведения

Троян Ibank появился в 2006 году. Первоначально он использовался для нецелевых атак на пользователей интернет-банков, но позднее нашёл применение в качестве инструмента при проведении организованных атак. Весной 2010 года пресс-службой компании Dr. Web было отмечено широкое распространение данной вредоносной программы.

Ibank определяется разными антивирусами под следующими именами: Trojan.PWS.Ibank, Backdoor.Win32.Shiz, Trojan-Spy.Win32.Shiz, Backdoor.Rohimafo и другими.

Существует две разновидности данного трояна: основной модуль и его загрузчик. Распространение загрузчика происходит по классической «партнёрской» схеме, о чём свидетельствует поле seller первого HTTP-запроса, отправляемого успешно установленным загрузчиком на сервер для запроса файла конфигурации:

Загрузчик получает инсталлятор трояна по ссылке, указанной в файле конфигурации, и запускает его.

Инсталлятор трояна представляет собой зашифрованный файл размером около 100 кБ (MD5: 53aec556c00f34182a72ba8edfb8fca9). Код вредоносной программы реализован на языке C и выполняется в режиме пользователя. С технической точки зрения троян достаточно прост, однако особенности его реализации отражают высокий уровень осведомленности разработчика о внутренних механизмах различных систем ДБО.

Инсталляция и особенности функционирования

Ibank устанавливается в системную директорию (c:\windows\system32) в виде отдельного исполняемого модуля со случайным именем.

На этапе установки троян блокирует доступ к целому ряду IP-адресов путём задания для них заведомо неверных настроек маршрутизации. Для этого вызывается команда route, устанавливающая ложный шлюз для каждого заданного IP-адреса.

Команда настройки маршрутизации и часть списка IP-адресов в теле программы

Автозагрузка трояна при старте Windows обеспечивается записью в ключ реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit.

Работающий троян не имеет собственного процесса. Его код внедряется в системный процесс (svchost.exe, services.exe и другие, в зависимости от версии трояна). Выполнение вредоносного кода в контексте доверенного системного процесса позволяет обходить фаерволы.

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

Помимо шпионской функциональности, Ibank оснащен следующими функциями:

• простой системой приёма команд (см. раздел «Удалённое управление»);

• функцией незаметной модификации трафика пользователя с целью автоматизации нелегальных транзакций и сокрытия нежелательных данных (см. раздел «Технология автозалива»);

• функцией настройки таблицы маршрутизации зараженного компьютера по команде от атакующего;

• функцией открытия прокси-сервера SOCKS на случайном порту;

• техниками блокирования антивирусов Kaspersky, Avira, AVG и CA HIPS (см. раздел «Блокирование антивирусов»).

Шпионская деятельность

После установки троян перехватывает ряд функций API (см. раздел «Механизм сбора данных») и ищет в проходящей через перехватчики информации появления определённых маркеров, сопутствующих обращению пользователя к той или иной системе электронной коммерции. Когда маркер найден, соответствующие данные (файлы ключей, логины и пароли) перехватываются и немедленно отсылаются на сервер, указанный в коде программы.

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

1. перехват нажатий клавиш в контексте браузера, отдельных процессов, отдельных окон и полей ввода;

2. перехват трафика HTTPS в контексте браузеров;

3. копирование ключевых файлов и сертификатов;

4. экспорт сертификатов из браузеров, в том числе с подбором паролей;

5. сбор данных непосредственно из HTTP-запроса к серверу системы;

6. сохранение истории веб-запросов;

7. сохранение удалённых и восстановленных файлов (.chk).

Механизм сбора данных

Локализация и сбор персональных данных пользователя обеспечивается установкой перехватов на следующие функции:

Код перехватчиков обеспечивает отсев данных, сбор информации и вызов процедуры отправки её на сервер.

Ряд перехваченных функций не являются стандартными API Windows. Среди них функция vb_pfx_import из модуля sks2xyz.dll, входящего в состав универсальной платформы ДБО «Фактура», на основе которой функционирует, к примеру, интернет-банк «Сбербанка», и функция RCN_R50Buffer из модуля FilialRCon.dll, входящего в состав интернет-системы «РайффайзенБанк». Кроме того, с целью получения доступа к открытому трафику SSL осуществляется перехват функций PR_Write из динамической библиотеки браузера Mozilla и неизвестной функции из библиотеки Opera.

Также стоит отметить перехват стандартной функции TranslateMessage, реализующий захват данных из контекста Java-приложений.

Целевые системы

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

Как видно из таблицы, троян нацелен на все популярные универсальные системы ДБО и, таким образом, обеспечивает кражу данных большинства российских банков.

В ряде случаев данные извлекаются не из платформы ДБО, а из стандартного СКЗИ, обеспечивающего криптооперации с ней.

Собранные данные хранятся перед отправкой в виде текстовых файлов и zip-архивов со следующими именами: pass.log, keylog.txt, ctunnel.zip, keys.zip, links.log.

Блокирование антивирусов

Отключение антивируса Kasperky производится путём отправки легитимного управляющего сообщения его окну:

Отключение Avira производится путём вызова легитимной функции, экспортируемой одной из библиотек антивируса:

Отключение AVG производится путём закрытия процесса программы и записи мусора в файл драйвера:

И наконец, отключение CA HIPS производится путём отправки легитимного кода управления устройству драйвера антивируса:

Сетевая активность

Троян выполняет следующие действия по обмену данными:

• непосредственно после инсталляции открывает случайный порт, на котором принимает входящие соединения в качестве прокси-сервера SOCKS;

• отсылает на сервер путем HTTP-запросов базовую информацию о заражённом компьютере: имя пользователя, имя компьютера, номер порта прокси-сервера;

• получает с сервера файл конфигурации с командами (см. раздел «Удалённое управление»);

• после сбора данных отправляет их на сервер методом POST-запроса на адрес скрипта gate.php;

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

Удалённое управление

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

Технология автозалива

Автозалив и подмена данных веб-страниц обеспечиваются путём модификации HTML-кода в соответствии с правилами, полученными из файла конфигурации.

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

Кроме того, после переменной set_url может быть указана опция G или P, уточняющая целевой запрос (GET или POST). Также существует опция L, указывающая, что необходимо сохранить заданный отрезок HTML-кода в лог вместо его модификации, и опция D, задающая периодичность запуска модификации.

После получения настроек автозалива троян сохраняет их в ключе реестра HKEY_LOCAL_MACHINE\Software\Microsoft\option_9.

Заключение

Подытожим ключевые постулаты данной статьи.

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

2. Существуют налаженные технологии обхода всех видов защиты, используемых в системах электронных транзакций.

3. Существуют доступные инструменты для совершения финансовых атак всех видов и масштабов.

4. Фиксируется рост заинтересованности атакующих субъектами российской электронной коммерции, в первую очередь клиентами банков (как физическими лицами, так и организациями) и системами денежных переводов.

5. По состоянию на сегодняшний день 99% потенциальных «жертв» не защищены.

К последнему пункту необходимо привести два пояснения. Во-первых, для заинтересованного атакующего не представляет труда обход антивируса. Таким образом, антивирус в некоторой степени защищает рядовых пользователей онлайн-банкинга, но, по мере увеличения класса платёжеспособности «жертвы», утрачивает свои полезные свойства в связи с пропорциональным возрастанием вероятности целевой атаки.

MitM — man-in-the-middle. Схема атаки, при которой злоумышленник выступает в роли несанкционированного посредника между клиентом и сервером.

MitB — man-in-the-browser, man-in-the-box. Схема атаки, при которой действия злоумышленника совершаются с помощью вредоносной программы на стороне клиента.

Во-вторых, все универсальные платформы ДБО и СКЗИ российского производства принципиально (by design) уязвимы к описанному в данной статье виду атак. Будучи построенными на базе устаревшей парадигмы информационной безопасности, ключевым звеном которой служила защита от сетевых атак (MitM и сетевой взлом), эти системы не предназначены для защиты от локальных атак с использованием вредоносных программ (MitB).

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

В ряде случаев, сопряженных с невысоким риском атаки, могут применяться половинчатые меры «повышения безопасности». В первую очередь это грамотная настройка политик безопасности и систем мониторинга уязвимого компьютера и прокси-сервера организации, разработанные и внедренные с учётом MitB-парадигмы безопасности.

Для банков доступны такие решения, как полный перевод системы удалённых платежей из интернета на мобильную платформу, а также подключение SMS-уведомлений для каждой транзакции (подчеркнём, что SMS-уведомление должно содержать значение суммы перевода и реквизиты получателя, а номер телефона клиента должен храниться на стороне банка). Последнее решение неудобно для пользователей, создаёт высокую нагрузку на системы банка и неприменимо в организациях с большим объемом транзакций.

Разработчики платформ ДБО могут несколько усложнить задачу атакующим путём дополнительной защиты файлов ключей, запутывания HTML-кода страницы онлайн-банкинга и других подобных «заглушек». Однако, по большому счёту, разработчик платформы ДБО не может решить проблему фундаментально, так как перехват данных осуществляется на уровне операционной системы, независимо от реализации конкретного приложения.

Единственным фундаментальным решением для защиты онлайн-банкинга является его полная изоляция, обеспечивающая невозможность проникновения на компьютер вредоносного кода и установки троянских перехватов. Это решение реализуется путём размещения системы банк-клиента на отдельном физическом компьютере или загрузочном диске, защищённом от записи, в совокупности с тонкой настройкой политик безопасности и общей архитектуры решения. Отметим, что решение по программной виртуализации интернет-банка не имеет смысла, так как оно не защищает от схемы атаки №2 (атака изнутри компьютера «жертвы»), а решение с загрузочным диском окажется бесполезным, если размещённая на нём система может быть успешно атакована в промежутке между загрузками.

* * *

Обсуждение статьи

Начнем с определений, которые используются в мире COM. Интерфейс (interface) — это просто группа функций. Эти функции называются методами (methods). Как правило, интерфейсам принято давать названия, начинающиеся с буквы I, например IShellFolder. Интерфейсы могут наследоваться от других интерфейсов. Однако здесь наследование работает так же, как и одиночное наследование в C++, т. е. в COM-стандарте нет понятия множественного наследования. Объект компонентного класса (coclass — component object class) содержится в DLL или в EXE и непосредственно включает код одного или нескольких интерфейсов. Говорят, что coclass реализует (implement) эти интерфейсы. COM-объект (COM-object) — это экземпляр coclass’а в памяти. COM-сервер (COM-server) — это двоичный файл (COM или EXE), который содержит один или несколько coclass’ов. COM-библиотека (COM-library) — это часть ОС, отвечающая за взаимодействие с приложением. GUID (globally unique identifier) — это 128-битное число, которое позволяет однозначно идентифицировать «объекты» в мире COM:

• CLSID, class ID — идентификатор coclass’ов;

• IID, interface ID — идентификатор интерфейсов.

Ну вот, в общем, и закончилось введение в мир COM. Если сейчас вы путаетесь в этих определениях, не стоит бояться, так как, когда мы перейдем к практике, всё сразу встанет на свои места.

Суть атаки COM-Server Based Binary Planting

Все скриншоты, представленные в этой статье, сделаны на виртуальной машине Windows XP SP3 Rus x86 (все фиксы на 2011-12-14).

Многие знают, что в Windows существуют так называемые виртуальные папки (virtual folders). К ним относятся «Панель управления», «Мой компьютер» и др. В реестре Windows каждой такой папке соответствует свой CLSID. Например, «Мой компьютер» имеет CLSID {20D04FE0-3AEA-1069-A2D8-08002B30309D}, «Панель управления» — CLSID {21EC2020-3AEA-1069-A2DD-08002B30309D}. Зная эти CLSID, можно легко открывать соответствующие виртуальные папки через Win + R (Пуск → Выполнить). При этом нужно добавить :: перед CLSID.

(картинка не сохранилась в архиве)

Однако если вы попытаетесь открыть «Панель управления», то ничего не выйдет, поскольку она является подпапкой «Мой компьютер». Таким образом, чтобы открыть «Панель управления», надо указать полный путь к ней: ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}. Но что, если создать папку с именем Test.{20D04FE0-3AEA-1069-A2D8-08002B30309D}? В результате у нас появится папка Test, которая, если смотреть через explorer.exe, будет иметь значок «Мой компьютер» (полный путь к папке: C:\Documents and Settings\Administrator\Desktop\SomeFolder\Test.{20D04FE0-3AEA-1069-A2D8-08002B30309D}\).

(картинка не сохранилась в архиве)

Более того, попытавшись перейти в эту папку, мы окажемся в папке «Мой компьютер». Отметим, что расширение созданной нами папки (то, что отделено от ее имени последней точкой) скрыто от explorer.exe. Давайте определим, какая DLL отвечает за обслуживание «Мой компьютер». Для этого посмотрим значение по умолчанию в реестре по ключу HKLM\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\InProcServer32.

(картинка не сохранилась в архиве)

Таким образом, за обслуживание «Мой компьютер» отвечает библиотека shell32.dll. Следовательно, можно предположить, что при переходе в эту папку загружается shell32.dll (но загрузки не происходит, поскольку эта библиотека и так всегда загружена). Для проверки этого предположения создадим DLL-библиотеку (исходник и бинарник есть в архиве, который прилагается к статье):

Откомпилируем эту библиотеку в FakeSHELL32.dll (cl.exe FakeSHELL32.cpp /MT /D "UNICODE" /D "_UNICODE" /LD), поместим в папку C:\1\ и изменим путь в реестре.

(картинка не сохранилась в архиве)

Теперь при переходе в папку Test.{20D04FE0-3AEA-1069-A2D8-08002B30309D} мы увидим следующее.

(картинка не сохранилась в архиве)

Таким образом, система действительно загружает COM-сервер, которому соответствует CLSID {20D04FE0-3AEA-1069-A2D8-08002B30309D} (почему DLL внедрилась в verclsid.exe, будет объяснено дальше).

Пример проведения атаки

Для примера возьмем общедоступный PoC[^2]. На сайте написано, что если у вас стоит обновление[^3] MS11-071, то проэксплуатировать уязвимость не получится. Поскольку в нашей тестовой системе это обновление установлено, придется вручную создать CLSID и по минимуму его заполнить. Для этого создадим и запустим следующий REG-файл (также есть в архиве, прилагающемся к статье):

После внесения всех необходимых изменений создадим папку Files.{42071714-76d4-11d1-8b24-00a0c9068ff3} (я создал ее на рабочем столе). Переименуем нашу DLL-библиотеку в deskpan.dll и переместим ее в эту папку. Также создадим в ней пустой RTF-документ (следуя советам из «The Anatomy of COM Server-Based Binary Planting Exploits»[^4]). При попытках открыть этот файл… ничего не происходит. Чтобы выяснить, в чем же причина, запустим ProcessMonitor и настроим фильтры. Видно, что, когда мы запускаем RTF-файл, система всё же осуществляет поиск DLL, но в контексте процесса verclsid.exe (C:\Windows\system32\verclsid.exe).

(картинка не сохранилась в архиве)

Переименуем этот файл в verclsid.exe и опять попробуем открыть RTF-документ. Ура! Теперь уязвимость срабатывает так, как и написано в «The Anatomy of COM Server-Based Binary Planting Exploits».

(картинка не сохранилась в архиве)

(картинка не сохранилась в архиве)

Что же происходит в недрах ОС? Почему DLL не запускается при наличии verclsid.exe? Давайте попробуем разобраться.

Условия эффективности атаки

Сначала посмотрим, какие функции вызываются, если в системе нет verclsid.exe. Для этого поместим точку останова в DllMain и запустим это всё под отладчиком. Итак, стек вызовов для моей тестовой машины выглядит следующим образом:

Видно, что после вызова функции SHELL32!SHExtCoCreateInstance всегда происходит загрузка DLL. Таким образом, функцией-триггером является SHELL32!CFSFolder::_Bind:

Как видно из листинга, функция SHELL32!SHExtCoCreateInstance вызывается только при успешном вызове функции SHELL32!CFSFolder___GetBindCLSID, в которую передается результат работы функции SHELL32!ILFindLastID. Она, в свою очередь, получает последний элемент пути к объекту (путь к любому объекту в SHELL задаётся с помощью структуры ITEMIDLIST, более подробно — «The Complete Idiot's Guide to Writing Namespace Extensions — Part I»[^5]), а функция SHELL32!CFSFolder___GetBindCLSID проверяет, является ли этот элемент CLSID’ом. Если это действительно так, то для соответствующего CLSID’а вызывается функция SHELL32!SHExtCoCreateInstance. Рассмотрим листинг этой функции:

Таким образом, функция SHELL32!SHExtCoCreateInstance является «оберткой» вокруг функции SHELL32!SHExtCoCreateInstance2:

В свою очередь, функция SHELL32!SHExtCoCreateInstance2 является «оберткой» вокруг функции SHELL32!_SHCoCreateInstance и при необходимости преобразует строку CLSID в CLSID. В нашем случае это преобразование не выполняется, поскольку первый параметр вызываемой функции SHELL32!SHExtCoCreateInstance2 равен NULL. Ключевой кусок функции SHELL32!_SHCoCreateInstance:

Таким образом, логика работы функции достаточно проста: после преобразования CLSID’а и IID’а в строковые значения она вызывает функцию SHELL32!_ShouldLoadShellExt. В случае, если она возвращает ненулевое значение, вызывается функция SHLWAPI!SHCoCreateInstanceAC, которая, собственно, и загружает необходимую DLL (что и происходит в нашем случае: см. стек вызовов). Взглянем на листинг функции SHELL32!_ShouldLoadShellExt:

Вначале функция проверяет, не является ли данный CLSID запрещенным. Для этого она просматривает ветки реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked и HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked и пытается найти в них имя параметра, которому соответствует CLSID (pszCLSID). При обнаружении такого параметра (его тип не важен) функция возвращает ненулевое значение. Затем она проверяет политику REST_ENFORCESHELLEXTSECURITY, которая, будучи включенной, разрешает запуск только доверенных расширений SHELL, т. е. тех расширений, имена которых являются параметрами ключей реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved и HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved. Поскольку на тестовой машине политика REST_ENFORCESHELLEXTSECURITY не включена и ключи реестра Blocked пусты, происходит вызов функции SHELL32!_QueryClassInterface, которая и возвращает ненулевое значение. Эта функция достаточно большая и выполняет множество проверок, прежде чем вернуть управление. Для простоты разобьем алгоритм функции на пункты и подробно опишем каждый из них. Прототип функции выглядит так:

1. Преобразование переданных значений pszCLSID, pszIID и dwClsContext в строку вида %s %s 0x%X.

2. Поиск параметра типа REG_DWORD с именем, указанным в п. 1, в ветке реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached. При обнаружении такого параметра, равного 0, функция возвращает управление с кодом 0, в противном случае — с кодом 1.

3. Поиск параметра типа REG_BINARY с именем, указанным в п. 1, и размером 16 байт в ветке реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached.

4. Если параметр из п. 3 найден, то функция вначале сравнивает первые четыре байта. Если они равны нулю, то функция переходит к выполнению операций, описанных в п. 5, в противном случае выполнение функции завершается с кодом, равным 1.

5. Функция сравнивает третье и четвертое четырехбайтные слова со временем, полученным с помощью GetSystemTimeAsFileTime (см. рисунок ниже), чтобы проверить, прошло ли 10 секунд с момента последней записи в этот параметр. Если не прошло, то выполнение функции завершается с кодом, равным 0, в противном случае функция переходит к выполнению операций, описанных в п. 6.

6. Формирование строки вида "/S /C %s /I %s /X 0x%X", pszCLSID, pszIID, dwClsContext.

7. Запуск процесса %WINDIR%\system32\verclsid.exe с командной строкой, указанной в п. 6.

8. Если после вызова функции CreateProcessW произошла ошибка ERROR_FILE_NOT_FOUND (2), выполнение функции завершается с кодом 1. Если произошла другая ошибка, функция завершается с этой ошибкой. Если ошибки не было, функция переходит к п. 9.

9. Функция ожидает, когда WaitForSingleObject завершит процесс verclsid.exe, а GetExitCodeProcess определит код его завершения.

10. Формирование данных для параметра реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached с именем, указанным в п. 1. Разбор параметров представлен на рисунке.

(картинка не сохранилась в архиве)

1 — управление кешированием: 0 — кеширование разрешено, 1 — запрещено; 2 — произвольные данные; 3 — младшие четыре байта времени, полученные с помощью функции GetSystemTimeAsFileTime; 4 — старшие четыре байта времени, полученные с помощью функции GetSystemTimeAsFileTime.

11. Если код завершения из п. 9 равен 0, то функция завершается с кодом, равным 1, в противном случае — с кодом, равным 0.

Таким образом, мы видим, что существует достаточно много условий завершения функции SHELL32!_QueryClassInterface с кодом, отличным от 0. Одно из этих условий — завершение процесса verclsid.exe с кодом, равным 0. Проанализируем работу этой программы и выясним, для чего она предназначена.

Исследование verclsid.exe и её обход

Итак, verclsid.exe запускается функцией SHELL32!_QueryClassInterface. Эта программа анализирует CLSID, переданный ей в качестве параметра, и в зависимости от разных условий формирует код завершения. Посмотрим, с какими параметрами запускается verclsid.exe при открытии RTF-файла из нашей папки.

(картинка не сохранилась в архиве)

Итак, у нас есть ключ /S, ключ /C, после которого идет GUID, ключ /I, за которым следует ещё один GUID, и ключ /X, после которого идет шестнадцатеричное число. Дизассемблирование файла verclsid.exe помогло выяснить, за что отвечают эти ключи:

• /S задаёт флаг COINIT_APARTMENTTHREADED для функции OLE32!CoInitializeEx;

• /C задаёт GUID объекта компонентного класса, т. е. наш CLSID;

• /I задаёт интерфейс coclass’а, определенного параметром /C, в данном случае IShellFolder;

• /X задаёт параметр dwClsContext для функции OLE32!CoCreateInstance, который в данном случае равен CLSCTX_INPROC_SERVER | CLSCTX_NO_CODE_DOWNLOAD.

После того как произошел разбор командной строки и приложение определило все свои входные параметры, оно инициализирует COM с помощью функции OLE32!CoInitializeEx и создает вторичный поток WatchDog, который просто засыпает на 15 секунд. Если по истечении этого времени программа не завершается, производится её принудительное завершение с кодом, равным 2:

Затем первичный поток вызывает функцию OLE32!CoCreateInstance:

Если вызов OLE32!CoCreateInstance завершился неудачно, то программа завершается с кодом 3, в противном случае для только что созданного COM-объекта вызывается метод QueryInterface:

Другими словами, у нашего объекта запрашивается интерфейс {9B45E435-34A9-4E6B-A2A1-B0ECD284967C}. Если функция QueryInterface завершается с ошибкой, программа завершается с кодом 3, в противном случае вызывается метод Release:

После этого программа вызывает функцию OLE32!CoUninitialize для деинициализации COM и завершается с кодом, равным 0, что нам и нужно. Для того чтобы написать примитивный COM-сервер, воспользуемся документом «Description of COM principle»[^6], в котором достаточно подробно описан механизм работы функции OLE32!CoCreateInstance. Исходники COM-сервера вы сможете найти в архиве, который прилагается к статье. Они достаточно тривиальны, однако есть одна хитрость. Поскольку мы всегда возвращаем значение S_OK для любого запрашиваемого интерфейса, это может привести к краху некоторых приложений. Поэтому DllMain проверяет, какое приложение вызвало эту функцию:

После этого поместим DLL в папку C:\Documents and Settings\Administrator, опять откроем наш RTF-файл и посмотрим на отладочную консоль:

Как видно, теперь атака проходит успешно. Заметим, что для этого DLL должна находиться в Current Directory процесса explorer.exe.

Заключение

Резюмируя, можно сказать, что атака DLL Hijacking применима и к COM-технологии. Однако для успешной эксплуатации уязвимости злоумышленнику необходимо преодолеть ряд ограничений (обход verclsid.exe, наличие/отсутствие ключей в разных ветках реестра). Возможным направлением дальнейших исследований является поиск COM-серверов с запретом на кеширование, уязвимых к атаке DLL Hijacking.

Литература

1. COM Server-Based Binary Planting Proof Of Concept.

2. Silently Pwning Protected-Mode IE9 and Innocent Windows Applications.

3. Introduction to COM — What It Is and How to Use It.

4. Introduction to COM Part II — Behind the Scenes of a COM Server.

5. An almost complete Namespace Extension Sample.

Приложение

code-com-hijacking.7z (файл не сохранился в интернете)

Последнее обновление: 05.04.2012.

[^1]: Binary Planting — The Official Web Site.

[^2]: XP_2-click.zip (файл не сохранился в интернете).

[^3]: Обновление MS11-071.

[^4]: The Anatomy of COM Server-Based Binary Planting Exploits.

[^5]: The Complete Idiot's Guide to Writing Namespace Extensions — Part I.

[^6]: Description of COM principle.

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

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

Стандартные способы получения информации о системе

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

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

1. Восстановление предположительно модифицированных участков кода ядра (global unhooking) перед сбором информации о системе.

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

Восстановление ядра

Восстановление участков кода ядра — это способ нейтрализовать эффекты руткита глобально, для системы в целом. Обычно в рамках этого подхода восстанавливают таблицу SDT, некоторое количество кода в начале системных функций, IRP-обработчики — и, в общем, все системные структуры, подозреваемые в модификации (см. рис. 1).

Рис. 1. Rootkit-модификация ядра

В процессе разработки алгоритмов восстановления структур ядра разработчик сталкивается с несколькими сложностями.

1. Поиск или вычисление «чистых» указателей на системные вызовы, IRP-обработчики и т. д., используемые впоследствии для восстановления цепочек системных вызовов. Также — поиск оригинальных системных файлов, из которых можно восстановить модифицированные участки ядра.

2. Различение безвредных модификаций и перехватов, установленных легитимным программным обеспечением (например, фаерволом или антивирусом).

3. Обеспечение безопасности алгоритма. Поскольку ядро системы непрерывно используется, запись в исполняемые регионы памяти ядра в определенных обстоятельствах может привести к BSOD.

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

Вместе с тем, техника глобального восстановления структур ядра обладает рядом существенных недостатков.

1. Небезопасность. Модификация структур в работающем ядре — рискованная операция при любых условиях.

2. Ненадежность. Руткит может в любой момент восстановить свои перехваты.

3. Бессистемность. Должны быть указаны конкретные структуры и участки кода, подлежащие восстановлению, что позволяет руткиту скрыться в непредусмотренной локации.

4. Трудоемкость. Получение оригинальных указателей на системные функции и различение вредоносных модификаций и перехватов от безопасных.

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

Углубление в систему

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

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

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

2. Стратегическая неэффективность. Углубление в систему стимулирует «гонку вооружений», поскольку достаточно очевидно обходится ответным углублением противника.

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

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

Альтернативное решение

Из всех недоверенных источников информации, собственные источники являются наименее недоверенными. Антируткит может выполнять системные вызовы самостоятельно, если он оснащен собственной, заведомо чистой копией ядра. Это «дешевый» способ получить чистую информацию в обход искажающих модификаций, не рискуя стабильностью системы.

Использование собственного ядра, правильно полученного и настроенного, позволяет надежно детектировать большинство современных руткитов ядра. В частности, облегченная реализация данной техники (описанная ниже в этой статье) позволяет обнаруживать объекты, скрытые посредством модификации таблицы SDT и кода ядра. Более сложная реализация позволит детектировать практически любой руткит ядра.

Детали техники

Создание работающей копии ядра относительно просто и может быть реализовано посредством следующего алгоритма (см. рис. 2).

1. Поиск необходимых исполняемых файлов.

Для минимальной реализации работающей копии ядра достаточно двух файлов: основной файл ядра (в большинстве случаев — ntoskrnl.exe) и hal.dll. Поскольку пути к этим файлам могут быть подменены руткитом, их рекомендуется вычислять посредством анализа аппаратной конфигурации, описанного ниже.

2. Загрузка файлов в память.

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

3. Релокация указателей и инициализация переменных.

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

4. Временная блокировка механизма системных нотификаторов.

Легитимные callback-механизмы не должны вмешиваться в работу антируткита. Отключить их можно патчингом функции ExReferenceCallBackBlock так, чтобы она во время работы антируткита безусловно возвращала нулевое значение.

5. Перенаправление собственных вызовов ядра на локальную копию.

Рис. 2. Цепочка вызовов дубликата ядра

Поскольку мы должны предполагать, что очевидные источники информации о пути к файлу ядра (такие как файл boot.ini или ключ реестра HKLM\System\CurrentControlSet\Control\SystemStartOptions “KERNEL”) могут быть подставными, рекомендуется использовать вычислительный алгоритм получения имени файла ядра. Последнее определяется двумя системными параметрами: количеством процессоров и поддержкой PAE (Physical Address Extension).

Недостатки

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

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

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

Обход

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

1. Руткит может подставить антируткиту модифицированный файл ntoskrnl.exe при его чтении с диска.

Решение: проверка подписи Microsoft.

2. Руткит может подставить ложный путь к файлу ядра.

Решение: получение имени файла посредством анализа аппаратной конфигурации.

3. Руткит может заблокировать чтение файлов ядра.

Маловероятно, так как это может нарушить функционирование легитимных приложений.

Преимущества

1. Безопасность. Грамотные манипуляции с собственной копией ядра абсолютно безопасны, в отличие от манипуляций с работающим кодом ядра.

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

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

Заключение

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

В качестве проверки практической ценности предложенной техники, мы разработали утилиту на ее основе: Trojan.Win32.TDSS remover [1]. Утилита «заточена» под детектирование и лечение руткита TDSS [2], хотя по своим возможностям представляет собой достаточно универсальный антируткит.

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

Ссылки

1. Esage Lab, Trojan.Win32.TDSS remover.

2. Алиса Шевченко, Анализ руткита TDSS.

Последнее обновление: 17.03.2012.

В контексте этой тенденции актуально вновь поднять тему файловых инфекторов. Одна из задач данной статьи — представить обзор известных на сегодняшний день техник заражения исполняемых файлов. Во второй части статьи рассматривается «шаг за шагом» процесс анализа и разработки процедуры лечения для относительно старого, но не потерявшего своей актуальности файлового инфектора Win32.Parite.C.

Обзор вирусных технологий

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

Добавление новой секции

Это самый распространённый метод заражения файлов, не утрачивающий своей популярности вопреки его успешному обнаружению всеми антивирусами. Суть данного метода заключается в добавлении секции в конец исполняемого файла. Далее вирус пересчитывает размер образа всего файла (SizeOfImage), выставляет на секцию нужные флаги, включая флаг исполнения (0x20000000), и меняет точку входа (EntryPoint) на начало новой секции.

При запуске заражённого файла сначала выполнится код из вирусной секции, а затем произойдет переход на оригинальную точку входа (Original Entry Point, OEP). Обычно такой переход осуществляется с помощью следующих инструкций процессора:

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

Расширение последней секции

Это также один из наиболее популярных методов заражения исполняемых файлов. Вирус получает указатель на последнюю секцию исполняемого файла и увеличивает её атрибуты физического размера (SizeOfRawData) и виртуального размера (VirtualSize), тем самым расширяя секцию. Затем вирус пересчитывает размер образа (SizeOfImage) и выставляет на последнюю секцию нужные флаги, включая флаг исполнения (0x20000000), вычисляет новую точку входа и заменяет оригинальную.

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

Однако встречаются и более сложные случаи: например, вирус может добавлять «мусорные» инструкции в начало кода заражения и направлять точку входа в середину массива данных, состоящих из большого количества взаимосвязанных безусловных переходов. Это затрудняет поиск границы между реальными данными последней секции и внедрённым кодом. В таком случае следует учитывать, что для лечения заражения достаточно восстановления оригинальной точки входа, в то время как физическое удаление вирусного кода является в большей степени эстетической мерой.

Заражение методом EPO (Entry Point Obscuring)

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

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

Для лечения вирусов этого типа не существует универсального подхода. В общем случае необходимо найти адрес перехода оригинальной инструкции call или jmp и восстановить изменённую инструкцию с последующим удалением вредоносного кода из тела исполняемого файла.

Учитывая, что большинство EPO-вирусов добавляют новую секцию или расширяют последнюю секцию, такие вирусы могут быть выявлены путем поиска в коде программы инструкций типа call или jmp, которые передают управление коду, находящемуся в последней секции.

Оверлейное заражение

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

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

Лечение заражённого файла в данном случае сводится к удалению оверлея и его загрузчика. Для удаления оверлея — если достоверно известно, что в нём хранится только вирус — достаточно получить его смещение в файле, сложив значения атрибутов PointerToRawData и SizeOfRawData последней секции, и обрезать файл до полученного размера.

Модификация секций

Манипулирование секциями исполняемого файла является более искусным методом заражения. Автору встречались на практике только две разновидности данного метода: с заменой секции таблицы переадресаций (relocation table, в заголовке модуля обычно именуемой .reloc) и со сдвигом секции ресурсов (обычно — .rsrc).

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

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

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

Заражение динамической библиотекой

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

Динамическая библиотека, содержащая в себе вирусную функцию, размещается в директории %SYSTEMROOT%\system32. Вирус заражает файл путем добавления в его таблицу импорта имени библиотеки и имени (реже — порядкового номера) экспортируемой функции, после чего меняет адрес ImportTable на новый, внедряет в тело исполняемого файла вызов вирусной функции и направляет точку входа на этот вызов. После того как вирусная функция отработана, вирус передает управление на OEP.

Лечение подобного заражения заключается в восстановлении точки входа и пересборке таблицы импорта.

Метод «украденных байт»

Метод «украденных байт» — техника передачи управления вирусному коду, как и в случае с методом EPO.

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

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

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

В качестве примера такого вируса, простого только на первый взгляд, рассмотрим полиморфный вирус Win32.Parite.C.

Анализ Win32.Parite.C

Offensive Computing. Win32.Parite.B Unpacking and Anatomy Reversing and Network Analysis

Вирус Win32.Parite.C известен тем, что хранит основной вредоносный код в отдельной DLL размером около 180 кБ и реализует нестандартный метод защиты зараженных файлов. Глобальной эпидемии этого вируса не было зафиксировано, однако в 2003 году его образцы занимали почетные места в Top 20 вирусных угроз. В последнее время информация о данном семействе вирусов начинает появляться снова.

Образец этого вируса можно загрузить с сайта vx.netlux.org. Для анализа будем использовать связку IDA Pro 5.5, HexRays 1.1 и IDAPython 2.5, а также Shadow OllyDbg и LordPE.

Как и многие другие файловые вирусы, Win32.Parite.C начинает поиск жертвы для заражения по маске *.exe в трех самых популярных местоположениях:

1. в текущей директории;

2. на первом разделе жесткого диска;

3. в системных директориях — %systemroot% и %systemroot%\system32.

Iczelion. Win32 Assembly Tutorials

Запустим образец вируса на виртуальной машине с установленной ОС Windows XP Pro SP3 и позволим ему заразить несколько файлов. Файлы для заражения рекомендуется выбирать простые, с хорошо известной структурой — таким образом, ее изменения в результате заражения файла будет проще обнаружить. Автор статьи использует для заражения файлы из уроков Iczelion. При написании данной статьи был использован исполняемый файл из урока 13.

После того как вирус заразит исходный файл, внесенные им изменения можно просмотреть с помощью утилиты LordPE. Для этого следует открыть в LordPE оригинальный, незаражённый файл, нажав на кнопку «PE Editor», затем нажать кнопку «Compare» и открыть уже заражённый файл. Таким образом можно оценить, какие действия были совершены вирусом, без анализа процедуры заражения.

Сравнение зараженного и чистого файлов

В данном случае наблюдаются следующие изменения в структуре файла:

• существенное увеличение размера заражённого файла;

• увеличение числа секций (NumberOfSections) на единицу;

• изменение размера образа (SizeOfImage);

• изменение точки входа (теперь она указывает на последнюю секцию);

• установка флага исполнения для секции .rdata;

• появление оверлея (заметим, что размер файла увеличился в несколько десятков раз, а физический размер последней секции очень мал).

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

Запустив заражённый файл в OllyDbg, мы получим предупреждение о том, что файл может быть упакован, так как точка входа не указывает в секцию кода. Попав на точку входа, видим слегка искажённый код, похожий на код расшифровки.

Код искаженного расшифровщика

При пошаговом исполнении (F8) становится ясно, что перед нами действительно код расшифровщика. Таким же способом дойдем до того момента, когда циклический переход по адресу 0x00405025 не будет осуществлен, либо поставим аппаратную точку останова на адрес 0x00405027, продолжим выполнение файла (F9) и дождемся остановки.

Остановка на точке останова после цикла расшифровки

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

Переход на OEP

Итак, видно, что после исполнения инструкции retn по адресу 0x0040524A произойдет переход на OEP, так как в стек записана оригинальная точка входа. Похоже на стандартную комбинацию push addr; retn, за тем исключением, что отсутствует инструкция push. Однако, если присмотреться, то по адресу 0x00405242 можно увидеть запись данных из регистра EDX в стек (о чем свидетельствует значение регистра ECX, равное 0x0012FFC0). Еще выше по коду видно, что в EDX данные попадают из памяти по адресу EDI+0Ch и суммируются с данными из памяти по адресу EDI+08h. По-видимому, таким образом происходит вычисление ImageBase и оригинальной точки входа.

Продолжим выполнение до адреса 0x00405237, перезапустив программу (Ctrl-F2).

*Остановка на записи в EDX оригинальной точки входа*

Так и есть: OEP вычисляется из значения ImageBase, которое хранится по адресу памяти EDI+08h, и значения EntryPoint, которое хранится по адресу EDI+0Ch. Таким образом, адрес точки входа хранится в памяти непосредственно после значения ImageBase.

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

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

Остановка при обращении по адресу хранения точки входа

Карта памяти с отображением загруженного лишнего модуля

Остановка произошла в неком модуле pvf1 по адресу 0x008F231E. Если продолжить выполнение до выхода из текущей функции (Ctrl-F9), то после завершения и остановки на инструкции retn по адресу, где предположительно должна появиться точка входа, появляется значение, очень похожее на EntryPoint. Значит, в модуле pvf1 в функции по адресу, где сработала точка останова, и происходит расшифровка.

Для дальнейшего анализа удобнее использовать дизассемблер IDA. Сохранить модуль для анализа можно следующими способами:

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

• выполнить код до вызова функции CloseHandle, которая освободит дескриптор файла, и скопировать его для анализа;

• сохранить область памяти по адресу 0x008F0000 с помощью LordPE.

Вручную загрузим модуль в IDA (manual load), указав в качестве ImageBase значение 0x008F0000. Перейдя (G) на адрес 0x008F231E и вызвав дополнение Hex-Rays (F5), получим псевдокод на C. Это и есть процедура декодирования точки входа. Трассировка кода процедуры в отладчике показывает, что декодирование происходит в цикле, отображенном на рисунке ниже:

Дизассемблерный листинг цикла декодирования OEP

В ходе исследования цикла в отладчике можно установить, что точка входа расшифровывается методом XOR. Декодирование происходит с использованием четырех различных ключей длиной по 4 байта. Значения ключей генерируются из двух разных массивов длиной по 8 байт каждый, находящихся по смещениям +28h относительно адреса, где должна храниться ImageBase (первый массив из 8 байт), и +0Сh относительно начала первой таблицы (второй массив из 8 байт).

Адреса и данные таблиц для расшифровки

Подготовка ключей происходит чуть выше процедуры декодирования, в цикле по адресу 0x008F22EE.

Дизассемблерный листинг цикла подготовки ключа

Псевдокод цикла подготовки ключа

Псевдокод функции подготовки ключа

Помимо вышеописанного, вирус заменяет два первых значения ThunkValue из таблицы импорта для kernel32.dll значениями, указывающими на LoadLibraryA и GetProcAddress.

*Адреса памяти, где хранятся оригинальные ThunkValue*

Значение оригинальных ThunkValue вирус прячет по смещениям +1Ch и +20h относительно адреса значения ImageBase.

*Подменённые значения для kernel32.dll*

Теперь, когда алгоритм разобран, можно приступить к лечению.

Лечение Win32.Parite.C

Опишем вкратце схему лечения файлов, зараженных вирусом Win32.Parite.C.

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

2. Когда сработает точка останова, найдем значение 75h, соответствующее коду инструкции jnz short, и выставим по найденному адресу вторую точку останова.

3. При каждом срабатывании второй точки останова будем проверять флаг ZF. Если он установлен, то код расшифрован, и можно приступить к поиску необходимых данных.

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

5. Далее, зная адрес значения ImageBase, можно вычислить адреса всех необходимых данных: зашифрованной точки входа, двух таблиц, из которых собирается ключ, и двух значений ThunkValue, «украденных» из таблицы импорта.

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

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

Протокол работы утилиты лечения

Список литературы

1. Offensive Computing. Win32.Parite.B Unpacking and Anatomy Reversing and Network Analysis.

2. Iczelion. Win32 Assembly Tutorials.

Последнее обновление: 17.03.2012.

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

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

1. Массивный вектор атаки.

Уязвимости в технологиях обработки популярных форматов данных, интегрируемых с веб-технологиями, в массе своей кроссплатформенны, кроссбраузерны и кроссформатны.

Кроссплатформенность естественным образом следует из стремления производителей-монополистов (каким, к примеру, является Adobe по отношению к формату PDF) захватить максимум рынка. Приложение компилируется для разных операционных систем, но основано на одном и том же коде с одними и теми же ошибками. В качестве примера можно привести уязвимость CVE-2009-1862, вредоносный документ на основе которой будет рассмотрен в примере 3: ей подвержены четыре операционные системы.

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

Кроссформатность обеспечивается взаимной интеграцией технологий: Flash-ролик может быть встроен в документ PDF, код JavaScript может содержаться внутри PDF и Flash, и все три — Flash, PDF и JavaScript — могут вызываться из кода веб-страницы. Таким образом, одна и та же уязвимость может эксплуатироваться при помощи файлов разных типов.

2. По мере того как интернет становится всё более полноценной рабочей средой, углубляется интеграция классических веб-технологий с медиа-контентом и офисными файлами. По этой же причине производители браузеров стремятся сделать работу с различными файлами более прозрачной (например, отображать PDF в окне веб-страницы вместо сохранения его на диск), что способствует автоматизации массовых заражений.

3. Значительный объём кода и динамичность развития библиотек для обработки форматов данных располагает к поиску и обнаружению все новых уязвимостей. К примеру, как показывает историческая ретроспектива по любой базе уязвимостей, тема уязвимостей в Adobe Flash неисчерпаема.

4. Успеху атак с использованием вредоносных офисных документов (таких как PDF и PPT) пока ещё способствует социальный фактор: пользователю психологически проще открыть незнакомый офисный документ, чем запустить Flash-ролик или исполняемый файл, необходимость осторожного обращения с которыми достаточно широко освещена.

5. Большинство браузеров настроены таким образом, чтобы автоматически запускать Flash-ролик и открывать PDF-документ. Таким образом, эксплуатация уязвимости и исполнение вредоносного кода происходит немедленно после перехода по вредоносной ссылке и загрузки соответствующего содержимого, без участия пользователя.

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

Анализ вредоносных файлов Пример 1. PDF + JavaScript

Рассмотрим вредоносный документ PDF (MD5: c251dcf3190701c46ee6a3f562df32e6), который наиболее распространён в настоящее время. Этот файл был впервые обнаружен в декабре 2009 г., сразу же попал в топ-20 вредоносных программ в Интернете [3] (Pdfka.asd — 12-е место), и поднялся на две позиции топа в январе [4] (Pidief.cvl — 10-е место), по-прежнему оставаясь единственным PDF-эксплойтом в пределах значимой статистики. Экземпляры вредоносных файлов для этого и последующих примеров, а также файлы, полученные в процессе их анализа и обработки, доступны в приложенном к статье архиве.

Это файл размером около 10 Кб. Открыв его в текстовом редакторе, можно увидеть в самом начале файла типичную для PDF-документа сигнатуру: %PDF.

Структура PDF

Структура PDF-файла проста и читается невооружённым глазом. Начальные сведения, достаточные для изучения простых PDF-эксплойтов, можно почерпнуть в статье Д. Стивенса «Анатомия вредоносных PDF-документов» (на английском) [5]. Полностью формат PDF описан в стандарте ISO 32000-1 и в соответствующем ему справочном документе, доступном для загрузки на сайте Adobe [6].

Итак, рассмотрим структуру данного вредоносного файла.

Дамп структуры PDF, оптимизированный для анализа, можно получить при помощи утилиты pdf-parser. В данном случае пользоваться ею нет необходимости, поскольку файл небольшой, и вся структура PDF в нём видна как на ладони. Мы видим стандартный набор объектов: каталог (1), содержание (2), список страниц (3), описатель отдельной страницы (4), каталог комментариев (5), встроенный JavaScript (6) и два объекта типа stream (7 и 8). В stream-объектах внутри PDF хранятся различные вложенные данные, такие как картинки, скрипты и шрифты. Чаще всего эти данные упакованы при помощи алгоритма deflate (/FlateDecode).

При анализе потенциально вредоносных PDF-файлов необходимо в первую очередь обращать внимание на активное содержимое документа. В данном случае привлекает внимание встроенный скрипт JavaScript (6), данные которого хранятся в упакованном объекте (7). Упакованный скрипт занимает всего 160 байт и практически не заметен при просмотре структуры PDF-файла.

От PDF к скрипту

Распакуем упакованный объект при помощи утилиты pdf-parser:

В результате получается совсем маленький скрипт, который получает данные комментариев (или аннотаций, функция getAnnots) и после некоторой их обработки исполняет их как скрипт (функция eval).

Почему именно getAnnots? В первых же результатах поиска Google по этому названию функции всплывает уязвимость CVE-2009-1492, связанная с ошибкой обработки комментариев в Adobe Acrobat. Но, как видно из соответствующего эксплойта [7], эта уязвимость не имеет никакого отношения к данному случаю. Поле комментариев просто используется в качестве хранилища для массивной части скрипта, чтобы PDF-документ не вызывал подозрений с первого взгляда.

Данные комментариев, получаемые функцией getAnnots, хранятся в сжатом виде в stream-объекте (8), на который ссылается объект Annot (5).

Распаковав его аналогично предыдущему, получаем длинную строку вида z0dz0az0dz0az09:. Для преобразования этой строки в читаемый скрипт над ней необходимо произвести соответствующие манипуляции:

Как видно из кода, в полученной из хранилища аннотаций строке все символы z заменяются на % — разделительный символ между байтами в шестнадцатеричном представлении, последовательность которых функция unescape преобразует в бинарный вид (в данном случае — в последовательность символов ASCII). Для декодирования unescape пригодятся онлайн-скрипт Decode Unescape или любая программа для преобразования HEX-ASCII.

После декодирования строки получаем достаточно большой и намеренно запутанный (обфусцированный) скрипт (см. файл 7-script2 в приложении).

Запутанный JavaScript

Как анализировать намеренно запутанные скрипты? Во-первых, то, что заставляет скрипт выглядеть устрашающе, — это просто псевдослучайные (вида v_8yD7D8CG__C) имена функций и переменных. Для повышения читаемости скрипта эти идентификаторы достаточно заменить на что-то более осмысленное.

Во-вторых, нужно вычленить функциональную часть скрипта: функцию или последовательность функций, которые совершают основную работу. В данном случае, просмотрев скрипт по именам функций и управляющим директивам JavaScript (которые, в отличие от идентификаторов переменных, не поддаются запутыванию), находим ядро: функцию eval. Она вызывает следующую зашифрованную часть скрипта.

Анализировать процедуру дешифрования не требуется — вместо этого можно заставить скрипт расшифровать самого себя. Для этого скрипт исполняется в соответствующей среде (например, в браузере с поддержкой JavaScript), причем функция eval внутри него должна быть заменена функцией document.write, что приведёт к печати расшифрованного скрипта в окно браузера вместо его исполнения.

В данном случае описанный приём не сработает из-за защиты от отладки (см. файл 8-script2-fail!.html). Во-первых, скрипт использует собственный код (arguments.callee [8]) в алгоритме дешифрования — таким образом, при замене eval на document.write алгоритм отрабатывает некорректно.

Во-вторых, осуществляется проверка переменной app, которая инициализирована в JavaScript-среде приложения (в данном случае — Adobe Acrobat), и не инициализирована в среде браузера или иного интерпретатора JavaScript.

Подытожим алгоритм авторасшифровки скрипта вопреки всем этим нюансам.

1. Вместо переменной arguments.callee должен быть подставлен оригинальный код скрипта, завёрнутый в функцию unescape.

2. Проверку переменной app нужно обойти любым удобным способом (например, добавив в скрипт команду var app = true).

3. Все вхождения функции eval() должны быть заменены на document.write().

4. Из аргумента к функции document.write() должны быть отфильтрованы угловые скобки, которые в противном случае будут поглощены HTML-интерпретатором браузера вместе с частью вывода.

От скрипта к бинарному коду

В результате исполнения модифицированного таким образом скрипта (см. файл 9-script2-ok.html) в браузере получаем очередную порцию кода (см. файл a-script3). Она запутана аналогично предыдущей и является последней, центральной частью скрипта, так как не содержит в себе вызовов функции eval.

Быстрый просмотр скрипта выявляет его функциональное ядро:

1. Неоднократный вызов функции unescape с длинными аргументами вида: "%u9090%u9090%u9090%u21eb%ub859:..".

В строках-аргументах к функции unescape усматривается shell-код, так как закодированы преимущественно байты, выходящие за пределы диапазона печатных символов [21h..7Eh]. К тому же первая строка начинается с нескольких байт 90h, который соответствует команде процессора NOP.

2. this.collabStore = Collab.collectEmailInfo({subj: "", msg: D_3_0824mk});

Вызов этой нестандартной для JavaScript функции сразу же привлекает внимание, а поиск в Интернете по соответствующим ключевым словам наводит на описание уязвимости CVE-2009-5659 [9] (равно как и на рекламу коммерческих связок эксплойтов).

Исследование shell-кода и самой уязвимости выходят за рамки этой статьи. Отметим лишь, что в бинарном коде полезной нагрузки (d-shellcode.exe-payload) просматривается невооружённым взглядом ссылка на вредоносный модуль, который будет загружен и выполнен в результате эксплуатации уязвимости.

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

Пример 2. SWF

В отличие от документов в формате PDF, структура которых легко читается невооружённым взглядом, ролики Adobe Flash более сложны для анализа. Поэтому для начала рассмотрим тривиальный экземпляр вредоносного объекта типа Flash: Trojan-Downloader.SWF.Small.fj (MD5: f8e4e4206586f566c5dddc74884e57df).

Это файл размером 232 байта. В начале файла — сигнатура CWS, соответствующая формату Flash с компрессией [10]. Для его распаковки можно воспользоваться, к примеру, утилитой cws2fws. Сигнатура формата Flash без компрессии, готового к анализу, — FWS.

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

С точки зрения потенциально вредоносного содержимого Flash-объекта, наибольший интерес представляет именно программа на языке ActionScript. Для декомпиляции ActionScript можно воспользоваться утилитой SWFScan, для получения дампа мнемоник байт-кода — утилитой swfdump из пакета SWFTools.

Декомпилированный ActionScript данного файла выглядит так:

Как видно из скрипта, Flash-объект передаёт в командную строку браузера небольшой скрипт (this.getURL). Расшифровав скрипт, получаем строку:

Таким образом, данный Flash-ролик производит перенаправление браузера на другой домен с передачей последнему аргументов к текущему веб-адресу (то есть части строки URL после вопросительного знака). Это элемент сценария массового заражения веб-пользователей с использованием технологии «отравления» поисковых систем (SEO Poisoning) [11].

Пример 3. PDF + SWF

Теперь, понимая принципы анализа как PDF-, так и SWF-файлов, рассмотрим более сложный случай: Exploit.SWF.Agent.br (MD5: 09a0f7aae0e22b5d80c7950890f3f738). Это относительно старый эксплойт, обнаруженный ещё в июле 2009 г., но изрядно нашумевший из-за интересных особенностей строения вредоносного файла [12].

Это документ PDF размером около мегабайта. Быстрый просмотр структуры файла выявляет большое количество PDF-объектов вперемешку с массивными блоками бинарных данных, поэтому для анализа структуры файла целесообразно воспользоваться утилитой pdf-parser.

Структура PDF

При анализе структуры файла (pdf-parser.py 0-sample > 1-pdfparse) ничто не бросается в глаза. Скрипты отсутствуют, зато есть несколько объектов типов ObjStm и XObject, неясного назначения.

Проанализируем PDF более внимательно, включив в дамп структуры файла вывод распакованных бинарных данных (pdf-parser.py -f 0-sample > 2-streamfilter). Задача при этом — проверить, не скрывается ли что-нибудь подозрительное в массивах сжатых данных.

Быстрый визуальный просмотр наиболее крупных блоков распакованных данных выявляет несколько картинок (/Subtype /Image — объекты 29, 31, 5), блок метаданных (/Type /Metadata — объект 6) и два подозрительных блока вложенной разметки PDF (объекты 33 и 7). При более внимательном изучении одного из этих блоков (33) обнаруживаются ссылки на два вложенных SWF-файла:

Возможность встраивать Flash-объекты в PDF-документы появилась в Adobe Reader начиная с версии 9 и описана в приложении к ISO 32000 [13].

Во втором PDF-объекте (7) обнаруживается ссылка на вложенное изображение:

Сохраним соответствующие объекты (2, 3 и 4) для последующего анализа (pdf-parser.py -o 2 -d 0-sample > 3-fancyball.swf и т. п.).

Анализ вложенных Flash-объектов

В результате декомпиляции программы fancyball.swf получается невинный скрипт, скопированный из примеров к Flash Professional 9 ActionScript 3.0 Preview [14] (файл 3.1-actionscript-decompile):

Однако дамп байт-кода того же скрипта (swfdump -D 3.0-fancyball.swf > 3.2-actionscript-dump) показывает, что функция инициализации скрипта переписана небольшим кодом неясного назначения:

Всё, что делает приведенный код, — перемножает два числа на стеке (причем в результате умножения получается адрес в пределах кучи), после чего обращается к неуказанному объекту (см. справочник инструкций для виртуальной машины ActionScript [15]). В результате интерпретации этих инструкций управление передается в область кучи (CVE-2009-1862).

А что находится в куче?

Рассмотрим декомпилированный скрипт второго Flash-объекта — oneoff.swf (файл 4.1-actionscript-decompile).

1. Присвоение двух локальных переменных.

Как видно из дампа байт-кода, это два числа: 0x0c0c0c0c и 0x13131313.

2. Создание последовательности из байта 0x13 длиной 1 Мб (1048576 = 1024²).

3. Динамическое создание массива в куче.

4. Заполнение этого массива ранее сгенерированной последовательностью 64 раза.

5. Динамическая генерация shell-кода в конце того же массива.

Таким образом, в результате выполнения программы этого Flash-объекта динамическая память соответствующего процесса будет заполнена массивом из 64 мегабайт нейтральных инструкций (байт-коду 0x13 соответствует инструкция adc edx,[ebx]), в самом конце которого расположен shell-код. Это heap spray — техника, обеспечивающая надёжное исполнение shell-кода без его привязки к конкретному адресу в памяти процесса, на который должно перейти исполнение в результате эксплуатации уязвимости.

Shell-код, детали которого мы рассматривать не будем, расшифровывает и запускает вредоносные модули, содержащиеся в файле картинки love_wallpaper_butterfly-dsc08951.jpg. Эти модули можно расшифровать и выделить из файла вручную, обратив внимание на длинные последовательности из одного байта (0xA0, 0x37) в коде файла и предположив, что они соответствуют результату потокового XOR-шифрования последовательности нулей, характерной для заголовка исполняемого модуля (см. файлы 7-malware1.ex, 9.0-malware2).

Кроме исполняемых модулей, в той же «картинке» обнаруживается ещё один вложенный PDF-файл (8.0-emdedded.pdf).

Выводы

Подытоживая анализ примеров, ещё раз подчеркнём несколько важных моментов.

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

2. Уязвимость, упомянутая в последнем примере (CVE-2009-1862), помимо этого, еще и кроссформатная: объекты Adobe Flash могут исполняться в качестве самостоятельных модулей, могут быть встроены в веб-страницу или в PDF-документ.

3. Таким образом, пространство для атаки при помощи эксплойта из последнего примера обширно: атака может осуществляться по нескольким векторам (Flash на веб-странице, PDF-документ) на четырёх операционных системах (Windows, Macintosh, Linux и Solaris [16]). Это в большей или меньшей степени касается любых Flash-уязвимостей.

4. От примерной даты обнаружения уязвимости (1 июня 2009 г. — дата принятия уязвимости по базе CVE) до момента выпуска патча компанией Adobe (30 июля 2009 г. — дата соответствующего бюллетеня [17]) прошло два месяца.

Приложение к статье: nb2-flash-attachment.rar (файл есть в nobunkum_ru_files.zip). Пароль к архиву высылается по запросу.

Список ссылок

1. Лаборатория Касперского. Kaspersky Security Bulletin 2009. Основная статистика за 2009 год.

2. ScanSafe. Annual Global Threat Report 2009.

3. Лаборатория Касперского. Рейтинг вредоносных программ, декабрь 2009.

4. Лаборатория Касперского. Рейтинг вредоносных программ, январь 2010.

5. D. Stevens. pdf_article.pdf (файл не сохранился в интернете).

6. Adobe. PDF32000_2008.pdf (файл не сохранился в интернете).

7. Milw0rm. Эксплойт для CVE-2009-1492.

8. Bojan Zdrnja. Browser does matter, not only for vulnerabilities — a story on JavaScript deobfuscation.

9. SecurityFocus. Эксплойт для CVE-5659.

10. Adobe. swf_file_format_spec_v10.pdf (файл не сохранился в интернете).

11. Tiger Woods SEO poisoning attack.

12. Лаборатория Касперского. SWF или PDF? Все одно — Adobe!.

13. Adobe. adobe_supplement_iso32000.pdf (файл не сохранился в интернете).

14. Jen deHaan. Exploring the Flash Professional 9 ActionScript 3.0 Preview.

15. Adobe. avm2overview.pdf (файл не сохранился в интернете).

16. Adobe. Security advisory for Adobe Reader, Acrobat and Flash Player.

17. Adobe. Security updates available for Adobe Flash Player, Adobe Reader and Acrobat.

Последнее обновление: 17.03.2012.

IDN (internationalized domain names) — это доменные имена, которые могут содержать другие алфавитные символы, помимо базовой латиницы [1]. Возможность регистрировать домены с такими именами важна прежде всего для носителей языков, чьи системы письменности не основаны на латинице, например русского или китайского. Но и дополнения к базовой латинице употребляются во многих европейских языках: например, в 2004 году норвежская сеть магазинов Elkjøp зарегистрировала домен elkjøp.no. Первым доменом верхнего уровня, где стала возможна регистрация IDN, стал .jp, разрешивший в 2003 году использовать в доменных именах символы японской письменности.

Протокол DNS [2], регламентирующий запросы к серверам доменных имён и ответы на них, — пожалуй, наиболее широко распространённый в Интернете. Поскольку существующая инфраструктура доменных имён рассчитана на работу только с набором символов ASCII, добавить ко всем серверам поддержку Unicode не представляется возможным. Поэтому пришлось разработать такую технологию, которая кодирует имена, пользуясь только символами ASCII. Например, домен elkjøp.no «на самом деле» зарегистрирован как xn--elkjp-yua.no. Такая запись доменного имени называется Punycode [3]. ASCII-запись интернационализированных доменных имён начинается префиксом xn--, чтобы показать, что в имени используется Punycode (обычно два дефиса подряд в доменном имени запрещены). В таком виде имя неприглядно, но может использоваться даже с программным обеспечением, написанным до появления IDN.

Когда мы набираем в адресной строке доменное имя, содержащее символы вне ASCII, браузер преобразует имя в Punycode и в таком виде использует в запросах к доменным и HTTP-серверам. Аналогично, если браузер перенаправлен на адрес http://xn--l-4ga.no, он покажет в адресной строке понятное пользователю http://øl.no.

Сама по себе кодировка Punycode не накладывает ограничений на входные данные и может применяться для кодирования любой последовательности символов Unicode. Поэтому перед кодированием доменные имена проходят процедуру Nameprep [4], которая приводит текст к нижнему регистру и удаляет некоторые невидимые символы, например пробелы нулевой ширины и мягкие переносы. Кроме того, в ходе этой процедуры составные символы нормализуются, то есть приводятся к одной, строго определённой форме кодирования, а именно Unicode normalization form KC. Так, последовательность кодов U+0041 (A) и U+030A (кружок-комбинатор) превращается в символ U+00C5 (Å). В него же превращается и символ U+212B (знак ангстрема), выглядящий точно так же.

Процедура Nameprep определена именно так для того, чтобы пресечь опасное злоупотребление: регистрацию доменных имён, внешне неотличимых друг от друга, но технически различных. Отправив по электронной почте ссылку на такой домен с «альтернативным» написанием имени, злоумышленник мог бы заманить жертву на сайт-имитацию. Как мы увидим далее, Unicode-нормализации, включённой в Nameprep, недостаточно для полного исключения этого вида мошенничества. Кроме того, Unicode содержит некоторые невидимые управляющие символы, например маркер смены направления, задающий общее направление письма в тексте — слева направо или справа налево. Включение злоумышленником в состав доменного имени этого и других подобных управляющих символов могло бы позволить ему получить некоторую степень опасного контроля над отображением доменного имени в браузере. Поэтому важно, чтобы после обратного преобразования из Punycode в Unicode браузер удалял из строки все такие символы, ведь злоумышленник мог и не применять к своей исходной строке процедуру Nameprep.

Все современные браузеры поддерживают интернационализированные доменные имена: Firefox с версии 1.4, Opera с версии 7.11, Safari с версии 1.2, Internet Explorer с версии 7.0 (существует также дополнение к версии 6.0 для поддержки IDN). Поддержка IDN в браузере состоит из двух частей: преобразования имени из Unicode в ASCII при вводе и преобразования из ASCII в Unicode при отображении. Первая часть не несёт никакой угрозы. Браузер, в котором было бы реализовано только преобразование из Unicode в ASCII, позволял бы посещать сайты с нелатинскими именами, которые набирает пользователь, но отображал бы их в нечитаемой кодировке Punycode. Именно поддержка обратного преобразования представляет собой слабое место, уязвимое для различных атак. Например, после декодирования может оказаться, что результат содержит невидимые управляющие символы, прописные буквы (которые процедура Nameprep преобразует в строчные) или неканонические формы кодирования букв с диакритическими знаками. К счастью, всё это легко отсеять автоматически. Так, например, современные браузеры откажутся декодировать адрес http://xn--l-bfa.no в строку http://Øl.no: прописная буква Ø должна была превратиться в строчную, что дало бы ASCII-форму http://xn--l-4ga.no, следовательно, мы имеем дело с мошенническим сайтом, владелец которого пытается выдать его за настоящий øl.no.

Старая атака с новыми возможностями

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

Обычно для таких атак используется сходство букв с цифрами в некоторых шрифтах (буква l и цифра 1, буква O и цифра 0), сходство сочетаний букв (rn и m, cl и d), «незаметность» точки (wwwpaypal.com) и даже «рябь в глазах» от повторяющихся элементов (paypapal.com). При внимательном рассмотрении адресной строки, особенно при использовании шрифтов, избегающих опасного сходства символов, все эти приёмы нетрудно распознать. Тем не менее данный метод остаётся весьма успешным. Для противодействия ему некоторые крупные веб-сервисы превентивно регистрируют очевидные варианты ошибочного написания своих имён. Так, например, домен paypa1.com (с единицей вместо последней буквы) был зарегистрирован в 2000 году в пользу PayPal Inc компанией MarkMonitor, специализирующейся на охране торговых марок. Кроме того, в последнее время пользователям всё чаще советуют не щёлкать по ссылкам, полученным по электронной почте, а набирать адреса вручную. Впрочем, поскольку веб-сервисы продолжают включать удобные ссылки в рассылаемые почтовые уведомления, остаётся только догадываться, какая часть пользователей следует этому совету.

Интернационализированные доменные имена приносят в старый сценарий новые возможности. Поскольку в таких именах можно использовать буквы различных алфавитов, злоумышленник может заменить одну или несколько букв доменного имени их омографами — идентично или почти идентично выглядящими буквами другого алфавита. Поскольку и латиница, и кириллица исторически происходят от греческого алфавита, неудивительно, что, к примеру, во всех трёх из них есть буква o. С точки зрения человеческого глаза это одна и та же буква, а с точки зрения Unicode — три разных. Во многих шрифтах они выглядят совершенно одинаково, поэтому маскировочный потенциал омографов намного выше, чем у «опечаток».

Атаку с использованием IDN-омографов впервые описали в 2001 году Евгений Габрилович и Алекс Гонтмахер из израильского технологического института Технион [5]. Однако первый известный случай успешной атаки по этому методу был предан огласке только в 2005 году на хакерской конференции Shmoocon. Тогда хакерам удалось зарегистрировать подставной домен pаypal.com (xn--pypal-4ve.com в Punycode), где первая буква а — кириллическая [6]. Благодаря публикации на Slashdot.org к проблеме было привлечено внимание общественности, вскоре после чего как браузеры, так и администрации многих доменов верхнего уровня выработали и реализовали контрмеры.

Наиболее богатые возможности для омографической атаки предоставляет кириллица. Буквы а, с, е, і, ј, о, р, ѕ, х и у (некоторые из них относятся к вариантам кириллицы, используемым в болгарском, сербском и других языках) похожи на строчные латинские буквы, а З, Ч и б — на цифры. В греческом алфавите точную имитацию латиницы из строчных обеспечивают только буквы ο и ν, но использование прописных сильно расширяет набор. Некоторые другие греческие буквы (α, η, ι, ρ, υ, χ) похожи на латинские, но имеют видимые отличия. Ещё несколько отдельных возможностей предоставляют иврит и армянский алфавит. Наконец, если имя самого атакуемого домена — IDN, то немецкую лигатуру ß можно сымитировать греческой буквой β, а буквы расширенной латиницы ë и ï — похожими символами кириллицы.

Итак, у большинства гласных и у некоторых согласных латинского алфавита есть омографы, главным образом в кириллице. Использование омографов вместо части букв латиницы, входящих в доменное имя, порождает множество смешанных имён. С ростом длины доменного имени число возможных омографических имитаций возрастает экспоненциально, а значит, так же растёт и дороговизна превентивной скупки похожих доменных имён самим владельцем популярного домена. Так, для paypal.com возможно 31 альтернативное написание (без привлечения единицы вместо буквы l), для livejournal.com — 95 (учитывая возможность использования греческих ο и ν), для moneysupermarket.com — 383, для computerandvideogames.com — 9215 (!).

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

Отдельно следует заметить, что в китайской, японской и корейской письменности существует похожая проблема: один и тот же символ иногда имеет несколько альтернативных написаний, которые считаются отдельными символами Unicode. Например, китайские иероглифы U+6559 (教) и U+654E (敎), обозначающие «учить», «учение», логически взаимозаменяемы. Замена одного такого символа другим может породить имя, трудноотличимое от оригинала для носителя языка. Аналогично, некоторые символы персидского языка, письменность которого основана на арабской, слегка отличаются от соответствующих арабских форм и предоставляют некоторый потенциал для маскировки подставных доменов.

Противодействие омографической атаке

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

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

Браузер мог бы реализовывать ту или иную эвристику, призванную отличить возможное злоупотребление. Например, разумным представляется отказ от декодирования имён, содержащих символы разных алфавитов вплотную друг к другу, и отображение таких имён в виде Punycode. Однако эвристика неизбежно давала бы иногда как ложнонегативные результаты (разрешение злоупотреблений), так и ложнопозитивные (запрет легитимных имён). Последние особенно опасны: если пользователь привыкнет к тому, что имена некоторых легитимных доменов отображаются в виде «каши» из латиницы и цифр, то появление в адресной строке других Punycode-последовательностей легко сможет пройти незамеченным, так как для человеческого глаза все бессмысленные цепочки символов выглядят похоже друг на друга. С другой стороны, некоторые имена можно сымитировать одними только символами кириллицы, без смешения алфавитов.

Администрации многих доменов верхнего уровня [7], со своей стороны, решили противостоять омографическим атакам путём введения ограничений на регистрируемые имена. Задача, стоящая перед администрацией государственного домена верхнего уровня (ccTLD), такого как .de, облегчается тем, что такой домен вполне разумно считать предназначенным для регистрации названий на национальном языке страны. Так, например, домен .no разрешает использование букв æ, ø, å, используемых в норвежском языке, а также некоторых других символов расширенной латиницы, встречающихся в прочих языках Скандинавии. Обычно домены верхнего уровня в странах, пользующихся латинским алфавитом, ограничивают репертуар разрешённых символов тем или иным подмножеством расширенной латиницы. Так же поступает международный домен .org. Такой подход в целом безопасен, поскольку среди символов расширенной латиницы нет точных омографов.

В несколько особенных условиях находится греческий домен .gr. В нём разрешены имена из произвольной смеси латинского и греческого алфавитов, однако при регистрации любого имени все омографы этого имени автоматически становятся недоступными для регистрации кому-либо, кроме владельца зарегистрированного домена. Иными словами, пространство имён разделено на классы омографической эквивалентности, и имена в одном таком классе не могут принадлежать разным владельцам. Аналогичный подход практикуют китайский домен .cn, тайваньский .tw, японский .jp и корейский .kr в отношении омографических написаний внутри дальневосточных языков. Для противодействия злоупотреблениям доменными именами на этих языках группа Joint Engineering Team (JET) разработала свод правил, принятых на вооружение администрациями упомянутых доменов [8].

Интересный подход избрала администрация иранского домена .ir: доменные имена непосредственно в домене .ir могут содержать только символы ASCII, а для имён на персидском создан специальный поддомен .ایران.ir («Иран.ir»), где латиница запрещена. Кроме того, при регистрации доменного имени на персидском языке на имя заказчика автоматически регистрируется до шести вариантов, получаемых заменой персидских букв ک и ی арабскими аналогами.

Тайский домен .th разрешает как базовую латиницу, так и символы тайского языка, поскольку никакая их смесь не может представлять омографической опасности. Болгарский домен .bg разрешает имена, состоящие либо только из кириллицы, либо только из латиницы, причём кириллическое имя обязано содержать хотя бы одну букву, не имеющую омографа в латинице (например, я).

Международный домен .biz разрешает, помимо латиницы, символы китайского, японского и корейского языков, однако они не представляют опасности с точки зрения возможности омографической имитации латиницы. Заказчику предлагается выбрать один из 15 разрешённых языков, а затем указать имя, полностью состоящее из символов, разрешённых для выбранного языка. Похожую политику применяет и международный домен .info. Польский домен .pl — один из самых либеральных — руководствуется подобными правилами и разрешает и кириллицу, и греческий алфавит, и даже иврит.

После определённого периода, в течение которого в домене .ru можно было зарегистрировать кириллический домен, Координационный центр национального домена сети Интернет (http://cctld.ru) ограничил набор допустимых символов латинскими буквами, цифрами и дефисом. Для регистрации русскоязычных имён предназначен новый домен верхнего уровня .рф, который уже утверждён ICANN и будет делегирован в апреле 2010 года. Сейчас организациям доступна возможность предварительной регистрации имён в этом домене. Особенностью домена .рф является то, что имена в нём могут состоять только из кириллицы, цифр и дефисов — латиница запрещена. Само имя домена .рф было выбрано так, чтобы избежать омографии с другими доменами верхнего уровня — по этой причине не были приняты варианты .ро и .ру. Домен .рф стал одним из первых интернационализированных доменов верхнего уровня, одобренных ICANN, вскоре после египетского домена .مصر («Египет»). На очереди заявки на создание болгарского домена .бг и украинского .укр.

В таблице приведён список доменов верхнего уровня, администрации которых противодействуют омографической атаке (автор приносит извинения за возможную неполноту списка). К сожалению, многие домены по-прежнему разрешают регистрацию любых имён без ограничений. Особенно прискорбно, что контрмерами до сих пор не озаботилась американская компания VeriSign, администрирующая самый крупный в мире домен верхнего уровня .com, а также популярные домены .net, .tv, .name, .cc и .jobs. Не приведены также такие домены, как .me и .ru, полностью запрещающие регистрацию IDN и этим исключающие возможность омографической атаки.

Поскольку не все администрации доменов верхнего уровня ограждают пользователей от омографических атак, производители браузеров вынуждены держать второй рубеж обороны. Реализованные в современных браузерах решения представляют собой различные компромиссные варианты между безопасностью и нуждами международного сообщества. Браузеры Firefox и Opera используют белый список доменов верхнего уровня, проводящих политику, препятствующую омографическим атакам. Если домен верхнего уровня не входит в этот список, то интернационализированные доменные имена в нём отображаются в форме Punycode. Это, в частности, означает, что интернационализированные имена в домене .com отображаются как Punycode. Увидев в адресной строке xn--pypal-4ve.com вместо paypal.com, пользователь легко распознает подмену. Ведёт белый список Mozilla Foundation [9].

Internet Explorer применяет вместо белого списка эвристику и запрещает имена из смеси символов разных алфавитов, не разделённых точкой, с исключениями для языков, где такое смешение обычно. Следует заметить, что эта эвристика не защищает от атаки, при которой доменное имя полностью набирается кириллическими омографами (axe.com).

Safari позволяет настраивать список алфавитов, разрешённых к отображению в составе IDN; кириллица и греческий алфавит в этот список по умолчанию не входят. Хотя это решение обезопасило американских и многих европейских пользователей, оно не решает проблему, в частности, для русскоязычных пользователей, оставляя их либо уязвимыми, либо без возможности пользоваться доменами с именами на родном языке.

Теоретически меры противодействия, реализованные в браузерах, — временные. Когда все домены верхнего уровня станут пресекать регистрацию опасных имён, эти меры станут не нужны. Однако как скоро это произойдёт, предсказать трудно. Особенно сложная задача по выработке безопасной политики стоит перед компанией VeriSign, поскольку домен .com и другие домены верхнего уровня, которые она администрирует, — международные и должны удовлетворять потребности заказчиков изо всех стран мира.

Заключение

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

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

Список ссылок

1. RFC3490. P. Faltstrom, P. Hoffman, A. Costello. Internationalizing Domain Names in Applications (IDNA), 2003.

2. RFC1034. P. Mockapetris. Domain Names — Concepts and Facilities, 1987.

3. RFC3492. A. Costello. Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA), 2003.

4. RFC3491. P. Hoffman, M. Blanchet. Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN), 2003.

5. E. Gabrilovich, A. Gontmakher. The Homograph Attack, Communications of the ACM, 45(2):128, 2002.

6. E. Johanson. The State of Homograph Attacks, 2005.

7. Internet Assigned Numbers Authority. Repository of IDN Practices, 2010.

8. RFC3743. K. Konishi, K. Huang, H. Qian, Y. Ko. Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean, 2004.

9. Mozilla Foundation. IDN-enabled TLDs, 2010.

Последнее обновление: 17.03.2012.

И вот, относительно недавно свет увидели несколько новых вредоносных программ класса «буткит». Это знаковое событие, указывающее на то, что практика применения буткит-техник во вредоносных программах не закончится одиночными образцами, а, возможно, приобретёт более массовый характер.

Derek Soeder, Ryan Permeh. bh-us-05-soeder.pdf (файл не сохранился в интернете).

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

Технические средства для анализа буткитов

Код буткита невозможно анализировать при помощи обычных отладчиков режима ядра, так как он начинает исполнятся на самом раннем этапе работы системы, а именно после того, как BIOS передаёт управление загрузочному сектору. Поэтому для отладки загрузочного кода могут быть использованы лишь виртуальные машины с возможностью отладки исполняемого кода. На данный момент необходимыми возможностями обладают виртуальные машины QEMU и Bochs. Рассмотрим каждую из этих программ подробнее.

Отладка при помощи QEMU

QEMU Emulator User Documentation. 3.11 GDB usage.

QEMU — свободно распространяемая программа с открытым исходным кодом. Её возможности включают в себя эмуляцию процессоров с архитектурой x86, x86-64 и многих других, а также устройств ввода-вывода. Поддерживается отладка эмулируемого кода с помощью отладчика GDB, что подробно описано в документации к QEMU.

Использование GDB в связке с QEMU

gdb_qemu.pdf (файл не сохранился в интернете).

По мнению автора статьи, вместо GDB удобнее использовать отладчик, встроенный в дизассемблер IDA Pro, начиная с версии 5.4. Процесс настройки отладчика и виртуальной машины подробно описан в документации к IDA Pro. Остановимся на некоторых особенностях, касающихся отладки загрузочного кода.

После подключения отладчика к виртуальной машине и инициализации сессии необходимо установить аппаратную точку останова на адрес 0000:7C00h, с которого начинает исполняться загрузочный код. Для этого перейдем на вкладку «Breakpoints» и в контекстном меню выберем пункт «Insert...».

Добавление новой точки останова в IDA Pro

После добавления точки останова исполнение кода можно продолжить (F9).

Заметим, что для отладки 16-битного кода необходимо вручную отредактировать настройки сегмента после того, как сработает точка останова. Для этого откроем пункт главного меню «Edit» → «Segments» → «Edit Segment...» и установим 16-разрядный режим адресации для текущего сегмента.

Настройки сегмента в IDA Pro

После этого можно перейти в окно анализа кода и исследовать код загрузочного сектора.

Отладка загрузочного кода в IDA Pro

Отладка при помощи Bochs

Bochs — свободно распространяемая система, возможности которой включают в себя эмуляцию процессоров архитектуры x86/x86-64 и устройств ввода-вывода.

Данная система отличается высокой точностью эмуляции, так как интерпретирует каждую инструкцию виртуального процессора. Однако по той же причине Bochs заметно проигрывает с точки зрения производительности не только популярным виртуальным машинам, таким как VMware или VirtualBox, но и вышеописанному эмулятору QEMU. Поэтому перед запуском Bochs целесообразно иметь уже готовый образ жесткого диска с установленной операционной системой. Такой образ можно создать с помощью QEMU.

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

Окно запуска Bochs

После запуска виртуальной машины открывается консоль отладчика с аскетичным, но достаточным для работы набором команд, список которых доступен по команде help. Для установки точки останова на начало загрузочного кода достаточно набрать lb 0x7c00 и затем c для продолжения исполнения кода.

Отладка кода в Bochs

Анализ новых буткитов Backdoor.Win32.Trup.a (Alipop)

Буткит Alipop появился примерно в мае 2010 года. Он имеет китайское происхождение, о чем свидетельствуют рекламные всплывающие окна и AdWare на китайском языке.

Самозащита

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

В действительности вышеприведенный код исполняется в следующем виде:

Как видно из листинга, пятибайтовая инструкция call по адресу 00405484 не несёт полезной нагрузки, поскольку предшествующие ей переходы всегда передают управление по адресу 00405485, где на самом деле находится инструкция push. Использование данного приёма затрудняет анализ кода в дизассемблере IDA, а его декомпиляция с помощью HexRays оказывается невозможной без предварительной обработки кода.

Инсталлятор

Инсталлятор буткита представляет собой исполняемый файл размером около 24 кБ (MD5: 3f5cff08b83a0a9ad5f8e0973b77a2ac), внутри которого содержатся все остальные компоненты буткита.

При запуске инсталлятора создается и запускается файл C:\WINDOWS\ali.exe (MD5: 570e6e5c1d0c95c5a446f6f62fa90468, размер около 17 кБ), который содержит в себе основной рабочий код трояна.

Для обеспечения автозагрузки инсталлятор записывает код буткита в первые 40 секторов жесткого диска:

Инфицированная MBR

Код буткита вызывается при следующей перезагрузке системы.

Загрузочный код

Загрузочный код буткита, во-первых, резервирует 20 кБ базовой памяти. Для этого он уменьшает значение объёма базовой памяти в соответствующей переменной BIOS по адресу 0040h:0013h. В зарезервированную область с помощью функции 2 прерывания 13h считываются компоненты буткита из первых 40 секторов жесткого диска, после чего управление передается прочитанному коду.

Прочитанные код и данные, начиная со смещения 83h, зашифрованы с помощью обратимой операции ROR, и далее происходит их расшифровка. После расшифровки буткит устанавливает перехват прерывания 13h BIOS, что позволяет осуществлять контроль за операциями чтения с диска на начальных этапах загрузки системы. Наконец, происходит вызов оригинального загрузчика ОС, сохранённого инсталлятором буткита в секторе 39.

Перехват прерывания 13h устанавливается с целью модификации кода модуля OSLOADER.EXE, представляющего собой часть модуля NTLDR, при его чтении с системного раздела. Задача осуществляемой модификации — передача управления на код буткита, исполняемый в защищённом режиме: именно в этом режиме исполняется OSLOADER.EXE.

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

Искомый код OSLOADER представляет собой следующий набор инструкций:

Приведенный фрагмент относится к функции _BlOsLoader@12(). Модифицируемые буткитом байты непосредственно следуют за вызовом функции _BlLoadBootDrivers@12(). Эта функция загружает в память драйверы системных сервисов, имеющих тип запуска SERVICE_BOOT_START. Код модификации представляет собой инструкцию call, которая передаёт управление резидентному коду буткита, находящемуся в зарезервированной базовой памяти по смещению 200h. Таким образом, код буткита получит управление в тот момент, когда процессор будет находится в 32-битном защищённом режиме.

Код защищённого режима

Код буткита защищённого режима начинает своё исполнение с получения адреса загрузки ядра. Этот адрес извлекается из первой записи списка загруженных модулей, представляющей собой структуру типа LDR_DATA_TABLE_ENTRY. Указатель на список загруженных модулей может быть получен из глобальной переменной _BlLoaderBlock модуля OSLOADER.EXE. В частности, переменная _BlLoaderBlock содержит указатель на структуру _LOADER_PARAMETER_BLOCK, копия которого используется как локальная переменная в коде функции _BlAllocateDataTableEntry@16(). Для поиска этого участка кода буткит также использует сигнатуру.

Кроме того, виртуальный адрес памяти, по которому загружается NTLDR и другие системные модули, извлекается из локальной переменной KdDllBase, к которой модифицированная функция _BlOsLoader@12() обращается по фиксированному смещению от ebp:

В процедуре sub_267 выполняется перехват функции ядра nt!IoGetCurrentProcess() таким образом, чтобы при её вызове управление получал код буткита следующего, третьего этапа, которому необходимо исполняться в 32-разрядном защищённом режиме после инициализации ядра операционной системы.

Обычно первый вызов функции nt!IoGetCurrentProcess() происходит по завершению инициализации ядра с помощью функции nt!Phase1Initialization():

Код, выполняемый после инициализации ядра

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

Обработчик перехвата nt!IoGetCurrentProcess() выполняет восстановление оригинального кода функции, после чего вызывает nt!PsCreateSystemThread() для запуска системного потока, который выполняет код «полезной нагрузки» буткита. Код «полезной нагрузки» делает следующее:

1. Создаёт в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run строковый параметр со значением C:\WINDOWS\ali.exe, обеспечивая запуск троянского процесса по завершению загрузки системы.

2. Создаёт файл C:\WINDOWS\ali.exe, содержимое которого на этапе инсталляции буткита в систему записывается инсталлятором, начиная с сектора 4 жесткого диска.

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

Дмитрий Олексюк. Уязвимости в драйверах режима ядра для Windows.

Шлюз вызова в GDT («чёрный ход»)

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

Троянский процесс

Основная задача процесса ali.exe — получение с сервера команд на скачивание и запуск других вредоносных программ. При этом для отправки HTTP-запросов используется процесс браузера Internet Explorer, запускаемый со скрытым окном.

Троянский процесс

Запрос файла конфигурации с сервера

Зашифрованный файл конфигурации трояна загружается с сервера по фиксированному адресу http://list.577q.com/sms/xxx.ini и сохраняется в каталоге C:\WINDOWS под именем win.ini.

Пример содержимого файла конфигурации:

Троян Alipop, хотя и использует технику заражения загрузочного сектора, может быть легко обнаружен и удален, так как в нём отсутствуют механизмы сокрытия вредоносной активности. Не предусмотрен в нем и защитный механизм восстановления загрузочного сектора буткита при попытке его перезаписи. Благодаря всему этому возможно излечить зараженную систему путем ручного восстановления загрузочной записи с помощью любого шестнадцатеричного дискового редактора (например, WinHex).

Mebratix.b (Ghost Shadow)

Symantec Security Response. Trojan.Mebratix.B — the Ghost in MBR.

Информация о бутките Mebratix впервые была опубликована в блоге компании Symantec.

Инсталлятор этого буткита (MD5: 1b465d5c330d99bdccffd299bf71010f, размер около 30 кБ) не отличается чем-либо примечательным.

Загрузочный код

Загрузочный код буткита Mebratix полностью идентичен стандартному загрузочному коду Windows, за исключением единственной трёхбайтовой инструкции. Рассмотрим оба дизассемблированных кода.

Загрузочный код Windows:

Загрузочный код Mebratix:

Как видно из вышеприведенных листингов, загрузочный код Mebratix отличается от стандартного аргументами к инструкции mov, находящейся по смещению 00D0h от начала загрузочного кода. Исходный вариант кода, по замыслу его разработчиков, выполняет чтение и передачу управления в первый сектор загрузочного раздела, а код буткита — во второй сектор диска, содержащий продолжение вредоносного кода.

Загрузочный код Mebratix (отличающаяся от кода стандартного загрузчика инструкция выделена)

Код буткита, содержащийся во втором секторе диска, выполняет резервирование 63 кБ базовой памяти тем же способом, что и буткит Alipop, затем копирует самого себя по адресу 9700:0000h и устанавливает перехватчик прерывания 13h:

Следующая часть загрузочного кода выполняет чтение 59 секторов жесткого диска (начиная с сектора 3) в память по адресу 9700:0200h. В этих секторах хранятся все остальные компоненты буткита, причём сектора с 3 по 6 зашифрованы с помощью операции xor, ключевой байт для которой вычисляется динамически на каждой итерации. Ниже приведен фрагмент кода, выполняющего расшифровку секторов.

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

Обработчик перехвата прерывания 13h выполняет модификацию кода модуля OSLOADER.EXE точно таким же образом, как это делает буткит Alipop.

Код защищённого режима

Код буткита защищённого режима, вызываемый из модифицированного модуля OSLOADER.EXE, служит для инициализации и запуска драйвера режима ядра буткита. Рассмотрим этот код подробнее.

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

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

Для передачи управления коду загрузчика драйвера буткит модифицирует функцию ядра nt!PspCreateProcess() таким образом, чтобы в её начале вместо вызова функции nt!_SEH_prolog() осуществлялся вызов загрузчика драйвера буткита.

Код функции до модификации:

Код после модификации:

Так как функция nt!PspCreateProcess() не экспортируется ядром, буткит выполняет её поиск путём анализа кода экспортируемой функции nt!PsCreateSystemProcess(), а именно побайтовым поиском опкода первой инструкции call (E8h), аргументом которой и является адрес функции nt!PspCreateProcess():

Обычно первый вызов nt!PspCreateProcess() происходит на этапе инициализации исполнительной подсистемы ядра:

Загрузчик драйвера

Код загрузчика драйвера режима ядра буткита выполняет следующие действия:

1. Получение PID текущего процесса с помощью nt!PsGetCurrentProcessId(). Если значение отличается от 4 (PID процесса System), происходит вызов nt!_SEH_prolog() и возврат в nt!PspCreateProcess().

2. Получение адреса nt!psLoadedModulesList путём сигнатурного анализа кода nt!KeCapturePersistentThreadState().

3. Выделение 10000h байт памяти для образа драйвера с помощью nt!ExAllocatePoolWithTag().

4. Копирование заголовков и секций драйвера в выделенную область памяти.

5. Восстановление модифицированного кода nt!PspCreateProcess().

6. Вызов точки входа драйвера буткита.

Драйвер и «полезная нагрузка»

Назначение драйвера буткита — внедрение кода пользовательского режима в процесс explorer.exe и установка перехватов на обработчики IRP-запросов типа IRP_MJ_READ/IRP_MJ_WRITE драйвера класса диска Disk.sys (\Driver\Disk). Указанные перехваты обеспечивают защиту секторов диска, в которых хранятся компоненты буткита, от попыток чтения или перезаписи со стороны антивирусных программ. Стоит отметить, что код драйвера работает нестабильно, и во многих случаях при заражении компьютера не происходит установки перехватов и внедрения кода пользовательского режима.

Код пользовательского режима отправляет HTTP-запросы на сервер meifawu.com. Файл конфигурации трояна загружается с адреса http://meifawu.com/n.txt.

Отправляемые на сервер запросы

Black Internet Trojan

Буткит под названием Black Internet Trojan появился совсем недавно. Из всех новых буткитов он наименее известен, но и наиболее распространён, о чем можно судить по активности на антивирусных форумах. Одним из первых источников, в которых появилась информация о заражении, был англоязычный антивирусный форум MajorGeeks, а несколькими днями позже о нём сообщили и на русскоязычном VirusInfo.

Инсталлятор и самозащита

Инсталлятор буткита (MD5: e35310220715287c5765b273a1797836, размер файла около 1,2 МБ) защищён неизвестным шифровщиком. В коде расшифровки реализовано определение виртуальных машин VMware по факту присутствия характерного для них «черного хода»:

Для того чтобы обойти данный механизм самозащиты буткита, достаточно добавить в конец файла конфигурации VMware (.vmx) строку, отключающую функцию «VMWare backdoor»:

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

Предупреждение UAC при запуске установщика

В заключение, непосредственно перед записью загрузочного кода на диск установщик ищет активную утилиту Process Monitor по характерному для неё значению оконного класса:

Загрузочный код

Одной из отличительных особенностей буткита Black Internet является то, что свои компоненты он хранит не в первых 63 секторах (обычно именно такое количество свободного пространства присутствует перед началом первого раздела диска), а в неразмеченной области, следующей за последним разделом:

Загрузочный сектор буткита узнаёт месторасположение этой неразмеченной области при разборе таблицы разделов, находящейся в MBR, после чего выполняет чтение 64 секторов, в которых хранятся остальные компоненты буткита.

Затем буткит выполняет ряд стандартных действий, которые были подробно рассмотрены при анализе двух предыдущих вредоносных программ:

1. Резервирование 4 кБ базовой памяти.

2. Перехват прерывания 13h.

3. Сигнатурный поиск и модификацию кода OSLOADER.EXE в обработчике int 13h.

4. Считывание и исполнение загрузочного кода системного раздела.

Код защищённого режима

Рассмотрим код буткита защищённого режима, вызываемый из модифицированного модуля OSLOADER.EXE.

Действия кода защищённого режима буткита сводятся к инициализации загрузчика драйвера режима ядра. Для этого выполняются следующие операции:

1. Сигнатурный анализ функции nt!Phase1Initialization() и выявление в ней точки вызова функции nt!IoInitSystem().

2. Замена вызова nt!IoInitSystem() вызовом загрузчика драйвера буткита.

3. Копирование кода загрузчика в область памяти непосредственно за ядром операционной системы.

Адрес структуры _BlLoaderBlock, в которой содержится указатель на список загруженных модулей, ищется методом сигнатурного анализа кода OSLOADER.EXE так же, как это реализовано в бутките Alipop.

В предыдущем листинге приведен алгоритм установки перехватчика функции IoInitSystem(). Рассмотрим, как выглядит сам перехват.

Код функции nt!Phase1Initialization() до модификации:

Код после модификации:

Загрузчик драйвера

Загрузчик драйвера режима ядра выполняет следующие действия:

1. Восстановление оригинального вызова nt!IoInitSystem() в коде nt!Phase1Initialization().

2. Вызов nt!IoInitSystem() с повторной передачей управления в загрузчик драйвера через подменённый адрес возврата на стеке.

3. Поиск адреса загрузки ядра ОС по первому вектору в таблице прерываний, адрес которой получается инструкцией sidt.

4. Сигнатурный поиск nt!PsLoadedModuleList. Адрес извлекается из ссылки на эту переменную в коде неэкспортируемой функции nt!IopWriteDriverList().

5. Получение по хэшам адресов ExAllocatePool, ExFreePool, KeLoaderBlock, NtClose, NtCreateFile, NtReadFile.

6. Считывание драйвера режима ядра из неразмеченной области в конце диска.

7. Настройка исполняемого образа драйвера и передача управления его точке входа.

8. Возврат управления в nt!Phase1Initialization().

Драйвер и «полезная нагрузка»

Драйвер буткита служит для внедрения кода пользовательского режима в процесс winlogon.exe. Для этого он создаёт системный поток, который циклически опрашивает список процессов путём анализа двусвязных списков структур ядра _EPROCESS и выполняет поиск требуемого процесса по имени исполняемого файла. Смещения нужных полей для структур _EPROCESS и _ETHREAD хранятся в глобальных переменных, значения которых инициализируются в зависимости от версии ядра операционной системы. Значение версии ядра может быть получено с помощью функций PsGetVersion() и RtlGetVersion(). Ниже приведен псевдокод функции, выполняющей поиск процесса по имени.

После получения указателей на нужный процесс и его действительный поток драйвер режима ядра выполняет чтение кода пользовательского режима из неразмеченной области диска и его внедрение в процесс winlogon.exe.

Назначение кода пользовательского режима — запуск троянского процесса с «полезной нагрузкой». Соответствующий модуль хранится в файле C:\System Volume Information\Microsoft\services.exe, который создаётся установщиком на этапе инсталляции буткита в систему.

Троянский процесс, в свою очередь, является «кликером»: после запроса конфигурации с сайта www.weathertalkz.com он осуществляет множественные переходы по рекламным баннерам в контексте процесса браузера Internet Explorer, работающего со скрытым окном.

Запрос конфигурации с www.weathertalkz.com

Лечение заражения

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

• OK (DOS/Win32 Boot code found) — MBR содержит оригинальный загрузочный код операционной системы DOS/Windows.

• Unknown boot code — MBR содержит неизвестный загрузочный код. На практике это может означать, что в системе присутствует буткит, который не скрывает модифицированный загрузочный код. Этот же статус будет выводится в случае использования какого-либо нестандартного менеджера загрузки: GRUB, TrueCrypt, Acronis и т. п.

• Controlled by rootkit! — в системе обнаружен активный буткит, который препятствует чтению модифицированного загрузочного кода стандартными средствами операционной системы.

Bootkit Remover

Для восстановления оригинального загрузочного кода Windows утилиту необходимо запускать со следующими параметрами:

Где <device> — это имя устройства физического накопителя, на котором требуется восстановить загрузочный код (например, \\.\PhysicalDrive0).

Для вывода загрузочного кода в консоль или в файл используется команда dump:

Так как рассмотренные в данной статье буткиты определяются утилитой как «Unknown boot code», анализ системы с таким результатом проверки необходимо производить в несколько шагов:

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

1. Если в исследуемой системе нет программ, которые могли бы модифицировать MBR, вердикт «Unknown boot code» является поводом для подозрений на заражение буткитом.

2. Необходимо сделать дамп загрузочного кода и проверить его в онлайн-сервисе VirusTotal: если буткит не целевой, то его загрузочный код с большой долей вероятности будет опознан антивирусами.

3. Если код не был опознан, то нужно установить программу нестандартного загрузчика, предположительно модифицировавшую MBR, в заведомо чистую операционную систему и побайтово сравнить полученный с неё дамп загрузочного сектора с дампом, полученным с проверяемой системы.

4. В случае необходимости восстановить оригинальную MBR.

Список литературы

1. Дмитрий Олексюк. Анализ и обнаружение буткита Sinowal.

2. Derek Soeder, Ryan Permeh. bh-us-05-soeder.pdf (файл не сохранился в интернете).

3. QEMU Emulator User Documentation. 3.11 GDB usage.

4. gdb_qemu.pdf (файл не сохранился в интернете).

5. Дмитрий Олексюк. Уязвимости в драйверах режима ядра для Windows.

6. Symantec Security Response. Trojan.Mebratix.B — the Ghost in MBR.

Последнее обновление: 17.03.2012.

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

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

В качестве отладчика мной будет использоваться WinDbg из пакета Microsoft Debugging Tools for Windows. Удобство в использовании, гибкость, расширяемость, возможность удалённой отладки по COM, 1394 или USB-порту, а также поддержка 64-разрядных систем делают WinDbg одним из самых привлекательных отладчиков ядра на данный момент. Однако и тем, кто использует Syser или SoftIce, не составит труда произвести описываемые действия.

Данная статья не претендует на достойную справочника по NT internals полноту раскрытия темы руткитов; она лишь даёт общее понимание логики их поиска и нейтрализации.

Приступая к работе

Для того чтобы иметь возможность полноценно отлаживать ядро операционной системы с помощью WinDbg, требуется два компьютера. При этом в качестве второго (целевого) компьютера можно использовать виртуальную машину. Для этого нужно настроить в виртуальной машине COM-порт и сконфигурировать гостевую ОС для поддержки удаленной отладки, после чего можно подключить к выбранному COM-порту WinDbg.[^1]

После того как получена работающая связка «виртуальная машина — отладчик», нужно загрузить отладочные символы для системных модулей. В отличие от SoftIce, при этом нет необходимости что-либо скачивать, конвертировать и добавлять вручную: WinDbg сам загрузит с сервера Microsoft отладочные символы для актуальной версии ядра и драйверов. Для этого достаточно в пункте меню File → Symbol File Path прописать строку вида:

Здесь C:\symbols — произвольный локальный каталог для сохранения загруженных отладочных символов.

Рис. 1. Настройка путей для загрузки отладочных символов.

Для того чтобы загрузить или перезагрузить символы, используется команда отладчика .reload.

Обратимся к сути проблемы. Каким образом работающий в системе руткит может препятствовать работоспособности антируткита? Очевидно, что для этого ему необходимо перехватывать управление в определённых точках операционной системы, препятствуя запуску или инициализации определённой программы. Способов и точек для осуществления такого контроля достаточно много. К ним относятся как стандартные механизмы, предоставляемые операционной системой, так и недокументированные, такие как сплайсинг ключевых функций, подмена указателей в различных внутренних структурах ядра и драйверов, техники вроде Direct Kernel Object Manipulation и многое другое.

По способу реализации и целевому предназначению все механизмы контроля запуска программ можно разделить на четыре условные категории:

• контроль системных событий с использованием нотификаторов;

• перехват системных вызовов;

• перехват файловых операций;

• перехват методов диспетчера объектов.

Рассмотрим их по порядку.

[^1]: См. список литературы, источник 1.

Контроль системных событий с использованием нотификаторов

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

Процессы

Для установки нотификатора на создание или завершение процесса используется функция ядра PsSetCreateProcessNotifyRoutine:

Функция получает два аргумента:

• NotifyRoutine — указатель на регистрируемую функцию, вызываемую при создании или завершении процесса;

• Remove — TRUE, если нотификатор удаляется, и FALSE, если устанавливается.

Функция-нотификатор должна иметь тип PCREATE_PROCESS_NOTIFY_ROUTINE:

Параметры ParentId и ProcessId являются идентификаторами родительского и создаваемого или завершаемого процесса соответственно. В качестве Create передаётся TRUE, если процесс создаётся, и FALSE, если завершается.

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

Рассмотрим, что происходит, когда драйвер регистрирует новый нотификатор, вызывая PsSetCreateProcessNotifyRoutine.

Список нотификаторов находится в секции данных ядра. Его размер определяется внутренней константой PSP_MAX_CREATE_PROCESS_NOTIFY, которая в 32-разрядных Windows XP, 2003 Server и Vista равняется 8. Сам список имеет следующий тип:

Структура EX_CALLBACK выглядит так:

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

Поле Function является указателем на функцию-нотификатор, переданную в PsSetCreateProcessNotifyRoutine при её установке.

Сама функция работает довольно просто:

1. Циклическим перебором массива PspCreateProcessNotifyRoutine ищется нулевой элемент.

2. Выделяется память в подкачиваемом пуле ядра под служебные структуры.

3. Инициализируются служебные структуры.

4. Новый указатель добавляется в список PspCreateProcessNotifyRoutine.

5. Инкрементируется PspCreateProcessNotifyRoutineCount — количество активных нотификаторов.

6. Возвращается STATUS_SUCCESS.

Таким образом, для перечисления активных нотификаторов на создание процессов нужны адреса внутренних переменных ядра PspCreateProcessNotifyRoutine и PspCreateProcessNotifyRoutineCount. Найти их очень просто: откроем в WinDbg машинный код PsSetCreateProcessNotifyRoutine, введя nt!PsSetCreateProcessNotifyRoutine в поле Offset окна дизассемблера (View → Disassembly, или Alt+7).

Определение PSP_MAX_CREATE_PROCESS_NOTIFY и перебор списка:

Добавление нотификатора в список:

Выделение памяти под EX_CALLBACK_ROUTINE_BLOCK и его заполнение:

Переменная PspCreateProcessNotifyRoutine не экспортируется ядром, однако, если отладочные символы загружены, её имя будет видно в окне отладчика.

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

В данном случае в системе установлен один нотификатор. Адрес указателя на EX_CALLBACK_ROUTINE_BLOCK для него — e184e1d0 (не забываем отбрасывать младшие три бита). Из него легко узнать адрес функции-обработчика:

Так как поле Function находится по смещению 4, адрес нотификатора равен f95398d8.

Рис. 2. Rootkit Unhooker обнаружил нотификаторы, установленные фаерволом Outpost.

Удалить этот нотификатор можно, затерев нулями соответствующий элемент массива:

И уменьшив на 1 значение PspCreateProcessNotifyRoutineCount:

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

Что касается PspCreateProcessNotifyRoutineCount и аналогичных переменных, в памяти она всегда находится сразу же за списком PspCreateProcessNotifyRoutine. Этот факт избавляет разработчика от необходимости писать отдельный код для её поиска при разработке монитора нотификаторов или части руткит-детектора.

Рис. 3. Поиск PspCreateProcessNotifyRoutineCount.

Потоки

Для установки нотификатора на создание и завершение потоков используется функция PsSetCreateThreadNotifyRoutine:

NotifyRoutine — указатель на функцию, вызываемую при создании или завершении потока:

ProcessId и ThreadId содержат идентификаторы процесса и создаваемого или завершаемого потока. Create равен TRUE, если поток создаётся, и FALSE, если завершается. Список хранится в PspCreateThreadNotifyRoutine; его максимальный размер PSP_MAX_CREATE_THREAD_NOTIFY равен 8, а число активных элементов находится в PspCreateThreadNotifyRoutineCount.

Принципы работы всех функций установки нотификаторов одинаковы. Перечисление и удаление нотификаторов на потоки происходит точно так же, как и нотификаторов на процессы.

Исполняемые образы

Ещё один способ блокировать работу приложения заключается в использовании нотификаторов на загрузку исполняемых образов. Они устанавливаются функцией PsSetLoadImageNotifyRoutine:

Функция-нотификатор вызывается при загрузке в адресное пространство процесса любого модуля, включая исполняемый файл процесса и DLL, а также при загрузке драйверов в память ядра:

В FullImageName передаётся полный дисковый путь к образу, в ProcessId — идентификатор процесса (или 0 для драйвера режима ядра).

Список хранится в PspLoadImageNotifyRoutine, число активных элементов — в PspLoadImageNotifyRoutineCount, а PSP_MAX_LOAD_IMAGE_NOTIFY также равна 8.

Код функции предельно похож на PsSetCreateThreadNotifyRoutine.

Системный реестр

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

Нотификаторы устанавливаются функцией CmRegisterCallback:

Function — указатель на нотификатор, Context — передаваемые ему данные, а Cookie — уникальный идентификатор для удаления через CmUnRegisterCallback.

В Argument1 и Argument2 передаются код типа события и ассоциированные с ним данные. События охватывают операции от открытия ключа до перечисления подключей или параметров и делятся на пред- и постнотификационные. Подробности приведены в Windows Driver Development Kit.

Список хранится в CmpCallBackVector, количество — в CmpCallBackCount. Размер задаётся CM_MAX_CALLBACKS и равен 100.

Автоматизация разбора списков нотификаторов

Отладчик WinDbg имеет свой скриптовый язык. Скрипты представляют собой текстовые файлы с обычными командами отладчика и управляющими директивами .if, .else, .elsif, .foreach, .for, .while, .do, .break, .continue, .catch, .leave, .printf, .block. В качестве переменных могут использоваться псевдорегистры ($tn, где n — целое число), назначаемые командой r, а также алиасы.[^2] Для логических выражений есть MASM-подобный и C-подобный синтаксис (в последнем случае выражение обрамляется в @@c++(expression)).

Простой скрипт, выводящий список всех нотификаторов:

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

Здесь C:\dbg_show_callbacks.txt — путь к скрипту.

Рис. 4. Вывод информации о нотификаторах с помощью скрипта.

Отключение всех нотификаторов

Альтернатива ручному исправлению списков нотификаторов с целью нейтрализации вредоносного кода — полное отключение механизма нотификации.

Механизмы rundown protection синхронизируют доступ к элементам массива EX_CALLBACK. При использовании нотификатора вызывающий код инкрементирует число ссылок на EX_CALLBACK_ROUTINE_BLOCK, вызывая при переборе массива ExReferenceCallBackBlock и проверяя её результат. Например, нотификаторы на создание процесса вызываются так:

Функция-нотификатор не будет вызвана, если ExReferenceCallBackBlock вернёт ноль. Поэтому для отключения нотификаторов можно модифицировать её так, чтобы она всегда возвращала 0. Функция имеет соглашение stdcall и один параметр, поэтому достаточно заменить первые байты на xor eax,eax; ret 4.

Пролог до патчинга:

Правим первые восемь байт:

После патчинга:

Подобная модификация структур ядра при помощи отладчика настолько же безопасна, насколько обычный сплайсинг: проблемы возможны только если в момент остановки системы по Ctrl+Break какой-либо поток исполнял модифицируемый код. ExReferenceCallbackBlock вызывается сравнительно редко, поэтому вероятность краха после патчинга мала. Однако манипуляции могут привести к частичной или полной неработоспособности всех драйверов, использующих нотификаторы. Таких драйверов мало, а в «чистой» системе с конфигурацией по умолчанию нет вовсе.

[^2]: См. список литературы, источник 2.

Диспетчер системных вызовов

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

Обработка системного вызова

Рассмотрим процедуру обработки вызова API-функции на примере CreateFileA из kernel32.dll.

Рис. 5. Диспетчер системных вызовов.

Архитектура системного API в операционных системах семейства NT имеет иерархическую организацию. Базовыми кирпичиками для большинства DLL являются функции Native API, импортируемые из ntdll.dll; их имена начинаются с префиксов Zw* или Nt*. В пользовательском режиме парные функции, например ZwCreateFile и NtCreateFile, имеют одну точку входа. Их небольшие заглушки переводят поток в режим ядра, после чего диспетчер передаёт управление соответствующей функции ntoskrnl либо win32k.

Код помещает в eax номер системного вызова и вызывает адрес из SharedUserData!SystemCallStub. В зависимости от процессора там находится вызов инструкции sysenter (ntdll!KiFastSystemCall) или программного прерывания 2Eh (ntdll!KiIntSystemCall). Windows 2000 и более ранние версии NT использовали только прерывание 2Eh; этот путь сохранён в поздних версиях для обратной совместимости.

В обоих случаях в edx помещается указатель на область стека с аргументами Native API. Вектор прерывания 2Eh обычно указывает на nt!KiSystemService:

Обработчик сохраняет пользовательский контекст, переключает стек приложения на стек ядра, а селектор fs — со структуры TEB на KPCR. Возврат в пользовательский режим выполняется инструкцией iret.

Обработчик sysenter задаётся MSR-регистрами:

Для возврата используется sysexit; указатели на ntdll!KiFastCallRet и пользовательский стек помещаются в edx и ecx. MSR читаются инструкцией rdmsr, записываются wrmsr; в WinDbg им соответствуют одноимённые команды.

Код по адресу 0x8053c710 (nt!KiFastCallEntry), как и nt!KiSystemService, является точкой входа диспетчера системных вызовов.

Для поиска обработчика по номеру вызова ядро использует дескрипторы KeServiceDescriptorTable и KeServiceDescriptorTableShadow. Каждый содержит четыре таблицы; в первой используется таблица функций ядра, а в Shadow дополнительно вторая таблица графической подсистемы.

Base указывает на адреса функций (nt!KiServiceTable или win32k!W32pServiceTable), Limit задаёт число записей, а Number — массив размеров аргументов (nt!KiArgumentTable или win32k!W32pArgumentTable). Поле Count служит отладочным счётчиком.

Указатель на используемый дескриптор хранится в KTHREAD::ServiceTable. Диспетчер выделяет из номера системного вызова номер таблицы и индекс функции:

При создании потока KeInitThread устанавливает обычный дескриптор:

Номера графических вызовов начинаются с 1000h. Если такой вызов сделан впервые, KiBBTUnexpectedRange вызывает PsConvertToGuiThread, которая меняет стек и устанавливает в KTHREAD::ServiceTable адрес KeServiceDescriptorTableShadow.

Функции Zw и Nt

В пользовательском режиме Zw* и Nt* имеют общую точку входа, но в ядре это разные функции. Zw* вызываются только драйверами и повторно проходят через диспетчер системных вызовов. При этом PreviousMode равен KernelMode, поэтому проверка аргументов как пользовательских указателей пропускается.

Методика перехвата

Диспетчер системных вызовов можно перехватить несколькими способами:

1. Подменить указатель на функцию в KiServiceTable.

2. Изменить IA32_SYSENTER_CS или IA32_SYSENTER_EIP.

3. Подменить KTHREAD::ServiceTable.

4. Изменить ссылки на таблицы дескрипторов в KeInitThread, PsConvertToGuiThread и других функциях.

5. Внести изменения в код диспетчера системных вызовов.

6. Внести изменения в код функции-обработчика.

Ни один из рассмотренных автором продуктов не обнаруживал автоматически все эти варианты.

Подмена указателя в KiServiceTable

Это наиболее распространённый способ, используемый руткитами, HIPS, антивирусами и межсетевыми экранами. Сначала следует проверить адреса таблиц:

Их можно восстановить так:

Команда dps позволяет просмотреть адреса обработчиков и символы. В исследованной системе драйвер aprtgsbrlm перехватывал следующие вызовы:

Для восстановления NtCreateFile в Windows XP используется её индекс 25h:

Подмена MSR-регистров

Корректные значения восстанавливаются командами:

Этот способ применим к Windows XP и новее. В Windows 2000 переход выполняется через int 2e; поскольку WinDbg не даёт простого способа править IDT, начало вредоносного обработчика можно заменить переходом на KiSystemService.

Подмена KTHREAD::ServiceTable

Для проверки всех потоков удобно использовать следующий сценарий WinDbg:

Сценарий выводит ServiceTable всех системных потоков и предупреждает, если поле не указывает на обычный или Shadow-дескриптор. После обнаружения остаётся проанализировать принадлежащую руткиту копию таблицы и снять перехваты. Такая подмена почти всегда сопровождается другими перехватами, поэтому следует особенно тщательно проверить нотификаторы и механизмы из следующих разделов.

Рис. 6. Поиск модификаций указателя KTHREAD::ServiceTable с помощью сценария.

Модификация ссылок на KeServiceDescriptorTable

Руткит может создать копии KeServiceDescriptorTable и KeServiceDescriptorTableShadow, а затем исправить ссылки на них в коде ядра, используя таблицу базовых поправок. Для проверки достаточно исследовать прежде всего KeInitThread и PsConvertToGuiThread; полный список ссылок можно получить в IDA.

Рис. 7. IDA нашла ссылки на KeServiceDescriptorTable.

Для автоматизированного поиска и исправления таких изменений в materials.rar (файл есть в nobunkum_ru_files.zip) приведён драйвер drivers/sdt_xref_unhook. Для загрузки драйверов удобна утилита KmdManager из комплекта KmdKit от Four-F.

Рис. 8. Загрузка драйвера с помощью KmdManager.

Руткит может подменить и образ ядра, читаемый с диска, поэтому наиболее достоверной остаётся ручная проверка с помощью отладчика.

Сплайсинг кода диспетчера и обработчиков

Сплайсинг основан на изменении машинного кода. Популярные цели в диспетчере — nt!KiFastCallEntry и отсутствующая в символах метка KiSystemServiceRepeat, хотя изменён может быть и другой участок. В Nt*-обработчиках перехват обычно ставится в начале функции: это может быть jmp или целый блок инструкций, передающий управление обработчику руткита.

Изменения проще всего обнаружить сравнением кода в памяти с образом ядра на диске. В materials.rar (файл есть в nobunkum_ru_files.zip) приведён драйвер drivers/spl_detect, который выводит найденные различия.

Рис. 9. Поиск модификаций кода ядра.

Не каждое различие означает активность руткита: ядро само модифицирует некоторые свои участки (self-patching). Типичные примеры:

На рис. 9 патч nt!KiDispatchInterrupt+0x22a соответствует KeFlushCurrentTb, а nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xc12 — KiSystemCallExitBranch.

Файловая система

Перехват системных вызовов позволяет скрывать файлы руткита и блокировать доступ к ним, но для этого применяются и другие способы. Файловая подсистема тесно связана с подсистемой ввода-вывода и имеет модульно-иерархическую структуру:

• драйверы устройств управляют портами, шинами и накопителями; большинство из них — PnP-драйверы;

• драйверы томов управляют разделами устройств хранения, создавая PDO, а после монтирования файловой системы — VDO;

• драйверы файловых систем реализуют FAT32, NTFS, CDFS и другие форматы, создают CDO и VDO и обрабатывают файловые IRP-запросы.

Совокупность этих компонентов образует стек драйверов устройств хранения, взаимодействие которого обеспечивает диспетчер ввода-вывода.

Рис. 10. Условная схема взаимодействия драйверов хранения информации.

При вызове NtCreateFile, NtWriteFile, NtQueryDirectoryFile и других файловых функций диспетчер ввода-вывода создаёт IRP и отправляет его драйверу файловой системы. Тот разбирает файловую таблицу либо переводит смещение в файле в смещение тома и передаёт запрос ниже. В итоге драйвер класса диска инициирует секторный ввод-вывод, поддерживаемый порт- и минипорт-драйверами. Стандартные примеры порт-драйверов Windows — Scsiport.sys и Atapi.sys.

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

1. Присоединение устройства-фильтра к целевому устройству.

2. Подмена указателей на IRP- или Fast IO-обработчики в объекте драйвера.

3. Сплайсинг кода этих обработчиков.

Устройства-фильтры

Присоединённые устройства образуют односвязный device stack по полю AttachedDevice структуры DEVICE_OBJECT. IoCallDriver вызывает обработчик верхнего устройства; фильтр может завершить IRP через IoCompleteRequest либо передать его ниже с помощью IoSkipCurrentIrpStackLocation и IoCallDriver.

Сначала получим устройства NTFS:

Затем просмотрим их стеки:

Безымянное устройство 818f8030 — VDO, а 81749030 — присоединённый фильтр руткита. Перед отсоединением необходимо убедиться, что CurrentIrp равен нулю и очередь не занята:

Если IRP активен, следует возобновить систему по F5 и повторить проверку после завершения ввода-вывода. Фильтр или цепочка фильтров отсоединяется обнулением AttachedDevice:

Минифильтр-драйверы файловой системы

К VDO реальной системы почти всегда присоединено устройство fltMgr.sys. Этот драйвер реализует API FltXxx для минифильтров файловой системы, которым может воспользоваться и руткит. Для отключения всех минифильтров достаточно отсоединить устройство fltMgr.sys от VDO; обычно это безопасно, хотя временно может перестать работать служба восстановления системы.[^4]

Подмена указателей на IRP-обработчики

При инициализации драйвер заполняет массив MajorFunction структуры DRIVER_OBJECT. Его размер равен IRP_MJ_MAXIMUM_FUNCTION + 1, где константа имеет значение 27.

Руткит может заменить указатели своими функциями, модифицировать буферы IRP либо завершать нежелательные запросы. Таблица обработчиков выводится командой !drvobj с флагом 2:

Подозрительны адреса без корректного символа либо указывающие не в сам драйвер или ядро. Здесь перехвачены IRP_MJ_CREATE и IRP_MJ_DIRECTORY_CONTROL.

Восстановление двух указателей:

0x00 и 0x0c — номера IRP_MJ_CREATE и IRP_MJ_DIRECTORY_CONTROL. Если символов нет, оригинальные адреса можно найти дизассемблированием файла драйвера: заполнение MajorFunction обычно расположено рядом с IoCreateDevice и точкой входа. Следует учитывать, что одноразовый инициализационный код часто находится в discardable-секции и выгружается после запуска драйвера.

Другие способы перехвата IRP

Функции IofCallDriver и IofCompleteRequest являются заглушками, переходящими по глобальным указателям:

В чистой системе они указывают на fastcall-функции IopfCallDriver и IopfCompleteRequest; начальную установку выполняет IopSetIoRoutines из IoInitSystem. Подмена этих указателей безопаснее сплайсинга, позволяет контролировать все IRP и не обнаруживается многими антируткитами, ищущими только изменения кода. Восстановление:

Объекты, типы объектов и их дескрипторы

В архитектуре NT ресурсы представлены объектами ядра, которыми управляет диспетчер объектов. Руткит может перехватывать функции Ob* или применять более сложные методы.

Объект состоит из заголовка OBJECT_HEADER и тела. Важнейшее поле заголовка — тип, то есть указатель на OBJECT_TYPE. Сам тип тоже является объектом типа «тип», а OBJECT_TYPE — его телом. Обычно программы обращаются к объектам через системные сервисы и связанные с ними дескрипторы (HANDLE). Объекты типов представлены в каталоге \ObjectTypes диспетчера объектов.

Вложенная в OBJECT_TYPE структура OBJECT_TYPE_INITIALIZER содержит характеристики типа и указатели на методы объекта:

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

1. Непосредственно заменить указатель на функцию метода.

2. Подменить указатель на тип в заголовке существующего объекта.

Список методов всех типов выводит драйвер drivers/ob_check_functions из materials.rar (файл есть в nobunkum_ru_files.zip).

Во втором варианте руткит получает целевой объект, создаёт копию его OBJECT_TYPE с изменённым методом и помещает адрес копии в OBJECT_HEADER::Type. Оригинальные структуры типов остаются нетронутыми. Для обнаружения можно перечислить объекты через ZwQuerySystemInformation(SystemObjectInformation) и проверить их Type.

Такой учёт объектов ведётся, только если в GlobalFlag включён FLG_MAINTAIN_OBJECT_TYPELIST (0x4000). Флаг устанавливается gflags.exe из Debugging Tools for Windows либо параметром GlobalFlag типа REG_DWORD в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager; после изменения требуется перезагрузка.

Рис. 11. Утилита gflags.exe.

Драйвер drivers/ob_check_objects из materials.rar (файл есть в nobunkum_ru_files.zip) проверяет поле Type. Руткит теоретически может обойти такую проверку, перехватив ZwQuerySystemInformation или исключив объект из списка типа. Поэтому качественный антируткит должен самостоятельно искать заголовки объектов в неподкачиваемом пуле.

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

Иногда недостаточно снять перехват: руткит может контролировать его состояние и устанавливать заново, а также восстанавливать удалённые файлы и значения реестра. Обычно это делает отдельный поток процесса System, созданный через PsCreateSystemThread либо IoAllocateWorkItem/IoQueueWorkItem, который выполняет восстановление в цикле.

Нужный поток находят, перечисляя потоки System и проверяя их стеки на адреса из драйвера руткита. В примере Rootkit.Win32.TDSS подозрительный поток виден так:

Адреса f7a094a5, f7a098e0 и f7a0b502 принадлежат руткиту. Завершать такой поток предпочтительно через отладчик, хотя штатный WinDbg при удалённой отладке не предоставляет отдельной команды. Метод состоит из четырёх шагов:

1. В стеке найти первый адрес возврата из драйвера руткита.

2. Записать по этому адресу вызов PspExitThread.

3. Обнулить ETHREAD::ActiveExWorker.

4. Возобновить систему по F5.

Тогда поток, вернувшись по изменённому адресу, завершит сам себя:

Послесловие

WinDbg позволяет надёжно выявлять аномалии работающей ОС: при удалённой отладке исследуемые компоненты не участвуют в сборе и обработке данных и не могут их исказить. Руткит теоретически способен мешать отладчику, но тогда компрометация становится очевидной. Современные вредоносные программы могут обнаруживать удалённую отладку, однако такие проверки обходятся. Существенный недостаток WinDbg — слабый встроенный язык сценариев; его можно компенсировать интеграцией Python или Perl.

Список литературы

1. Руководство по настройке канала связи между виртуальной машиной и отладчиком

2. Офлайн-документация WinDbg: команды as и ad.

3. Таблица номеров системных вызовов для разных версий Windows

4. MSDN: FltXxx (Minifilter Driver) Routines

Приложение

materials.rar (файл есть в nobunkum_ru_files.zip)

Последнее обновление: 17.03.2012.

[^4]: См. список литературы, источник 4.

Возникает вопрос: можно ли считать указанные проблемы именно проблемами реализации протокола, если один из пунктов — проблема пользовательского интерфейса, а другой — фундаментальное свойство протокола? С точки зрения пользователя, все перечисленные проблемы возникают во время использования протокола HTTPS в веб-браузере. Именно это и обусловило выбор такой, возможно, не совсем корректной формулировки.

В тексте статьи применительно к криптографическому транспорту протокола HTTPS будет применяться термин SSL, а не TLS, так как стандарт TLS содержит некоторые расширения, использование которых мы не рассматриваем. В рамках данной статьи отличия TLS, используемого в протоколе HTTPS, от SSL версии 3.0 не имеют значения: оба могут применяться с одинаковым результатом.

Технологии проксирования SSL

Широкие возможности по решению перечисленных проблем реализации HTTPS предоставляют технологии проксирования.

Проксирующие приложения, реализующие инспекцию SSL с помощью метода «человек посередине», на настоящий момент распространены довольно широко. Однако все они специализируются на анализе содержимого защищенного трафика (то есть решают только четвертую проблему из вышеприведенного списка) и не предоставляют дополнительных функций по управлению сертификатами.

В определенном смысле можно считать, что любое «вмешательство» в функционирование протокола SSL является нарушением его идеологии как протокола, обеспечивающего конфиденциальность, целостность и взаимную аутентификацию в режиме точка-точка. Однако в реальности, в последние годы требования к протоколу HTTPS изменились — подобно тому, как применение протокола HTTP значительно переросло уровень пятнадцатилетней давности, когда он использовался только для передачи несложных веб-страниц. Если в 1995 году пользователь отправлял через HTTPS только свой номер кредитной карточки, и задачи протокола сводились к защите данных от перехвата, — то сейчас через HTTPS проходит трафик постоянно используемых приложений с комплексной архитектурой (таких как Gmail). Поэтому необходимо позаботиться не только о защите конфиденциальных данных, но и о том, чтобы пользователь не подцепил вирусов через интерфейс веб-приложения и продолжал получать адекватную защиту от других угроз.

Алгоритм работы прокси-сервера, реализованного по методу «человек посередине», достаточно прост:

1. Прокси-сервер принимает TCP-соединение от клиента и получает команду на установление соединения с сервером.

2. Прокси-сервер устанавливает TCP-соединение с сервером и начинает SSL-сеанс.

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

4. Прокси-сервер начинает SSL-сеанс с клиентом, используя для этого новый сертификат.

5. Прокси-сервер принимает HTTP-запрос от клиента, передает его механизму инспекции содержимого и, при отсутствии ошибок и нарушений политики безопасности, передает HTTP-серверу.

6. Прокси-сервер получает ответ от HTTP-сервера, передает его механизму инспекции содержимого и, при отсутствии ошибок и нарушений политики безопасности, передает клиенту.

Далее мы рассмотрим более подробно проблемы реализации HTTPS, перечисленные в предыдущем разделе, и возможности для их решения посредством технологий SSL-проксирования.

Анализ проблем протокола HTTPS Пользовательский интерфейс управления сертификатами

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

Если в рамках интранет-решений мы можем более или менее успешно контролировать все аспекты реализации и внедрения протокола HTTPS, то в «большом грязном интернете» многое не только устроено не так, как нам хотелось бы, но и недоступно нашему влиянию. Так, по различным оценкам, от половины до двух третей сайтов, использующих протокол HTTPS, делают это не вполне корректно: при посещении таких сайтов возникают предупреждения браузера об ошибках [1]. При этом с практической точки зрения интересны два момента: во-первых, эти ошибки почти бесполезны — пользователи их игнорируют [2]. Во-вторых, есть как минимум один распространенный случай, когда мы можем позаботиться о пользователе за него.

Для начала вернемся от реализации к собственно задаче — подтверждению аутентичности сайта посредством сертификации. На деле это две совершенно разных задачи:

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

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

По-видимому, с точки зрения разработчиков браузеров, подобные нюансы не имеют значения: на все случаи жизни выдаётся довольно однообразного вида ошибка, которую, как было указано выше, пользователи склонны игнорировать.

Рисунок 1. Ошибка сертификата в окне браузера Firefox 3

Приведенный на рис. 1 пример представляет ещё не самый худший вариант отображения ошибки сертификата веб-браузером. К примеру, в Google Chrome вообще нет возможности добавить постоянное исключение для подобных ошибок. Учитывая то, что они встречаются достаточно часто, а также то, что пользователи склонны тем меньше обращать внимание на предупреждения, чем их больше, — налицо проблема информационной безопасности.

Такое решение, как нетрудно понять, подстрахует пользователя от автоматического игнорирования ошибки, опасного с точки зрения его безопасности. В исключительном случае пользователь может обратиться к администратору, который в свою очередь примет квалифицированное решение об исправлении ошибочного сертификата, уведомлении владельца ресурса об ошибке, расследовании инцидента в случае реально происшедшей атаки типа «человек посередине», либо — в последнюю очередь — о внесении правила-исключения в настройки межсетевого экрана.

(картинка не сохранилась в архиве)

Рисунок 2. Выдача клиентом SSH предупреждения об изменившемся сертификате

Подобная функциональность уже реализована в клиентах SSH. Для предупреждения об изменении веб-сертификатов ничто не мешает реализовать аналогичное поведение средствами технологии проксирования SSL. Единственную сложность при этом представляет необходимость реализации пользовательского интерфейса управления сертификатами, так как легитимные сертификаты тоже иногда меняются. Так как прокси-сервер является компонентом более сложной системы, встраивать такой механизм именно в прокси-сервер нецелесообразно.

Уязвимости в реализации и конфигурации протокола и прикладных библиотек

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

Например, эффективная защита от уязвимости большей части прикладных библиотек для работы с сертификатами, продемонстрированной в июле 2009 года исследователями Kaminsky и Marlinspike [3], реализуется простейшей проверкой всего лишь в несколько строк программного кода. Более того, эта проверка оказывается достаточно универсальной и, предположительно, будет эффективна также против других возможных ошибок парсера ASN.1, которые могли бы создать разночтения в длине интерпретируемых данных.

Еще проще при помощи SSL-прокси контролируются такие потенциальные угрозы безопасности, как:

• устаревшие версии протокола SSL [4];

• криптографически нестойкие хэш-функции в подписях сертификатов [5];

• использование криптографически нестойких алгоритмов шифрования.

Следует, впрочем, отметить, что это решение — не панацея: так, обнаруженная в конце 2009 года атака на пересогласование TLS-сеанса принципиально необнаружима [6] со стороны клиента. Главная задача SSL-прокси, как и других технологий межсетевого экранирования, заключается в создании единой точки контроля, не заменяющей, а дополняющей управление конфигурацией и изменениями.

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

Расширения X509v3 и автоматическая валидация сертификатов

Расширения X509 версии 3 хорошо известны любому, кто занимался построением сервисной архитектуры информационных систем, развертыванием больших виртуальных частных сетей и, наверное, любыми другими сложными случаями внедрения PKI, кроме, собственно, веб-сервисов. Такой странный «перекос» обусловлен удивительным фактом: веб-браузеры не имеют полноценной поддержки этого общепринятого и уже далеко не нового (IETF RFC2459, 1999 год [7]) стандарта! Фактически поддержка PKI в браузерах ограничивается довольно ненадежной реализацией протокола OCSP, проверкой разрешенных целей использования сертификата удостоверяющего центра (Basic Constraints), альтернативных имен и практически нефункциональным (а именно настраиваемым вручную и пригодным только для интранета) механизмом использования списков отозванных сертификатов (CRL). Валидация сертификатов в рамках протокола SSL/TLS производится согласно представляемой сервером фиксированной «цепочке доверия», чего зачастую недостаточно.

Рассмотрим ситуацию более подробно на примере произвольно взятого «в дикой природе» сертификата, в котором присутствуют интересующие нас расширения.

Этот сертификат принадлежит сервису Яндекс.Деньги. Остановимся подробнее на интересующих нас расширениях.

• Authority Key Identifier (AKID). Этот идентификатор указывает, каким сертификатом подписан рассматриваемый нами сертификат. Механизм аналогичен поиску сертификата, поле Subject которого соответствует полю Issuer данного сертификата.

Почему именно этот способ поиска удостоверяющего сертификата рекомендуется в настоящее время? Тому есть несколько причин. Во-первых, в случае перевыпуска сертификата AKID однозначно идентифицирует искомый публичный ключ, поэтому исключена путаница между «старым» и «новым» сертификатами с одинаковым полем Subject. А во-вторых, современный стандарт PKI предполагает специальное использование сертификатов, имеющих одинаковую ключевую информацию, но разные информационные поля, для установления сложных взаимоотношений доверия между иерархиями сертификации. Поэтому важно, чтобы мы могли идентифицировать сертификат именно по ключу и выбирать подходящий из нескольких вариантов [8].

• CRL distribution points. Это URL, по которому можно получить список отозванных сертификатов, в данном случае — по протоколу HTTP.

CRL через HTTP — весьма медленный способ уведомления об отзыве сертификатов: типовое время обновления составляет несколько часов. Объем «списка отзыва» может быть значительным, до десятков и сотен килобайт. Поэтому веб-браузеры обращаются только к тем спискам, использование которых было указано явно в пользовательских настройках.

• Authority Information Access (AIA). В этом расширении указывается, где можно получить информацию об издателе сертификата.

Вместо этого механизма, как уже упоминалось, веб-приложения либо используют предварительно построенные «цепочки доверия», полученные при установлении связи по протоколу SSL/TLS, либо полагаются на то, что все необходимые дополнительные сертификаты уже есть в хранилище браузера.

Какие преимущества дает использование SSL-прокси применительно к проблеме поддержки расширений X509v3? Мы можем подключить готовую библиотеку валидации сертификатов (в нашем случае был использован Carillon Pathfinder) и, таким образом, реализовать следующие функции, отсутствующие в веб-браузере:

• корректную валидацию согласно RFC5280 [8] с использованием информации AKID;

• кэширование с целью экономии трафика и использование CRL;

• автоматическое получение недостающих сертификатов промежуточных удостоверяющих центров с помощью AIA;

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

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

Общие проблемы PKI в «большом плохом интернете»

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

При этом, чтобы скомпрометировать систему, не обязательно вмешательство злоумышленника в функционирование удостоверяющего центра. Достаточно, чтобы слабым звеном в цепочке доверия оказался, например, криптографически нестойкий хэш-алгоритм, что, увы, является не теоретической, а вполне практической угрозой. Еще в 2009 году некоторые корневые удостоверяющие центры продолжали использовать устаревший алгоритм MD5, а если и прекращали, то оставалось большое количество неотозванных MD5-сертификатов. Поэтому специальное внимание при разработке нашего решения для SSL-проксирования было уделено исключению подобных слабых звеньев. Для снижения подобных рисков также может использоваться упомянутый выше параметр расширения Basic Constraints, ограничивающий возможную длину цепочки сертификатов для конкретного удостоверяющего центра. С другой стороны, распространены случаи «ложной тревоги», когда слабый алгоритм использовался для самоподписи корневого сертификата, что само по себе не представляет угрозу безопасности.

Также в «большом плохом интернете» используется значительное количество не вполне корректно сформированных с точки зрения X509v3 сертификатов. Это обычно не представляет проблемы, так как веб-браузеры не содержат функциональности, на которую эта некорректность могла бы повлиять.

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

Show Me The Code: SSL Proxy

Автором был разработан прокси-сервер для SSL. Продукт SSL Proxy существует в двух вариантах:

1. Бесплатный пакет с исходным кодом (open source). Распространяется в рамках проекта OpenFWTK в виде компонента http-gw, под лицензией «Old BSD with advertisement clause».

2. Коммерческий встраиваемый компонент для межсетевых экранов и DLP-систем.

В состав программы входит ПО Carillon Pathfinder, распространяемое под лицензией GNU LGPL.

Особенности реализации и внедрения

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

• самоподписанные сертификаты остаются таковыми. Для них лишь создается новый ключ, и возможен контроль непредусмотренной подмены;

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

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

• сертификаты, подписанные неизвестными удостоверяющими центрами, содержат в поле Issuer строку UNVERIFIED, что позволяет веб-браузеру выдавать диагностику, аналогичную той, которую можно получить при «прямом» подключении;

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

Инспекция содержимого для протокола HTTPS

Это базовая функциональность, ради которой, в основном, и были написаны все существующие реализации технологии проксирования SSL: инспекция содержимого защищенного трафика по принципу «человек посередине». Прикладные особенности реализации данной технологии в программе SSL Proxy заключаются прежде всего в использовании интерфейса к дешифрованной сессии, доступного непосредственно для механизма инспекции контента: DLP, антивируса, системы ведения архива и т. п. На настоящий момент наиболее широко распространенным стандартом на такой интерфейс является протокол i-cap (Internet Content Adaptation Protocol [9]) — он и был использован в рассматриваемом продукте.

Выводы

Мы рассмотрели актуальные проблемы и угрозы безопасности, возникающие при использовании протокола HTTPS, и возможность их решения при помощи технологии SSL-проксирования. Как показано в данной статье, использование проксирующего SSL-сервера отлично себя оправдывает, повышая уровень защищенности браузера без создания дополнительных неудобств для пользователя. Возможно, в скором времени эволюция веб-браузеров позволит им решать поднятые в данной статье проблемы встроенными средствами — и тем не менее заслуженное место для HTTPS-прокси в системе обеспечения сетевой безопасности всегда найдется.

Список ссылок

1. Researcher: Poor SSL Implementations Leave Many Sites At Risk. DarkReading.com.

2. J. Sunshine, S. Egelman et al. sunshine.pdf (файл не сохранился в интернете).

3. M. Marlinspike. BHUSA09-Marlinspike-DefeatSSL-PAPER1.pdf (файл не сохранился в интернете).

4. 56387: SSLv2 Protocol Multiple Weaknesses. OSVDB.org.

5. A. Sotirov, M. Stevens et al. MD5 considered harmful today: Creating a rogue CA certificate.

6. T. Zoller. practicaltls.pdf (файл не сохранился в интернете).

7. RFC2459. Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

8. RFC5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

9. RFC3507. Internet Content Adaptation Protocol (ICAP).

Последнее обновление: 17.03.2012.

Анализ кода в полиморфных объектах обычно затруднён большим количеством инструкций, передающих управление на другие участки кода. Зачастую «ненужные» инструкции запутывают код настолько, что понять его логику можно, только разработав специальный анализатор кода. В задачи такого анализатора может входить выяснение размера и смещения зашифрованных данных, поиск ключа для их расшифровки, определение адреса перехода на изначальную точку входа и другие функции.

Типичный вопрос, встающий перед разработчиком анализатора кода, — «Поддержку каких инструкций необходимо добавить?» Можно выяснить это с помощью дизассемблера IDA Pro, но запускать такое мощное средство анализа кода только, чтобы увидеть одну-две инструкции, было бы нерациональным. Куда быстрее ту же задачу можно решить с помощью Hiew.

Совет от разработчика Hiew

Евгений Сусликов

sen@kemtel.ru

Некоторое время назад я прочитал статью «Коварный и ужасный sndrec32.exe». По моему мнению, вместо описанного там применения четырёх различных инструментов достаточно одного Hiew. Вся правка «коварного и ужасного» сводится к следующему:

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

F4, F3 — переключение в режим дизассемблера.

F8, F7 — просмотр функций импорта.

F9, *memory* — поиск имён по маске.

Последний шаг делается в предположении, что искомая функция будет содержать слово «memory» в имени. Оказывается, всего одна импортируемая функция соответствует такому фильтру — GlobalMemoryStatus.

2. Найти вызовы данной функции в коде. Для этого достаточно нажать Enter. Ctrl-Enter позволяет найти следующий вызов. На интересные фрагменты кода можно сделать закладки с помощью клавиши + на цифровой клавиатуре. В нашем случае второй и третий вызовы по адресам .10077AC и .100789A почти идентичны.

3. Исправить код. Клавишами Alt-1 вернёмся к первой закладке, прочтём код и примем решение заменить знаковый переход jle на беззнаковый jbe по адресу .10077D5. В строке по этому адресу нажмём F3 для редактирования и F2 для ввода ассемблерного кода, затем вместо «jle» введём «jbe» и нажмём Enter. После этого нажатием Esc выйдем из ассемблера и сохраним изменения клавишей F9.

Заметим, что автор оригинальной статьи не упомянул о коде на адресе .100789A. Перейдя на вторую закладку клавишами Alt-2, обнаружим там аналогичную ошибку и исправим её.

Многие вирусные аналитики назначают Hiew в качестве альтернативного средства просмотра (Alt-F3) в настройках менеджера файлов. Автор статьи рекомендует сэкономить ещё один шаг и добавить к команде запуска Hiew параметр /Oc=OEP, чтобы просмотр исполнимых файлов всегда начинался с точки входа. Если же задать в файле hiew8.ini настройку StartMode = Hex, то режимом просмотра по умолчанию станет шестнадцатеричный.

К точке входа можно перейти в любой момент, нажав последовательно F8 и F5.

Удобная возможность Hiew — следовать по смещениям, указанным в инструкциях передачи управления, например, call или jmp. Справа от каждой такой инструкции редактор показывает цифру, нажав которую на клавиатуре, можно перейти по указанному в инструкции смещению. Вернуться назад после такого перехода можно, нажав клавишу 0. (Автор находит более удобным использовать для этой цели клавишу z, для чего в файле hiew8.ini следует задать настройку JumpTable = "z123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ").

Иногда оказывается полезной возможность перенастройки шкалы смещений Hiew путём сопоставления её нулевой точки с адресом произвольной инструкции. Для этого необходимо, установив указатель на нужный адрес, дважды нажать Ctrl-F5. При этом новая настройка шкалы сохраняется в виде соответствующей записи в окне, отображаемом при однократном нажатии Ctrl-F5, и может быть использована повторно. Перенастройка шкалы может быть полезна для оценки размера зашифрованных данных, а также для повышения наглядности адресов переходов типа call и jmp, отсчитываемых в режиме адресации Local (Alt-F1) от «нуля» шкалы.

Расшифровка данных

Несложные скрипты для расшифровки данных можно разрабатывать и применять непосредственно в Hiew, экономя время на запуск отладчика.

Разберём для примера известный crackme/keygenme от Ms-Rem, в котором проверка производится байт-кодом в виртуальной машине. Рассмотрим начало байт-кода программы:

Байт-код

Код функции, декодирующей очередную инструкцию виртуальной машины, выглядит так:

Чтобы расшифровать данные с помощью Hiew, следует прежде всего выделить блок зашифрованных данных клавишей * и нажать Alt-F3 (CryBlk). Затем в окне редактирования кода напишем код расшифровки, аналогичный вышеприведённому. Hiew поддерживает выполнение ограниченного набора инструкций, список которых приведён в разделе «Crypt commands» справочного файла. С учётом ограничений код будет выглядеть так:

Нажав F7 после редактирования кода, получим расшифрованные данные.

Расшифрованный байт-код

При необходимости сохранить скрипт расшифровки в файл можно вернуться в редактор нажатием Alt-F3, после чего нажать F9.

Нередко возникает необходимость в расшифровке данных, зашифрованных по алгоритму XOR с длинным ключом. В таком случае можно воспользоваться встроенной возможностью Hiew по расшифровке: перейти в режим правки клавишей F3 в режимах Code или Hex, нажать F8 и задать ключ шифрования. Установить новый ключ можно клавишами Ctrl-F8.

Восстановление обнулённых дескрипторов секций

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

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

Возьмем вредоносную программу, упакованную таким полиморфным упаковщиком, и увидим после снятия дампа следующее:

Обнулённые дескрипторы секций

Чтобы восстановить дескрипторы секций, прежде всего скопируем их из оригинального, упакованного файла. Для этого откроем этот файл, выделим начало и конец области дескрипторов клавишей *, а затем запишем выделенные байты в файл с дампом памяти, нажав F2 и указав имя файла и смещение (1e8).

Выделенные дескрипторы в оригинальном файле

Затем, открыв файл с дампом, исправим смещения, указанные в дескрипторах (F8, F6). Нажатие F3 позволяет начать редактирование выбранного дескриптора, а F9 — принять сделанные изменения.

Редактирование дескриптора секции

Статическая распаковка файла

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

Для примера рассмотрим образец test.bin из приложения к статье. Он упакован простейшим полиморфным упаковщиком, предназначенным для сокрытия вредоносного кода от обнаружения.

Открыв файл для анализа в Hiew и пройдя несколько переходов, мы увидим характерный код для доступа к данным, расшифровки и перехода на OEP:

Для распаковки достаточно сложить адрес следующей инструкции после call (10007044) и значение в инструкции add (0FFFFFF70). Сложение можно выполнить непосредственно в Hiew, нажав Alt-=. Зашифрованные данные, находящиеся по вычисленному адресу, удобнее всего представить как массив двойных слов (DWORD). Для этого следует нажать Shift-F9 и при необходимости выбрать режим показа двойных слов клавишей Tab.

Массив двойных слов

Нетрудно видеть, что для распаковки первого объекта нужно вычислить его адрес (для этого сложим смещение 10006FB8 с величиной FFFFA048), запомнить размер объекта (17ED) и применить ключ расшифровки (0E902ECDE).

Заметим, что, если в массиве двойных слов окажется значение, похожее на RVA (Relative Virtual Address), перейти по нему можно клавишей Enter.

Обнаружение вредоносных программ

Чтобы разработать метод обнаружения вредоносного кода по сигнатуре, нужно найти в нём пригодные для этого уникальные черты.

В начале файлов tukuhegu.dll и welolazu.dll (см. приложение к статье) можно увидеть такие участки:

Переход посредством установки SEH-обработчика

*Установка перехвата с помощью инструкции jmp*

Первый признак, пригодный для обнаружения, заключается в использования SEH-обработчика (Structured Exception Handling) с последующей его активацией путём сознательного вызова исключения. Это «трюк», практически никогда не встречающийся в легитимных программах. Во втором случае происходит запись значения 1DA79 по адресу 1001ED17+1. Затем — запись в память опкода инструкции jmp и смещения 1001ED17, что является типичным признаком процедуры перехвата функций. При наличии столь подозрительных инструкций не требуется понимания того, как именно работает код и что хранится по указанным смещениям: найденные инструкции могут быть использованы в качестве сигнатур для обнаружения данной программы антивирусом. С целью предварительной фильтрации файлов и уменьшения числа ложных срабатываний антивирус обычно выполняет дешёвые предварительные проверки перед поиском сигнатур, например, проверку на наличие у секции кода атрибута «writeable».

Возьмем еще один пример, на котором можно увидеть ошибки генератора кода в полиморфном движке. Для этого откроем в Hiew образец A0330534.bin:

Бессмысленная конструкция

Ещё одна бессмысленная конструкция

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

Рассмотрим более сложный случай: модуль трояна «Зевс» (файл zeus_hz0132.bin в приложении), полученный автором статьи по ссылке из спама. Образец интересен тем, что код распаковщика занимает всего 136 байт.

Распаковщик «Зевса»

Сразу после открытия файла в Hiew бросается в глаза переход на третью инструкцию с помощью инструкций push и ret, нехарактерный для современных компиляторов. Ещё одной особенностью является то, что код не использует результаты после вызовов GetCommandLineW и GetOEMCP. Начиная с инструкции lodsd, можно видеть цикл расшифровки и ключи шифрования. Просматривая код далее, заметим переход назад с достаточно большим смещением в участок расшифрованного кода, который, очевидно, является переходом на OEP. На этом анализ завершён, и можно быстро написать статический распаковщик.

Последнее обновление: 17.03.2012.

1. Судя по огромному количеству «воплей о помощи» от пользователей на публичных форумах, большинство антивирусов не справляются с лечением руткита, хотя успешно его обнаруживают [1].

2. В публичном доступе нет полноценного описания функционала TDSS.

3. Реализация TDSS интересна тем, что, являясь со всей очевидностью эффективной, она не задействует никаких изощренных техник «нового поколения» или «0-day».

4. TDSS активно распространяется в живой среде, развиваясь в мощный ботнет. По данным Лаборатории Касперского за март-апрель 2009 г., в базы ежедневно добавляется от 100 до 300 сигнатур для новых и модифицированных файлов руткита [2].

Таким образом, руткит TDSS — угроза пограничного типа: он достаточно мощный для поражения антивирусных программ, но недостаточно опасный для детального исследования; достаточно распространенный для публичных криков о помощи, но не дотягивает до эпидемии.

Обзор семейства

ТDSS известен своей выдающейся способностью обходить активную защиту (антивирус, HIPS, фаервол), сложноудаляемостью и rootkit-функционалом. Его типичные наблюдаемые признаки в системе — всплывающие окна (pop-up), а также проблемы с запуском и обновлением антивирусных продуктов. На практике может иметь место любой функционал, что обеспечивается динамической подгрузкой дополнительных модулей.

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

Сам по себе TDSS — не более чем мощный загрузчик (downloader) с модульной архитектурой. Его основная задача — проникнуть на машину пользователя в обход защиты, хорошо закрепиться в системе, и в дальнейшем обеспечивать удаленное управление ресурсами зараженной машины, включая загрузку дополнительных функциональных модулей.

Схема распространения TDSS не менее продуманна, чем его архитектура. Используется несколько каналов доставки вредоносного кода. Известные вектора атаки включают загрузку кода через web-эксплойт (iframe attack) [3], инсталляцию его под видом видео-кодека [4] для просмотра порнографии, а также распространение в связке с легитимными [5] и пиратскими программами, генераторами ключей и crack'ами [6].

Характерные особенности

• Настоящее название руткита TDSS — TDL. Более поздние образцы руткита называют себя TDL2.

• Файлы троянца защищены от анализа посредством несложной обфускации и шифрования.

• Некоторые файлы отмечены поддельным штампом версии, характерным для программ Microsoft.

• Основа механизма инсталляции TDSS — загрузка сервисом msiexec.exe (Microsoft Installer) своей собственной легитимной, но модифицированной DLL [7].

• После инсталляции руткит блокирует загрузку или обновление антивирусных программ.

• Руткит тщательно закрепляется в системе, препятствуя деинсталляции. Например, некоторые модификации работают в режиме Safe Mode — это достигается модификацией ключей реестра HKLM\SYSTEM\ControlSet001\Control\SafeBoot\Minimal и HKLM\SYSTEM\ControlSet001\Control\SafeBoot\Network.

• Руткит хранит свои настройки в реестре: список антивирусных модулей, которые необходимо блокировать, список собственных модулей, которые необходимо подгружать в адресное пространство браузера, и т. д.

• Руткит скрывает свои файлы и ключи посредством перехвата нескольких функций.

• Драйвер руткита открывает своим модулям окно в пространство ядра. Для этой цели используется вызов функции ZwFlushInstructionCache со специфическим набором аргументов.

Внутривидовое разнообразие

Первые версии руткита в 2008 г. создавали в системе драйвер tdsserv.sys, от которого и произошло официальное имя TDSS. Впоследствии имя основного драйвера несколько раз менялось на clbdriver.sys, seneka*.sys, UACd*.sys, gaopdx*.sys, tdlserv.sys и другие.

Первые версии руткита использовали патчинг библиотеки advapi32.dll, подгружаемой сервисом Microsoft Installer, в ходе инсталляции. Более новые версии используют патчинг библиотеки msi.dll. Возможно, это изменение — реакция на новые поведенческие сигнатуры систем защиты.

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

Новейшие образцы эволюции TDSS содержат функционал червя. В частности, руткит пытается — и, судя по отзывам жертв, вполне успешно — размножаться через съемные накопители. С этой целью копия руткита размещается в директории RECYCLER в виде скрытого файла с именем .com, и создается ссылка на него в файле autorun.inf. Это приводит к автоматической загрузке руткита при подключении зараженного накопителя к системе (за исключением случаев, когда функция Autorun для внешних дисков запрещена в настройках системы), а также при попытке открытия зараженного накопителя из «Проводника».

Анализ кода

Для анализа был использован экземпляр, обнаруженный примерно в марте 2009 г. (MD5: 1DE66FC07C7B5893F5F83B397AC38F3D) [8]. Разновидность TDSS, представленная этим экземпляром, отмечена российским филиалом лаборатории Symantec как одна из наиболее упоминаемых вредоносных программ в марте 2009 г. [9].

Общий алгоритм функционирования TDSS, характерный для семейства в целом, уже описан [10], так же как и основные механизмы компонентов руткита в ring3. Суммарный высокоуровневый обзор функционала конкретного файла можно найти поиском по MD5 в архиве любой публичной песочницы (например, ThreatExpert). Поэтому я опишу только самые важные механизмы и функционал уровня ядра.

Инсталляция руткита и обход защиты

Процедура инсталляции руткита достойна упоминания, поскольку обеспечивает эффективный обход поведенческих защит и фаерволов. Ключевая идея алгоритма обхода — исполнение вредоносного кода в составе модифицированной системной библиотеки, автоматически подгружаемой легитимным системным сервисом. В результате такой манипуляции фаервол пропускает сетевую активность вредоносного кода в силу того, что его процесс-источник — системный сервис Windows — по умолчанию внесен в «белый список» и, как следствие, обладает всеми возможными привилегиями для загрузки и инсталляции файлов. Большинство проактивных защит также пропускают поведенческую активность руткита, поскольку она не вписывается в типичные паттерны нежелательного поведения.

Технически этот алгоритм реализован следующим образом. Модификация системной библиотеки — advapi32.dll или, в более поздних версиях руткита, msi.dll — осуществляется в копии библиотеки на диске, которая затем загружается в директорию \KnownDLLs в памяти. После этого стандартными средствами запускается Microsoft Installer, который автоматически подгружает модифицированную библиотеку из \KnownDLLs [11].

В этой схеме модификация кода msi.dll минимальна, и обеспечивает только выполнение кода из секции \knowndlls\dll.dll, содержащей процедуры инсталляции руткита. Сам патч — <malicious_code_injection> — элегантен:

Функционал секции dll.dll отображен на рис. 1.

Рис. 1. Основная задача этой библиотеки — загрузка и инсталляция драйвера руткита.

Драйвер

TDSS не имеет собственного процесса в пользовательском пространстве. Базовые функции обеспечиваются драйвером, который автоматически загружается на старте. Дополнительные высокоуровневые функции обеспечиваются отдельными DLL-модулями, внедряемыми в заданные процессы.

Функционал драйвера включает в себя:

• сокрытие руткита;

• обеспечение «портала» в режим ядра;

• предотвращение загрузки антивирусов, перечисленных в конфигурационном ключе реестра;

• внедрение DLL-модулей в процессы, перечисленные в конфигурационном ключе;

• инсталляцию новых DLL-модулей.

Rootkit-функционал

Руткит перехватывает методом сплайсинга следующие функции в пространстве ядра:

• IofCallDriver;

• IofCompleteRequest;

• NtFlushInstructionCache;

• NtQueryVlaueKey;

• NtEnumerateKey.

Перехват NtEnumerateKey используется для сокрытия ключей реестра, отвечающих за загрузку и конфигурацию руткита (в данном случае это все ключи, начинающиеся со строки gaopdx*). Перехват NtQueryValueKey используется для подмены адресов DNS-серверов (значения DhcpNameServer и NameServer [12]) в реальном времени, без модификации реестра. Перехват IofCallDriver обеспечивает глобальную фильтрацию всех IRP в системе, что позволяет руткиту прятать свои файлы (начинающиеся со строки gaopdx*) всякий раз, когда он перехватывает IRP к драйверу файловой системы:

Перехват IofCompleteRequest обеспечивает схожий функционал.

Портал в пространство ядра

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

Набор команд, обрабатываемых перехватчиком NtFlushInstructionCache, очень ограничен и не позволяет управлять руткитом. Доступные команды обеспечивают передачу переменных из ядра в пользовательский модуль, остановку заданного процесса или потока из ядра (посредством внедрения соответствующей задачи в очередь APC-вызовов ядра) и запуск процедур инсталляции нового DLL-модуля.

Устойчивость в системе

Драйвер вызывает функцию ExQueueWorkItem для запуска нескольких потоков в ядре. Потоки зациклены с периодом меньше секунды. Таким образом обеспечивается постоянная перерегистрация драйвера в системе (\registry\machine\system\currentcontrolset\services\gaopdxserv.sys), отключение системного фаервола (\registry\machine\system\currentcontrolset\services\sharedaccess\parameters\firewallpolicy\) и другие функции.

Блокирование антивирусов

Драйвер руткита посредством PsSetLoadImageNotifyRoutine инсталлирует процедуру нотификации, получающую управление по факту загрузки любого модуля в память. Внутри процедуры происходит сверка имени загружаемого модуля со списком запрещенных, перечисленных в ключе disallowed настроек руткита в реестре. Загрузка запрещенных модулей блокируется.

Удаление TDSS вручную

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

1. В Device Manager (Компьютер → Управление устройствами), в разделе Non-PnP Driver, отключить и удалить драйвер руткита. Его можно локализовать по имени (tdsserv.sys, quadraserv.sys и т. д.). Поскольку полагаться на имя драйвера ненадежно — его лучше определить наверняка при помощи любого антируткита (GMER или Rootkit Unhooker предпочтительны; Avira Antirootkit также справляется с задачей). После этих манипуляций все файлы и ключи реестра руткита становятся видимыми и доступными для удаления вручную.

2. Удалить файл, соответствующий данному драйверу.

3. Удалить все ключи реестра, ссылающиеся на данный драйвер, и файлы дополнительных модулей, перечисленные в конфигурационном ключе.

4. Удалить (при их наличии) файлы autorun.inf и RECYCLER\*.com на всех дисках.

5. Перезагрузиться.

6. Использовать антивирус для окончательной очистки системы от возможных пропущенных файлов.

Шаги 1–4 должны выполняться без помощи антивирусов, поскольку в случае отсутствия сигнатуры к какому-либо файлу дезинфекция не будет успешной.

Выводы и заключение

• Эффективность TDSS демонстрирует, что для обхода систем защиты нет необходимости изобретать нетривиальные решения.

• Разработчики вредоносных программ продолжают находить способы решения своих задач, основанные на обращении особенностей защиты в ее уязвимости [13].

• Распространение вредоносной программы в связке с легитимной — очень эффективная техника, хотя и не новая. Идея этой техники заключается в том, что если пользователь добровольно запускает приложение, которое считает легитимным, — то он добровольно устранит всевозможные предупреждения от поведенческой защиты или UAC'а. Он также пропустит инсталляцию драйвера, поскольку для некоторых приложений (например, инсталлятора кодеков [5]) использование драйвера вполне ожидаемо. Кроме того, наличие видимого окна инсталлятора может ввести в заблуждение простую поведенческую защиту.

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

• Вызов функций NtOpenSection, NtMakeTemporaryObject и других API-интерфейсов к системным секциям.

• Получение доступа к системным библиотекам (даже если это простое копирование).

• Вызов LoadLibraryEx с параметром DONT_RESOLVE_DLL_REFERENCES (используется кодом dll.dll для восстановления кода msi.dll).

• Модификация системной конфигурации DNS и DHCP.

• Вызов PsSetLoadImageNotifyRoutine. Несмотря на высокую вероятность того, что к моменту вызова этой функции защита будет уже отключена, — это не дает достаточных оснований для того, чтобы отказаться от контроля.

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

Ссылки

1. Поиск Google, отзывы пользователей о TDSS на форумах.

2. Лаборатория Касперского, статистика по сигнатурам для TDSS.

3. Dancho Danchev, Embassy of India in Spain Serving Malware; Malware Analysis & Diagnostic, Etude de cas — Infection rootkit TDSS.

4. ThreatExpert, отчет о действиях программы с MD5=2c5c874235a73fc50a69780c7ad1488a.

5. ThreatExpert, отчет о действиях программы с MD5=d2ada2dba8e036d37726ebddbcc9e9d6.

6. ThreatExpert, отчет о действиях программы с MD5=b17d76537ef5d94547fc4ca8851b35da.

7. Symantec, Backdoor.Tidserv Technical Details.

8. Virustotal.com, отчет о сканировании программы с MD5=1de66fc07c7b5893f5f83b397ac38f3d.

9. Anti-malware.ru, История информационной безопасности за 4-ю неделю марта от Symantec.

10. F-Secure, Backdoor:W32/TDSS Virus Description.

11. Microsoft Support, INFO: Windows NT/2000/XP Uses KnownDLLs Registry Entry to Find DLLs.

12. MSDN, DhcpNameServer registry key.

13. Virus Bulletin, January 2009. Shevchenko A., AlisaShevchenko-Jan09.pdf (файл не сохранился в интернете).

Приложения

Экземпляр руткита TDSS и файлы анализа IDA — по запросу.

tdss_remover_latest.rar (файл не сохранился в интернете)

Последнее обновление: 17.03.2012.

Кроме того, при публикации этого материала мы преследовали еще одну цель: представить методологию расследования компьютерных преступлений. Данное исследование демонстрирует, как, имея на руках только инструмент злоумышленников (бинарный файл трояна), выйти на «цифровое ядро» киберформирования и проанализировать его. Следует заметить, что применяемый подход позволяет извлечь всю техническую информацию об инциденте, в то время как задача установления личностей атакующих и привлечения их к ответственности остаётся в сфере компетенции правоохранительных органов.

Партнёрская программа, «партнёрка» — веб-сервис по привлечению широкого круга веб-мастеров к распространению некоторого продукта за вознаграждение, обычно в виде доли от стоимости продукта.

Часть 1. Вскрытие

В последнее время в интернете возрождается популярность партнерских программ. Всё больше и больше крупных ботнетов, результаты исследования которых публикуются в русскоязычных и зарубежных источниках, оказываются связаны с той или иной партнёрской программой. Ботнет TDSS — возможно, самый крупный на сегодняшний день — не является исключением. Распространение вредоносной программы, обеспечивающей функционирование данного ботнета, осуществляется партнёрской программой «Dogma Millions».

Главная страница партнёрской программы dogmamillions.com

На сайте dogmamillions.com описаны правила работы с партнёрской программой и условия для партнёров. После регистрации партнёру доступен для загрузки бинарный файл руткита TDSS, подлежащий распространению любыми удобными способами за комиссионное вознаграждение.

Личный кабинет партнера на сайте партнерской программы

Целевая страница, или «лендинг» (от английского landing page), — веб-страница, на которую пользователь попадает в результате перехода по рекламной ссылке или направляется другими способами (например, путём открытия всплывающих окон).

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

Дополнительная учётная запись со ссылкой на загрузку исполняемого файла TDSS

Партнёрская программа

SQL injection — метод атаки на веб-сайт, который заключается во внедрении запросов SQL в легитимные данные, получаемые веб-сервером от посетителя сайта, и считывании полноценных ответов на запросы от СУБД.

Blind SQL injection — атака идентична SQL Injection за тем исключением, что атакующий вынужден действовать вслепую, методом прощупывания базы данных при помощи отдельных SQL-запросов, результат выполнения которых должен быть сведён к бинарному формату типа «истина/ложь».

На сервере партнёрской программы использовалась база данных MySQL версии 5. Все запросы к базе данных, описанные далее, будут соответствовать языку запросов MySQL.

Поиск уязвимостей в скриптах личного кабинета не принёс результата. Однако получить доступ к базе данных всё-таки удалось: вначале при помощи атаки Blind SQL injection, а затем и классической атаки SQL injection.

Для партнёров существует возможность создания дополнительных учетных записей (subaccounts). Последние используются для анализа эффективности использования разных видов веб-трафика с разными целевыми страницами. Например, одной дополнительной учетной записи может соответствовать троян, на загрузку которого будет направляться порно-трафик. Таким образом, данный троян скачает жертва, просматривающая сайты с порнографическим содержимым. К другой может быть привязан троян, загружаемый посетителями сайтов с «крэками». В результате раздельного сбора статистики партнёр может оценить, какой вид трафика лучше подходит для работы с данной партнёрской программой, принося максимум комиссионных.

Дополнительные учётные записи создаются при помощи HTTP-запроса типа GET:

После такого запроса в личном кабинете партнёра появится дополнительная учётная запись с идентификатором 1. Её можно удалить, указав её идентификатор в соответствующем GET-запросе:

Атака Blind SQL Injection заключалась в следующем. Необходимо было создать дополнительную учётную запись с любым произвольным идентификатором и затем попытаться его удалить. Параметр запроса delete был уязвим, поэтому возможно было провести атаку, отправив на сервер запрос следующего вида:

Если значение выражения ord(substring((version()),1,1)) больше 1, то условие if возвращает 1, и запрос упрощенно принимает следующий вид:

Если же условие ложно, то запрос будет иметь вид:

Таким образом, дополнительная учетная запись будет удалена только в том случае, если переданное в параметре delete условие истинно. На основе этих данных может быть проведена атака Blind SQL Injection.

Возможен и другой вариант атаки. Параметр create команды создания дополнительной учётной записи также уязвим. Запрос следующего вида приведет к созданию на сервере дополнительной учетной записи с идентификатором, равным значению выражения:

Таким образом, если версия базы данных на сервере выше 5, то первым символом строки, которую вернёт команда version(), будет «5». ASCII-код этого символа равен 53, поэтому в личном кабинете партнера появится дополнительная учётная запись с идентификатором 53.

*Часть таблиц с колонками из базы данных dogmamillions.com*

*Первые дополнительные учетные записи из таблицы affiliates базы данных dogmamillions.com*

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

Командные серверы

На момент проведения анализа командные серверы (C&C, command-and-control) ботнета TDSS располагались по следующим доменным именам и IP-адресам (фрагмент файла конфигурации руткита):

Управление ботнетом производится с трёх серверов, указанных в поле servers файла конфигурации. Именно их мы проверили на предмет уязвимостей в первую очередь.

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

1. формируется пакет данных;

2. этот пакет шифруется по алгоритму RC4, причём в качестве ключа используется IP-адрес либо доменное имя целевого сервера;

3. пакет данных дополнительно кодируется по алгоритму Base64;

4. данные отправляются на сервер.

Таким образом, псевдокод алгоритмов шифровки и дешифровки выглядит следующим образом:

Анализ данных, передаваемых ботом на сервер, выявил уязвимости, позволяющие произвести атаки Blind SQL injection и SQL Injection.

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

Сообщение об ошибке при неправильном запросе к серверу

После расшифровки строки по описанному выше алгоритму была получена команда следующего вида:

Точное назначение этой команды на этапе атаки было неясным. Однако в результате её анализа было установлено, что третий параметр в списке, разделенном символом вертикальной черты, является уязвимым.

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

В основу этого эксплойта положена команда, при успешном выполнении которой ответ от базы данных придет с задержкой на 3 секунды, тогда как при невыполнении задержки не произойдет. Это стандартный вариант реализации атаки Blind SQL injection с задержкой с тем исключением, что вместо функции benchmark() использована функция sleep(), так как последняя не создает нагрузки на СУБД.

База данных

Приступив к атаке, мы первым делом проверили, имеет ли текущий пользователь привилегию на чтение и запись данных на сервере (File_priv). Запрос, отправленный на сервер для этой цели, до шифрования выглядел следующим образом:

Результат работы эксплойта для Blind SQL Injection с задержкой

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

При истинном значении условия новая команда вместо задержки возвращает ошибку, а при ложном — завершается успешно.

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

Работа эксплойта без задержки

Скрипты

В результате анализа кода файла index.php и подключаемых им скриптов была найдена ещё одна уязвимость, которая существенно облегчала исследование благодаря возможности сведения атаки типа Blind SQL Injection к классической атаке SQL Injection. Рассмотрим код файлов index.php и modules.php:

*Часть скрипта index.php (многоточиями замещён опущенный код)*

*Уязвимый параметр в скрипте modules.php*

Как видно из последнего листинга, значение параметра $request[1] не проверяется перед использованием в коде скрипта. Для данной уязвимости был разработан эксплойт, позволявший выполнять чтение файлов и базы данных в 10 раз быстрее, чем предыдущий:

Данный запрос возвращает количество записей в таблице users в тексте сообщения об ошибке, возвращенном сервером.

Проверка эксплойта SQL Injection и ответ сервера на запрос

Таким образом, была получена возможность использовать атаку типа SQL Injection, что существенно упростило и ускорило изучение сервера.

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

«Чёрный ход»

На этапе внедрения скрипта для удалённого управления сервером возникло затруднение: а именно, все GET-запросы к серверу перенаправлялись на файл index.php. Таким образом, успешно разместив на сервере скрипт «чёрного хода», мы не могли к нему обратиться. Обойти это ограничение можно было путем модификации файла конфигурации веб-сервера.

Для поиска файла конфигурации был произведен опрос различных возможных путей к нему через уязвимость SQL Injection. В качестве инструмента для тестирования вариантов пути к файлу использовалась программа с открытым кодом wfuzz, слегка модифицированная для обеспечения шифровки данных перед их отправкой на сервер. В результате тестирования был найден файл конфигурации веб-сервера: /etc/lighttpd/lighttpd.conf.

*Содержимое файла lighttpd.conf*

Листинг файла конфигурации дает представление о том, что перенаправление запросов на index.php происходило с помощью модуля mod_rewrite, а настройки для виртуальных серверов подключались в отдельном скрипте на языке Perl. В указанном скрипте, в свою очередь, подключались файлы конфигурации с настройками для отдельных виртуальных серверов, имена которых получались путем перечисления файлов в заданной директории. Таким образом, путь к нужному нам для обхода перенаправления файлу был по-прежнему неизвестен.

Для файла с настройками перенаправления был составлен и протестирован объемный список, содержащий доменные имена и IP-адреса, входящие и входившие в ботнет TDSS.

Часть списка возможных путей к файлам конфигурации

Однако желаемый результат был достигнут лишь в результате интеллектуального перебора возможных путей вручную. Итак, был найден файл конфигурации целевого виртуального сервера: /etc/lighttpd/sites-enabled/engine.conf.

*Часть файла engine.conf*

Файл конфигурации содержал настройки для шести серверов, только для двух из которых были созданы правила перенаправления HTTP-запросов на файл index.php. Для остальных серверов осуществлялось перенаправление HTTPS-запросов на скрипт MakeBuild.php.

Анализ скрипта MakeBuild.php с помощью последнего из разработанных эксплойтов показал, что в его задачи входит сборка и конфигурация исполняемого файла руткита TDSS. Скрипт принимает на вход несколько параметров, один из которых предоставляет собой отладочную информацию о сборке трояна.

*Часть скрипта MakeBuild.php*

Скрипт MakeBuild.php оказался уязвимым к атаке на удаленное исполнение кода (remote code execution). В частности, как видно из листинга, входные параметры скрипта не фильтруются, а передаются напрямую в функцию exec(). Дополнительно, если использовать параметр dbg в запросе к скрипту, то в отладочном выводе будет напечатан результат выполнения команды.

В результате выполнения следующего запроса выводится список файлов в текущей директории:

Через эту уязвимость на сервер был загружен скрипт для удаленного управления.

Повышение привилегий

Права root на сервере были получены с помощью эксплойта для уязвимости sock_sendpage(), который потребовал небольшой модификации для обеспечения его выполнения в 64-битной операционной системе сервера.

*Директория /root на командном сервере TDSS*

Панель управления

Настройки для панели управления ботнетом содержались в файле engine_admin.conf, расположенном в той же директории, что и файл engine.conf.

*Содержимое файла engine_admin.conf*

Как видно из файла, адрес панели администрирования — 91.212.226.59. Однако открыть этот адрес в веб-браузере не удавалось: наш IP-адрес не входил в «белый список» доступа. Обойти эту защиту позволила модификация правил фаервола, описанных в файле /root/ipt.rules.

*Изначальное содержимое файла ipt.rules*

Таким образом, доступ к сайту панели управления был получен, но для входа в панель требовалась стандартная авторизация (Basic Authorisation). Пароли для входа хранились в файле htpasswd.engine в зашифрованном виде. Но вместо подбора паролей для первого доступа мы подменили файл htpasswd.engine целиком. Позже выяснилось, что логины и пароли к панели управления хранились в базе данных без шифрования, что позволило использовать их для дальнейшего доступа.

Запрос авторизации при входе в административную панель

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

Статистика числа заражений по дням

Статистика по операционным системам

Запущенные на выполнение команды

Статистика по странам

Модули TDSS

Смена серверов

Тем временем начала распространяться новая версия бота TDSS (3.64). В этой версии сменились адреса командных серверов.

Фронтенд (front-end) — дополнительный HTTP-сервер для выдачи статического содержимого сайта. Используется в целях оптимизации ресурсов веб-серверов с высокой нагрузкой.

Скрипты новых серверов претерпели некоторые изменения. В частности, была исправлена уязвимость с выводом ошибки при неверном GET-запросе к серверу. Но, поскольку все остальные найденные ранее уязвимости успешно функционировали, то было возможно прочитать файл index.php. Его код оказался доработан: теперь все исключения записывались в файл лога. Настройки сервера также претерпели изменения. В частности, в дополнение к HTTP-серверу lighttpd в качестве фронтенда был установлен дополнительный веб-сервер nginx.

Конфигурацонный файл виртуальных серверов на новом сервере остался прежним: engine.conf.

Таким образом, панель администрирования сервера теперь располагалась по адресу 188.72.242.191, а наш скрипт удаленного управления остался на сервере по адресу 188.72.242.190. Как видно из листинга, каждому IP-адресу соответствует отдельное доменное имя. Возможность использования «чёрного хода» оказалась недоступна. Для обхода этого ограничения был разработан следующий скрипт:

*Скрипт для выполнения команд на новом сервере через файл MakeBuild.php*

Данный скрипт обеспечивает отправку запроса к скрипту MakeBuild.php путем подстановки доменного имени сервера, на котором хранится файл скрипта (bld.newnetengine.com), в поле Host HTTP-запроса. Получив такой запрос, HTTP-сервер nginx на командном сервере перенаправлял его на указанный сервер и возвращал ответ.

Часть 2. Анализ

Командный сервер ботнета работает под управлением 64-разрядной операционной системы Ubuntu Linux:

Для сетевого интерфейса eth0 назначено 10 IP-адресов:

Из них четыре (91.212.226.60, 91.212.226.61, 91.212.226.62 и 91.212.226.64) используются для доступа к веб-шлюзу, с которым работают боты, два (91.212.226.63 и 212.117.162.50) — для доступа к веб-интерфейсу для сборки и конфигурации бота, и один (91.212.226.59) — для доступа к панели администрирования ботнета.

*Учетные записи локальных пользователей в файле /etc/shadow*

Список запущенных процессов на сервере на момент анализа выглядел следующим образом:

База данных и скрипты

В качестве СУБД на сервере используется MySQL, а в качестве веб-сервера — LightTPD, к которому в качестве обработчика CGI-приложений подключен пакет PHP. Кроме того, часть данных, обращения к которым производятся наиболее часто, кэшируются в памяти с помощью программы memcached.

Скрипты панели администрирования и шлюза для ботов находятся в директории /var/www/engine, которая имеет следующую структуру:

На момент получения доступа к серверу база данных содержала 47 таблиц с общим количеством записей порядка 17 719 469 и занимала на диске примерно 2,6 ГБ.

Имена и назначения таблиц:

Далее будет приведена структура наиболее интересных таблиц и некоторые пояснения, касающиеся работы с ними.

Запросы от ботов к серверу

Сразу после инсталляции бот инициирует запрос команд от сервера и повторяет этот запрос через заданный в конфигурации интервал времени. Запросы бота, как уже было описано в первой части статьи, шифруются по алгоритму RC4 с использованием имени целевого сервера в качестве ключа, затем кодируются по алгоритму base64 и отправляются на веб-шлюз командного сервера по протоколу HTTPS.

Формат запросов на получение команд может отличаться от одной версии бота к другой. Для большинства версий, включая самые последние, запрос выглядит следующим образом:

Назначение полей запроса:

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

Функциональность отправки специальных запросов не фигурирует в коде «полезной нагрузки» бота в явном виде, однако бот может отправлять подобные запросы в результате обработки команд, полученных с сервера (например, команды на загрузку дополнительного модуля «полезной нагрузки»).

Рассмотрим процесс обработки запросов от бота более подробно. В первых строках скрипта /var/www/engine/index.php происходит подключение необходимых заголовочных файлов, а также расшифровка запроса:

Поля запроса, как видно из приведённого кода, сохраняются в массиве $request. Далее, в зависимости от значения первого элемента этого массива (а именно, идентификатора типа для специальных запросов), происходит подключение одного из следующих PHP-скриптов, обрабатывающих конкретные типы запросов:

Если значение первого элемента массива не совпало с приведенными в таблице идентификаторами, то такой запрос обрабатывается как запрос команды:

Возвращаемый боту в ответ на запрос список команд также шифруется по алгоритму RC4, но в качестве ключа в этом случае используется не имя сервера, а идентификатор бота (содержимое переменной $requestName).

Учётные записи партнёров

В таблице affiliates содержится информация об учётных записях партнёров. Их добавление и редактирование доступно оператору панели администрирования ботнета.

Редактирование учётной записи партнёра в панели администрирования ботнета

Каждый партнёр может владеть произвольным количеством ботов. Идентификатор учётной записи партнёра «прошивается» в исполняемый файл бота на этапе его сборки и конфигурирования и хранится руткитом в файле config.ini на зашифрованной файловой системе.

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

*Идентификаторы основной и дополнительной учётных записей партнёра в файле config.ini*

Учётными записями партнёров можно управлять без посредства панели администрирования, путём отправки специальных запросов типа services веб-шлюзу командного сервера. Формат параметров этого запроса выглядит так:

Коды операций:

Пояснение параметров запроса:

Перечень возможных групп, к которым может принадлежать партнёр, содержится в файле /var/www/engine/data/groups.txt:

Для примера, запрос получения статистики по количеству установок бота в период с 01.08.2009 по 01.07.2010 для дополнительной учётной записи 0 партнёра с affAid, равным 10000, будет выглядеть следующим образом:

Таблица ботов

Информация о боте представляет собой запись в таблице bots, которая создаётся при обработке первого запроса на получение команд от бота. При этом значения полей таблицы affId, affSid и botName извлекаются из соответствующих параметров запроса.

Класс mBots, обеспечивающий работу с таблицей bots, находится в файле /var/www/engine/library/models/mBots.php. Функции добавления и изменения информации о боте реализованы в скрипте /var/www/engine/public/engine.php.

Структура таблицы bots:

Система команд

В конце скрипта engine.php подключается файл /var/www/enginedata/commands.php. Его задача — вывод команд, которые требуется выполнить боту. При этом скрипт commands.php генерируется динамически на основе данных, хранящихся в таблице commandsinfo.

Класс mCommands, обеспечивающий работу с командами, находится в файле /var/www/engine/library/models/mCommands.php. Процедура динамического создания файла commands.php реализована в методе reGenerate, который вызывается по команде из панели администрирования:

Добавление новой команды в панели администрирования

Для каждой команды можно указать следующие дополнительные параметры:

• идентификаторы стран, для ботов из которых требуется выполнение данной команды;

• идентификаторы учётных записей партнёров;

• версии браузеров на зараженных машинах;

• версии руткита и модуля TDLCMD.DLL;

• время жизни команды;

• максимальное число запусков команды.

Оператор панели администрирования может даже редактировать непосредственно фрагмент PHP-кода, который будет включён в commands.php.

Редактирование кода команды в панели администрирования

Бот может обрабатывать следующие команды:

Модули «полезной нагрузки»

Основные функции руткита TDL3 — «полезная нагрузка» — обеспечиваются дополнительными модулями. Модули представляют собой обычные динамические библиотеки, загружаемые с сервера и внедряемые в произвольный либо текущий процесс пользовательского режима.

Информация о доступных модулях хранится в таблице modules:

Загрузка файла модуля на заражённый компьютер может производиться с помощью команды ModuleDownloadUnxor. В качестве параметра ей передаётся зашифрованный запрос к серверу, формат полей которого выглядит следующим образом:

Запрос на загрузку модуля обрабатывается в файле /var/www/engine/public/modules.php:

Исполнение команды, адресованной конкретному модулю, происходит путём отправки боту строки следующего вида:

Пример загрузки и исполнения модуля remover (фрагмент кода из commands.php):

Добавление и редактирование модулей происходит в соответствующем разделе панели администрирования:

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

На момент получения доступа к серверу в базе данных присутствовали следующие модули:

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

На момент анализа число загрузок модуля Remover составляло 19 000 — таким образом, оно несопоставимо мало относительно общего количества ботов. Это может свидетельствовать о том, что модуль Remover проходил тестирование и что в будущем разработчиками бота планировалось широкое использование собственного «антивируса» для борьбы с конкурирующими вредоносными программами.

Статистика

В завершение статьи приведём несколько срезов статистики по ботнету. Статистические данные были получены путём анализа базы данных командного сервера d45648675.cn по состоянию на 7 февраля 2010 года.

Более подробные статистические данные приведены ниже в виде графиков и диаграмм.

Число новых установок по неделям (одна точка на графике соответствует одной неделе)

Заметный пик на графике соответствует «рекорду» в 443 364 уникальные установки бота 19 января 2010 года. Все установки были относительно равномерно распределены между несколькими десятками партнёрских учётных записей. Это может говорить о том, что причиной столь стремительного роста числа инсталляций стала волна эксплуатации некой уязвимости «нулевого дня».

Число уникальных ботов, которые обращались к серверу в течение недели

Распределение ботов по странам

Распределение ботов по партнёрам

Как видно из диаграммы, самый крупный партнёр обеспечивал 22,3% всех инсталляций руткита, вдвое превышая по эффективности второго партнёра.

Распределение новых инсталляций по партнёрам

Как видно из диаграммы, 90% партнёров обеспечивают от 1 000 до 50 000 загрузок, из которых 50% приходится на мелких партнёров (число загрузок от 1 000 до 5 000). Партнёров с числом загрузок более 5 000 всего 17, из них всего один обеспечил более 1 000 000 загрузок.

Версии Windows

Как видно из диаграммы, операционная система Windows XP, в которой не поддерживаются современные защитные механизмы (UAC, DEP и ASLR), является наиболее уязвимой для вредоносных программ. Относительно малое число заражений Windows 7 не связано с долей данной операционной системы в числе остальных (которая достаточно высока). Можно предположить, что доставка бота на компьютеры с Windows 7 осуществлялась преимущественно методами социальной инженерии.

Версии руткита

*Версии модуля TDLCMD.DLL*

Поскольку сервер d45648675.cn функционировал и на момент написания статьи (14 июля 2010), мы собрали обновлённую статистику с помощью механизмов специального запроса типа services. Мы также проанализировали несколько десятков инсталляторов руткита TDL3, чтобы выявить адреса всех активных командных серверов.

Помимо сервера, соответствующего доменному имени d45648675.cn (и ряду других), использовался второй сервер a57990057.cn. Каждый из двух серверов имел несколько IP-адресов, и каждому IP-адресу было сопоставлено несколько доменов.

Federal Bureau of Investigation. FBI, Slovenian and Spanish Police Arrests Mariposa Botnet Creator, Operators.

Как видно из таблицы, в период с 07.02.2010 по 14.07.2010 количество ботов, прошедших через первый сервер, выросло почти на 40%, а общее количество компьютеров, заражённых руткитом TDL3 в период с 12.08.2009 по 14.07.2010, составило более 16 000 000. Крупнейшим ботнетом в мире до настоящего момента считался ботнет Mariposa, объём которого на момент его закрытия был оценён экспертами в 12 000 000 зомби-машин.

Последнее обновление: 17.03.2012.