Якби наші програми були матеріальні і на них можна було б вішати таблички, то плагіни до браузерів, такі як 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-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 квітня.

Мал. 1. Експлойти Java в різних наборах ExploitPack

З часів активної експлуатації уразливості CVE-2012-0507 мало що змінилося і Java і раніше залишалася найпопулярнішим вектором, використовуваним в наборах експлойтів. 5 липня 2012 року з'явилася публічна інформація про використання CVE-2012-1723 в наборі експлойтів Blackhole, хоча сама вразливість була знайдена в середині червня. Уразливість заснована на колізії в JIT-компілятор. Для її успішної експлуатації необхідно створити кілька статичних полів (в експлойтів їх 100), потім стільки ж звернень до цих полів, що призводить до затримки JIT-компіляції цього коду на стадії верифікації. У підсумку всі ці маніпуляції дозволяють виконати довільний аплет в обхід перевірок безпеки за межами пісочниці.

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.

Опис вразливостей з'явилося вже після виходу патча від 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 .

Новий, 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.

В кінці січня дослідник безпеки Адам Говдяк (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, в яких було усунуто п'ять нових проблем з безпекою.

Експлойт уразливості був виявлений в кінці лютого в «дикому вигляді» компанією 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.

Мал. 2. Статистика використання вразливостей Java

На початку березня одна з кібергруппіровок випустила експлойт-пак з назвою 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-аплети, у користувачів корпоративні додатки повинні запускатися тільки з серверів самої організації.

Мал. 3. Хронологія виявлення вразливостей Java і їх закриття

За допомогою технології IPMI (Intelligent Platform Management Interface) можна визначати такі неприємності, як зависання сервера, блокування мережевого доступу через неправильну настройки файрвола, перегрів апаратної частини серверів і тому подібні, і оперативно реагувати на них. Зазвичай технологія реалізується у вигляді інтегрованого в материнську плату контролера, який містить окрему мережеву плату (тобто забезпечується дублювання основного каналу управління сервером).

Управління ведеться за власним протоколу IPMI. IPMI працює незалежно від операційної системи і здатний управляти платформою, на якій відсутній ОС, і навіть в тих випадках, коли сервер вимкнений, досить лише підключення до джерела живлення. Працювати з IPMI-контролером можна через веб-інтерфейс (потрібен будь-який браузер з підтримкою Java) або через спеціалізоване ПО.

Володимир Трегубенко, [email protected]