суббота, 31 марта 2012 г.

Blackhole + CVE-2012-0507 = Carberp

На этой неделе известный набор эксплойтов Blackhole обновился до версии 1.2.3 и в его составе появился новый эксплойт для Java на уязвимость CVE-2012-0507 (Java/Exploit.CVE-2012-0507). Первыми обратила внимание общественности на актуальность этой уязвимости компания Microsoft, которая опубликовала в своем блоге сообщение об интересном способе выполнения Java кода за пределами песочницы JRE (Java Runtime Environment).

Первые упоминания о боевом эксплойте для этой уязвимости появились от компании Immunity, которая выпустила специальный модуль для своего продукта Immunity CANVAS еще в начале марта 7.03.2012. Эта уязвимость была закрыта 15 февраля в рамках критического обновления от Oracle. Буквально вчера поздним вечером, на момент подготовки этой публикации, появился публичный эксплойт для CVE-2012-0507 в составе Metasploit Framework. Отдельно стоит отметить его кроссплатформенность и возможность эксплуатации на системах Windows, Linux, Solaris и OSX. Последняя особенно интересна в свете увеличения количества вредоносных программ для нее, распространяющихся в том числе и посредством эксплуатации Java уязвимостей. Эксплойт из Metasploit Framework выглядит очень похожим на тот, что был обнаружен в обновленном Blackhole и складывается впечатление, что он был рипнут по большей части от туда ;)

В последнее время я довольно часто писал об эксплойтах для Java и они действительно в последний год самые пробивные в инцидентах массового распространения вредоносных программ. Разработчики наборов эксплойтов, таких как Blackhole, используют только так называемые 1-day уязвимости, т.е. уже содержащие официальное исправление от разработчиков. Потому что использование 0-day слишком дорого для их целей и совершенно себя не окупает, но бывают исключения, когда 0-day попадает на паблик вместе с PoC. Использование уязвимости нулевого дня на данный момент можно чаще всего увидеть в целенаправленных атаках. Кстати довольно занимательный пост о ценах на 0-day и карме ресечеров можно почитать тут.

Вернемся к нашему эксплойту, на этой неделе было замечено снова распространение Win32/TrojanDownloader.Carberp через популярные веб-ресурсы, посредством внедрения iFrame конструкций для перенаправления на ресурс с набором эксплойтов.

Первым нам попался ресурс lifenews.ru, на котором содержался следующий iFrame:


Как видно из внедренного кода сразу происходила атака именно CVE-2012-0507, а доменное имя на котором был расположен Blackhole очень схоже с именем атакованного веб-ресурса. Результат выполнения кода в iFrame можно увидеть даже визуально на модифицированной оригинальной странице.


После этого отображается старая, но недобрая, страница ожидания и именно в этот момент происходит активная стадия эксплуатации.


Аналогичная атака была замечена на веб-ресурсе izvestia.ru и устанавливалась так же модификация из семейства Win32/TrojanDownloader.Carberp. Вообще первые детекты эксплуатации Java/Exploit.CVE-2012-0507 были замечены ближе к середине марта.

Полный лог событий при посещении модифицированной страницы веб-ресурса livenews.ru выглядит так:


В обоих случаях заражение происходило при посещении URL вида:
  • http://izvestia.ru/banners/index.php?p=55
  • http://lifenews.ru/banners/index.php?p=2
Что наводит на мысли об инфекции через баннерную сеть, использующуюся на обоих ресурсах. Адрес на которой происходила переадресация так же выглядел одинаково в обоих случаях. 

Кстати у читателя может возникнуть закономерный вопрос, а как же недавний шум в прессе о задержании группы кибепреступников распространявших Win32/TrojanDownloader.Carberp и зарабатывавших на мошенничестве в системах ДБО. Все верно было задержано восемь человек, которые являлись различными звеньями преступной сети и представляли собой лишь одну группу, которая работала с Carberp. Но ведь на свободе остались еще другие и естественно чуда не произошло и они не прикатили свою деятельность.

Но давайте все же вернемся к эксплойту на уязвимость CVE-2012-0507, именно он представляет наибольший интерес из всей этой атаки (Carberp был ранее известной нам модификации и лишь перепакован для обхода обнаружения). Уязвимость скрывается в реализации класса AtomicReferenceArray, в которой происходит не верная проверка на принадлежность к типу Object[]. Эта уязвимость относится к так называемому классу "Type Confusion Vulnerabilities", раньше подобные уязвимости встречались на уровне верификатора байт-кода, но сейчас они уже закрыты и коллизия находятся непосредственно в Java API. Все это позволяет выполнить специально подготовленный апплет или класс за пределами песочницы JRE.  

Структура объектов в Java/Exploit.CVE-2012-0507 выглядит следующим образом:


Метод init() класса Ner создает объект типа AtomicReferenceArray для выполнения кода за пределами песочницы.


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


Код класса, который должен выполниться за пределами песочница зашифрован простым перестановочным алгоритмом щифрования и перед выполнением происходит его расшифровывание, которое в итоге приводит к появлению DownloadAndExec, который уже за пределами изолированной среды скачивает полезную нагрузку в виде троянца Carberp в каталог вида %TEMP%\vdsh89\gyu<file_number> и выполняет его.


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

Я думаю в этом году мы еще не раз вернемся к теме эксплуатации узявимостей для платформы Java и это далеко не последняя уязвимость для нее.

3 комментария:

  1. Mozilla забаннила старые версии Java-плагина: я так понимаю, что именно из-за этого.

    https://blog.mozilla.com/security/2012/04/03/blocklisting-older-versions-of-java/
    https://blog.mozilla.com/addons/2012/04/02/blocking-java/

    Кстати, вы не могли бы пояснить, как обстоят дела с безопасностью .NET/Silverlight и сопутствующих технологий?

    ОтветитьУдалить
    Ответы
    1. Да, вы абсолютно правы это произошло именно из-за большого количества атак, использующих Java-вектор.

      Что касается технологии Silverlight, то там несколько по иному устроенна песочница и обойти ее ограничения сложнее. А за счет специфики системы типов CLR, похожая ошибка мало вероятна. Но там есть другие ;) На данный момент нам еще ни разу не встречалась массовая эксплуатация уязвимостей для платформы Silverlight.

      Удалить