Cамая полная история дыр в известной платформе
Если бы наши программы были материальны и на них можно было бы вешать таблички, то плагины к браузерам, такие как Adobe Flash и Adobe PDF, несомненно, были бы достойны вывески «Вход для малвари свободный!». Однако в последние годы пальму первенства в этой области у продукции Adobe грозится отобрать Java. Попробуем разобраться в этой темной истории.
Итак, каковы же причины такого устойчивого роста количества эксплойтов к Java? Их несколько. Во-первых, бурное развитие мобильных устройств привело к необходимости писать приложения корпоративного уровня для разных платформ, и кросс-платформенная Java здесь подошла как нельзя лучше. Во-вторых, в больших компаниях на Java пишут приложения для работы систем электронного документооборота, систем банковского обслуживания и так далее, причем имеются жесткие требования ставить JRE определенной версии.
Многие вендоры любят использовать технологии Java для удаленного управления серверами по технологии IPMI.
Кроме того, Java-уязвимости довольно просто эксплуатируются, так как не требуют обхода DEP/ASLR и прочих механизмов безопасности. Ну и вдобавок ко всему эксплойты Java-уязвимости в подавляющем большинстве своем кросс-платформенные, что позволяет активно использовать их против целевых систем под управлением не только Windows, но и OS Х и Linux.
Из-за этой специфики применения Java домашние пользователи менее подвержены опасности по сравнению с корпоративными. Да и саму Java нужно устанавливать вручную, она не входит в инсталляционные пакеты Windows и браузеров, чего не скажешь о продукции компании Apple.
До определенного момента, а именно до эпидемии Flashback весной 2012 года Java-плагин для браузера был включен по умолчанию, но после этого инцидента Apple приняла решение от него избавиться.
Масштабы разрушений
Для оценки масштабов проблемы можно взять данные 2012 года от антивирусной компании «Лаборатория Касперского». Ее сотрудники исследовали используемые в 2012 году уязвимости. В качестве исходных данных служила информация облачной сети безопасности Kaspersky Security Network. Общее количество пользователей ПЭВМ под управлением ОС Windows, согласившихся передать данные в KSN, составило свыше 11 миллионов. Анализ выявил восемь уязвимостей, которые наиболее часто использовались злоумышленниками в эксплойт-паках. Пять из них содержалось в ПО Oracle Java JRE, три оставшихся находились в продуктах Adobe — две в Flash Player и одна в PDF Reader. На графике (см. рис. 2) показано процентное соотношение пользователей, которые подвергались риску заражения вредоносным ПО через эксплуатацию уязвимостей Java. Далее будут кратко описаны уязвимости Java, наиболее широко используемые в 2012 и начале 2013 года.
CVE–2012–0507
Уязвимость CVE–2012–0500 не снискала особой популярности у злоумышленников. Даже в составе Metasploit ее эксплойт идет в разделе Windows, тогда как все остальные последние эксплойты проходят по категории Multi, то есть кросс-платформенные. Поэтому сразу переходим к CVE–2012–0507.
Впервые рабочий эксплойт для нее появился в продукте Immunity CANVAS еще 7 марта 2012 года. Сама уязвимость на тот момент уже была закрыта в рамках критического обновления от Oracle от 14 февраля 2012 года. В конце марта эксплойт этой уязвимости появился в обновленном Blackhole Exploit Kit версии 1.2.3. Уязвимость скрывается в реализации класса AtomicReferenceArray, в которой происходит неверная проверка на принадлежность к типу Object, что в конечном итоге позволяет выполнить специально подготовленный апплет или класс за пределами песочницы JRE. 29 марта 2012-го появился публичный эксплойт для CVE–2012–0507 в составе Metasploit Framework. Ко всему прочему он кросс-платформенный и срабатывает в среде ОС Windows, Linux, Solaris и OS X. Последняя особенно интересна — для нее заметно увеличилось число вредоносных программ, распространяющихся в том числе и посредством эксплуатации Java-уязвимостей.
Эксплойт из Metasploit Framework выглядит похожим на тот, что имеется в составе Blackhole, и предположительно взят именно из него.
Первые признаки эксплуатации в «диком виде» CVE–2012–0507 были замечены в середине марта. Именно тогда были отмечены многочисленные случаи инфицирования трояном Carberp на таких крупных ресурсах с высокой посещаемостью, как izvestia.ru и lifenews.ru. Cкрипты, загружающие вредоносные Java-апплеты, размещались на взломанных серверах баннерной сети, используемых на этих ресурсах. В конечном итоге после успешной эксплуатации уязвимости Java происходил вызов функции DownloadAndExec, который уже за пределами изолированной среды Java скачивал полезную нагрузку (Carberp) в каталог %TEMP% и запускал ее.
Троян Flashback или Flashfake, вызвавший в начале 2012 года волну заражений компьютеров Apple под управлением OS X, тоже использовал CVE–2012–0507 для своего распространения, это было после 16 марта 2012-го. До этого для заражения Flashback использовались уязвимости CVE–2011–3544 и CVE–2008–5353, обе тоже для Java. Кстати, CVE–2011–3544 был в свое время одним из самых «пробивных» эксплойтов. Массовое заражение более чем 550 тысяч Маков стало возможным из-за того, что Apple проигнорировала критическое обновление от Oracle и не обновила свой пакет Java для OS X. Патч от Apple вышел только 6 апреля.
Хакер #172. Спецвыпуск о Raspberry Pi!
CVE–2012–1723
Со времен активной эксплуатации уязвимости CVE–2012–0507 мало что изменилось и Java по-прежнему оставалась самым популярным вектором, используемым в наборах эксплойтов. 5 июля 2012 года появилась публичная информация об использовании CVE–2012–1723 в наборе эксплойтов Blackhole, хотя сама уязвимость была найдена в середине июня. Уязвимость основана на коллизии в JIT-компиляторе. Для ее успешной эксплуатации необходимо создать несколько статических полей (в эксплойте их 100), затем столько же обращений к этим полям, что приводит к задержке JIT-компиляции этого кода на стадии верификации. В итоге все эти манипуляции позволяют выполнить произвольный апплет в обход проверок безопасности за пределами песочницы.
CVE–2012–4681
24 июля 2012 года Джеймс Форшоу (James Forshaw aka tyranid) сообщил компании Zero Day Initiative (ZDI, www.zerodayinitiative.com) о новой уязвимости. Через месяц, 26 августа, компания FireEye (www.fireeye.com), а вслед за ней и другие разработчики антивирусного ПО обнаружили применение эксплойта этой уязвимости, являвшейся на тот момент zero-day. Уже на следующий день эксплойт был внедрен в состав Blackhole Exploit Кit.
Майкл Ширл (Michael Schierl), эксперт в области уязвимостей Java, обнаруживший такие известные уязвимости, как CVE–2011–3544 и CVE–2012–1723, провел собственный анализ эксплойта CVE–2012–4681 и создал временный патч уязвимости. Oracle выпустила соответствующее обновление безопасности только 30 августа, таким образом, пользователи Java оставались беззащитны перед злоумышленниками как минимум в течение четырех суток.
Эксплойт, обнаруженный FireEye, использовался для скрытой установки вредоносного ПО Poison Ivy, относящегося к категории Remote Administration Tool. Как позже отметили специалисты компании Immunity, технически эксплойт эксплуатировал не одну, а сразу две уязвимости в Java.
CVE–2012–5076 и CVE–2012–5088
Описание уязвимостей появилось уже после выхода патча от Oracle. Интересно в них применение Reflection Api.
В Java существует механизм защиты, который построен на понятии доменов безопасности. Каждый домен включает в себя набор классов, экземплярам которых выданы одинаковые права. Для упрощения достаточно выделить два домена — trusted и untrusted. К первому относятся все системные классы и подписанные апплеты, им разрешены все действия в системе. Ко второй категории относятся неподписанные апплеты, которые сильно ограничены в правах (например, им запрещено манипулировать с файлами). При обращении к некоторому системному ресурсу происходит запрос к менеджеру безопасности, который проверяет, есть ли у текущего потока права для доступа к ресурсу. В определении прав доступа есть одно исключение — privileged блоки. Если некоторый код исполняется в контексте privileged блока, то его права определяются правами вызвавшего метод doPrivileged кода. Таким образом, сущность метода сводится к обнаружению таких методов-классов, которые позволят выполнить вредоносный код (обычно это код отключения менеджера безопасности) в privileged блоке. Так как такие методы недоступны для прямого вызова, для решения этой проблемы используется Reflection API (в совокупности с некоторыми другими трюками). Reflection API в чем-то похож на RTTI в C++ и позволяет получать полную информация о классах и их членах в runtime.
Более подробно об уязвимостях CVE–2012–5076 и CVE–2012–5088 можно почитать в статье «New Java Modules in Metasploit… No 0 days this time» на сайте, на русском языке есть отличная статья о CVE–2012–5076 от комрада neko на damagelab.org.
CVE–2013–0422
Новый, 2013 год для Oracle сразу не задался. Разработчики некоторых эксплойт-паков, таких как Blackhole, Cool, Nuclear Pack, Sakura, сделали «новогодний подарок» для своих клиентов в виде zero-day эксплойта уязвимости Java Applet JMX 0day Remote Code Execution (CVE–2013–0422). По данным авторов вредоносного ПО, используемая ими уязвимость существует во всех версиях Java 7, в том числе в Java 7 Update 10. Этот «подарок» вынудил компанию Oracle выпустить спустя неделю экстренное обновление, однако не прошло и 24 часов после выпуска 13 января 2013 года патча Java 7 Update 11, закрывающего уязвимость CVE–2013–0422, как на одном из форумов, распространяющих crimeware, появилось сообщение о продаже очередного zero-day эксплойта для Java. Продавец запросил за эксплойт 5000 долларов и пообещал продать его только двум первым «счастливчикам». И покупатели не заставили себя долго ждать. Кстати, подобное уже случалось — не далее как 16 октября 2012 года компания Oracle выпустила патчи Java 7 Update 9 and Java 6 Update 37, через несколько недель в продаже появился zero-day эксплойт, по всей видимости и использующий CVE–2013–0422, «пробивающий» Java 7 Update 9 (но не затрагивающий Java 6).
Сотрудник компании Immunity Эстебан Гильярдой (Esteban Guillardoy) сделал отчет с подробным анализом уязвимости, ее суть сводится к тому, что при помощи метода
com.sun.jmx.mbeanserver.MBeanInstantiator.findClassможно получить ссылку на экземпляр любого класса (например, запрещенного к использованию в апплетах без разрешения пользователя). Но есть одна маленькая проблема — у этого класса нет публичного конструктора. Обходится это при помощи класса
com.sun.jmx.mbeanserver.JmxMBeanServerу которого есть публичный конструктор, а также метод
getMBeanInstantiatorпозволяющий получить ссылку на
com.sun.jmx.mbeanserver.MBeanInstantiatorТаким образом, весь эксплойт умещается в паре строк кода (дальше можно получать ссылки на любые классы и производить операции в обход ограничений безопасности):
javax.management.MBeanServer ms = com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer("test", null, null, true); com.sun.jmx.mbeanserver.MBeanInstantiator mi = ((com.sun.jmx.mbeanserver.JmxMBeanServer)ms).getMBeanInstantiator(); Class clazz = mi.findClass("some.restricted.class.here", (ClassLoader)null);Между прочим, именно CVE–2013–0422 использовал в качестве одного из своих векторов распространения (помимо уязвимости PDF) вредоносный загрузчик MiniDuke.
CVE–2013–0431
В конце января исследователь безопасности Адам Говдяк (Adam Gowdiak) из компании Security Explorations опубликовал информацию об обнаруженной им новой уязвимости. Как известно, в декабре прошлого года в Java 7 Update 10 были введены настройки безопасности, предусматривающие четыре уровня: Low, Medium, High, Very High. В частности, при выборе Very High запрещается выполнение любого неподписанного Java-кода.
Однако реализация уровней безопасности не принимала во внимание, что Java-апплеты могут быть созданы с использованием сериализации. Это можно сделать с помощью следующего HTML-тега <applet>:
<applet object="BlackBox.ser">Данные BlackBox.ser могут быть легко созданы с использованием следующего кода:
BlackBox b=new BlackBox(); ByteArrayOutputStream baos=new ByteArrayOutputStream(); ObjectOutputStream oos=new ObjectOutputStream(baos); oos.writeObject(b); FileOutputStream fos=new FileOutputStream("BlackBox.ser"); fos.write(baos.toByteArray()); fos.close();Указанный метод может быть успешно использован для запуска неподписанных Java-апплетов в среде JRE 7 Update 11 независимо от выбранного уровня безопасности в панели управления Java. Данная уязвимость получила номер CVE–2013–0431.
Из последних инцидентов с ее использованием можно отметить распространение троянской программы Cridex. По данным компании ESET, атака осуществлялась через спам-сообщения, которые содержали информацию о популярной в СМИ теме — введению разового налога для банковских счетов клиентов кипрских банков. Само письмо выглядело таким образом, как будто оно было отправлено от телекомпании BBC. Ссылка в сообщении вела на веб-страницу, с последующим перенаправлением на Blackhole Exploit Kit. В результате успешной эксплуатации уязвимостей, в основном как раз CVE–2013–0431, компьютер заражался Cridex.
Oracle выпустила патч Java 7 Update 13, закрывающий эту уязвимость, 1 февраля. Критическое обновление устраняло 50 проблем безопасности в JRE. Среди них было финальное исправление уязвимости CVE–2013–0422, на самом деле бывшей результатом использования двух уязвимостей, одна из которых была закрыта Java 7 Update 11, а другая — Java 7 Update 13. Компания Oracle 20 февраля в дополнение к выпущенному в начале месяца Update 13 представила плановые корректирующие выпуски Java SE 7 Update 15 и Java SE 6 Update 41, в которых было устранено пять новых проблем с безопасностью.
CVE–2013–1493
Эксплойт уязвимости был обнаружен в конце февраля в «диком виде» компанией FireEye при помощи технологии Malware Protection Cloud (MPC). В отличие от других распространенных уязвимостей Java, где менеджер безопасности обходится простым путем, здесь использовалась произвольная запись и чтение памяти процесса виртуальной машины Java. После срабатывания уязвимости эксплойт искал адрес памяти, в котором содержалась информация о внутренней структуре виртуальной машины, в том числе о статусе менеджера безопасности, а после перезаписывал эту часть памяти нулями.
После успешной эксплуатации загружалась и запускалась вредоносная программа McRat в виде файла svchost.jpg с того же сервера, где находился и вредоносный JAR. Эксплойт не отличался высокой стабильностью работы, поскольку пытался перезаписать значительный объем памяти. В результате в большинстве случаев после атаки загрузка происходила, но виртуальная машина Java завершалась с ошибкой и не могла запустить загруженный файл.
Специалисты компании выяснили, что уязвимость работает в браузерах, использующих плагин Java версии 6 с обновлением 41 и Java версии 7 с обновлением 15. На тот момент пользователям рекомендовалось отключить выполнение плагинов Java или сменить настройки безопасности Java на Very High и не запускать недоверенные апплеты.
Компания Oracle 4 марта выпустила внеплановые обновления Java SE 7 Update 17 и Java SE 6 Update 43 с исправлением проблем безопасности CVE–2013–1493 и CVE–2013–0809.
Согласно официальной информации от Oracle, Java SE 6 Update 41 должен был стать последним публичным апдейтом в ветке JDK6, поддержка которого, начиная с 20 февраля 2012 года, должна была происходить только по каналам Oracle Lifetime Support на платной основе. JDK7 тогда стала бы единственной публично поддерживаемой веткой в линейке JDK, вплоть до выхода JDK8. После выхода JDK8 JDK7 будет поддерживаться еще некоторое время, а затем также уйдет из публичной поддержки где-то в районе июля 2014 года. Тем не менее 4 марта выходит Java SE 6 Update 43, и именно он стал последним публичным патчем для шестой ветки Java. Хоть Oracle и пытается таким образом принудить переходить на JDK7, в целом корпоративный сектор не горит желанием это делать, так как многие их продукты разработаны под старые версии JDK.
Заключение
В начале марта одна из кибергруппировок выпустила эксплойт-пак с названием Neutrino. Этот пак на данный момент использует только две уязвимости — Java CVE–2012–1723 и CVE–2013–0431, что нехарактерно для Exploit Kit, куда обычно входят эксплойты к как можно большему количеству ПО. Создатели обещают добавить также эксплойты на Flash и PDF-плагины к браузеру, однако, с их слов, суммарный пробив и так составляет 86%. Естественно, что на практике количество установок вредоносного ПО будет на порядок ниже из-за отлова антивирусами, тем не менее эти цифры позволяют увидеть общую картину использования уязвимых версий JRE.
Общий вывод такой: в течение 2012 года и далее интересы злоумышленников сместились с использования эксплойтов плагинов браузеров с продукции компании Adobe (Flash Player и PDF) на использование уязвимостей Java.
Согласно появлению все новых описаний проблем безопасности от компании Security Explorations, доступных на их сайте www.security-explorations.com, ситуация в ближайшее время не изменится, компании Oracle и Apple будут вынуждены все время подлатывать «дыры» в своих реализациях виртуальных машин Java. Сводную таблицу хронологии обнаружения уязвимостей Java и их закрытия можно увидеть на рисунке (см. рис. 3), почти все из них есть в составе Metasploit Framework (кроме CVE–2013–1493).
В свете этого хочется дать следующие рекомендации:
обычным пользователям — не нужна вам эта Java, не ставьте ее вообще, одной «дырой» в системе будет меньше;
сисадминам крупных контор — по максимуму ограничивайте список сайтов, откуда могут запускаться Java-апплеты, у пользователей корпоративные приложения должны запускаться только с серверов самой организации.
Intelligent Platform Management Interface
С помощью технологии IPMI (Intelligent Platform Management Interface) можно определять такие неприятности, как зависание сервера, блокировка сетевого доступа из-за неправильной настройки файрвола, перегрев аппаратной части серверов и тому подобные, и оперативно реагировать на них. Обычно технология реализуется в виде интегрированного в материнскую плату контроллера, который содержит отдельную сетевую плату (то есть обеспечивается дублирование основного канала управления сервером).
Управление ведется по собственному протоколу IPMI. IPMI работает независимо от операционной системы и способен управлять платформой, на которой отсутствует ОС, и даже в тех случаях, когда сервер выключен, достаточно лишь подключения к источнику питания. Работать с IPMI-контроллером можно через веб-интерфейс (нужен любой браузер с поддержкой Java) или через специализированное ПО.
Владимир Трегубенко, tregubenko_v_v@tut.by
