В современном мире трудно найти человек использующего интернет, но не устанавливающего дополнительных расширений для своего браузера. Такие расширения как Flash установлены у подавляющего большинства пользователей. А ведь именно появление таких плагинов повлияло на изменение ландшафта в современном эксплойтостроении. Теперь безопасность на стороне пользователя не может контролироваться только со стороны разработчиков браузера. Не менее важна и безопасность каждого из установленных плагинов, ведь злоумышленники могут использовать его для внедрения в систему вредоносного кода. К примеру, появление уязвимостей в продуктах небезызвестной компании Adobe влечет за собой рост количества эксплойтов, нацеленных именно на эти уязвимости.
Причем неоперативное закрытие этих самых уязвимостей со стороны Adobe дает злоумышленникам достаточно большое временное окно для успешных атак. Далеко ходить не надо и яркий пример этому — CVE-2010-1297, когда эта дыра была прикрыта только 29 июня, а обнародована уязвимость стала 4 июня. Получается окно более трех недель для успешных атак нулевого дня. От начала текущего года мы отмечаем сильное увеличение потока эксплойтов, нацеленных на продукцию Adobe.
Популярность сплойтпаков с наличием эксплойтов для Adobe и способных обходить DEP и ASLR сильно возрастает. Самое интересное, что в некоторых сплойтпаках стали появляться механизмы автоматической проверки попадания сайта в черные списки популярных репутационных систем.
Кибепреступники используют в своем творении полиморфные механизмы обфускации эксплойта, что позволяет либо для каждого посетителя, либо через какие-то временные интервалы модифицировать код эксплойта, не изменяя его функциональность. Такой функционал необходим для противодействия сигнатурному обнаружению и довольно эффективно сбивает примитивные методы детекта. В последнее время стало появляться функционал по противодействию публичным песочницам и автоматическим средствам анализа, таким как: Wepawet, Jsunpack и некоторым общеизвестным методам автоматической распаковки обфусцированных JavaScript программ.
Нагоняют трафик на сайт с эксплойтпаком тоже автоматически, здесь может быть как прямой редирект, так и целая цепочка. Киберпреступники, продающие такого рода трафик, это, по большей части, партнерки, которые владеют ботсетью из зараженных веб-сайтов. Редирект, как правило, осуществляется при помощи простого инжекта iframe.
В последние годы идет явный акцент на client-side атаках с использованием эксплойтов. В принципе, внедрено уже много различных механизмов для их противодействия на уровне операционных систем. Именно благодаря этим механизмам порог мастерства для человека, разрабатывающего эксплойт, сильно возрос. А теперь давайте посмотрим (обзорно, конечно :)) на те техники, которые используются злоумышленниками в современном эксплойтостроении.
DEP и прочий ASLR
Обход DEP уже давно перестал быть проблемой и на эту тему первые открытые публикации стали появляться несколько лет назад. Но все же со временем ситуация осложнилась появлением технологии permanent DEP. Суть этой технологии заключается в том, что процесс при запуске сам устанавливает себе DEP при помощи вызова функции SetProcessDEPPolicy(). DEP не может быть выключен в процессе исполнения, т.к. тут возникает проблема повторного вызова NtSetInformationProcess(), который невозможен. По умолчанию в современных браузерах (на XP SP3 и выше), как мы видим, используется этот механизм, что усложняет жизни современным разработчикам эксплойтов. Это не может не радовать нас как разработчиков защитного софта.
Но, не смотря на предоставляемые механизмы противодействия, не все разработчики массового софта подходят к их использованию одинаково серьезно. Давайте посмотрим как обстоят дела в динамике.
Несмотря на очевидный прогресс по сравнению с 2008 годом, мы всеравно видим, что, например, ASLR используется. А для продуктов Adobe существуют механизмы обхода, именно поэтому с таблице стоят опции поддержки защитных механизмов со звездочкой. Эти данные взяты из недавнего отчета “DEP/ASLR Neglected in Popular Programs” компании Secunia. ASLR представляет реальную проблему для злоумышленников только в том случае, если он будет повсеместно использоваться.
Давайте теперь немного поговорим о методиках обхода и эффективности вышеупомянутых технологий защиты, которые сейчас наиболее популярны.
Heap spraying
Несмотря на очевидный прогресс в механизмах противодействия со стороны операционной системы, исследователи и в белых, и в черных шляпах не перестают искать методы их обхода. Ведь уже хорошо известные способы эксплуатации с перезаписью адреса возврата и захвата SEH-обработчика перестали работать и понадобились новые техники. Евангелистом методов эксплуатации при помощи JIT spraying по праву можно считать Александра Сотирова, который одним из первых стал подробно обсуждать эту тему публично и рассказывать о различных способах эксплуатации при помощи этой техники.
Если попытаться определить технологию атаки JIT spraying в общем виде, то она будет выглядеть следующим образом:
А на системном уровне примерно так:
Ниже мы приводим сводную таблицу медов атаки с использованием этой техники и способов противодействия им:
В последнее время при использовании JIT spraying часто встречается шелл-код, использующий возвратно-ориентированное программирование. В эксплойтах для CVE-2010-1297 эта техника активно используется, правда использование этой техники влечет за собой приминение многоуровневой архитектуры для шелл-кода.
ROP
Возвратно-ориентированное программирование (Return-oriented programming) или попросту ROP нацелено в первую очередь на то, чтобы дать возможность обойти защитные механизмы, такие как неисполняемых сегментов памяти. ROP – это, конечно, новая веха в эксплойтостроении, но предпосылки для ее появления были замечены уже давно. Интересная схема эволюции этих методов была взята нами из статьи «A gentle introduction to return-oriented programming».
Использование техники ROP требует от исследователя достаточно высокого уровня знаний и подготовки, что увеличивает порог вхождения для людей, желающих разобраться в этом. Отладка такого шелл-кода тоже занимает достаточно много времени.
Все выше описанное о сложности разработки не говорит о том, что можно радоваться, и скоро мы все попадем в нирвану. Нет, это не так, скорее это означает то, что дальше нас ждет интересное развитие этих методик и, конечно же, появление новых.
