Анализ работы эксплойт-пака BlackHole и защита от него

На сегодняшний день использование уязвимостей в легитимном ПО является одним из наиболее популярных способов заражения компьютера. По нашим оценкам, чаще всего компьютеры пользователей атакуют эксплойты к уязвимостям в Oracle Java. Современные защитные решения способны эффективно противостоять drive-by атакам, реализуемым с помощью эксплойт-паков. Мы рассмотрим процесс заражения компьютера с помощью эксплойт-пака BlackHole и соответствующие механизмы защиты.

 

1. Эксплойт-паки

2. В черной дыре

• Стартовая страница эксплойт-пака
• Эксплойт к CVE-2012-5076
• Эксплойт к CVE-2012-0507
• Эксплойт к CVE-2013-0422
• Три в одном

3. Защита от Java-эксплойтов

• Первый этап: блокирование перехода на лендинг
• Второй этап: детектирование файловым антивирусом
• Третий этап: сигнатурное детектирование эксплойтов
• Четвертый этап: проактивное детектирование эксплойтов
• Пятый этап: детектирование загруженных вредоносных программ (полезной нагрузки)

4. Выводы

 

Эксплойт-паки

Как правило, злоумышленники используют не один эксплойт, а готовые наборы – эксплойт-паки. Это позволяет значительно повысить эффективность «пробива», поскольку в ходе атаки могут быть задействованы один или несколько эксплойтов, каждый из которых эксплуатирует имеющуюся на атакованном компьютере уязвимость в ПО.

Если раньше эксплойты и загружаемые с их помощью вредоносные программы создавались одними и теми же людьми, то сегодня эта отрасль чёрного рынка стала работать по модели SaaS (Software as a Service). В результате распределения труда каждая группа злоумышленников выполняет свои задачи: кто-то создает и продает эксплойт-паки, кто-то обеспечивает приход пользователей на стартовые страницы эксплойтов (гонит трафик), кто-то пишет распространяемые в ходе drive-by атаки вредоносные программы. Теперь злоумышленнику, желающему заразить компьютеры пользователей, например, одной из модификаций троянца ZeuS, достаточно купить готовый эксплойт-пак, настроить его и нагнать побольше потенциальных жертв на стартовую страницу (она также называется лендинг).

Злоумышленники перенаправляют пользователей на лендинг несколькими способами. Самый опасный для пользователей — взлом страниц легальных сайтов и внедрение в их код скриптов или iframe. В таких случаях пользователи сами заходят на знакомый сайт, и этого достаточно, чтобы началась drive-by атака и эксплойт-пак незаметно начал свою работу. Киберпреступники могут использовать и легальные рекламные системы, размещая ссылки на вредоносные страницы в баннерах или тизерах. Еще один популярный у злоумышленников способ — распространение ссылок на лендинг в спаме.

  
Рисунок 1. Общая схема заражения компьютеров пользователей с помощью эксплойт-паков

 

Сейчас на рынке представлено множество эксплойт-паков – Nuclear Pack, Styx Pack, BlackHole, Sakura и другие. Несмотря на разные названия, суть этих решений идентична – они представляют собой набор различных эксплойтов плюс панель администратора. Более того, все наборы эксплойтов работают практически по одной и той же схеме.

Один из самых известных на рынке эксплойт-паков — BlackHole. В него входят эксплойты, эксплуатирующие уязвимости в Adobe Reader, Adobe Flash Player и Oracle Java. Для максимальной эффективности входящие в набор эксплойты постоянно меняются. В начале 2013 года мы исследовали три эксплойта к Oracle Java из набора BlackHole, и для иллюстрации принципов работы эксплойт-паков в этой статье мы выбрали именно BlackHole.  

 

В черной дыре

Сразу стоит отметить, что сведения об эксплойтах, содержимом стартовых страниц и другая рассматриваемая нами информация (особенно – названия методов, классов, значения констант) актуальна на то время, когда проводилось исследование. Дело в том, что злоумышленники продолжают активно работать над BlackHole: чтобы усложнить детектирование антивирусными решениями, они часто вносят изменения в код того или иного эксплойта — например, меняют используемый им алгоритм расшифровки. В результате код может отличаться от приведенного нами в примерах ниже, но принцип его работы, тем не менее, останется неизменным.

 

Стартовая страница эксплойт-пака

Стартовая страница эксплойт-пака используется для определения входных параметров и принятия решения о дальнейших действиях эксплойт-пака. К входным параметрам относятся версия операционной системы пользователя, версия браузера и установленных плагинов, системный язык и другие. Как правило, в зависимости от входных параметров подбираются соответствующие эксплойты для атаки на систему. Если необходимое эксплойт-паку ПО отсутствует на компьютере пользователя, атаки не происходит. Атаки может не происходить и в тех случаях, когда злоумышленники пытаются предотвратить попадание содержимого эксплойт-пака в руки экспертов антивирусных компаний или других исследователей. Например, киберпреступники могут внести IP-адреса исследовательских компаний (краулеров, роботов, прокси-серверов) в свои «чёрные списки», блокировать запуск эксплойтов на виртуальных машинах и прочее.

Пример кода лендинга эксплойт-пака BlackHole представлен на скриншоте ниже.

  
Рисунок 2. Код стартовой страницы эксплойт-пака BlackHole

 

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

В результате обращения к стартовой странице будет выполнен код, который изначально был зашифрован.

 

Алгоритм расшифровки JavaScript кода, актуальный для января 2013: происходит заполнение переменных “z1 – zn” зашифрованными данными, потом эти переменные склеиваются в одну строку и расшифровываются следующим образом: каждые два символа (символ “-“ пропускается) рассматриваются как 27-ричное число и переводятся в десятичное число; к полученному значению прибавляется “57”, и всё это делится на 5; окончательное число преобразуется обратно в символ с помощью функции “fromCharCode”. Код, выполняющий эти действия, обведён голубыми овалами на скриншоте. Второй массив состоит из десятичных чисел от 0 до 255, которые конвертируются в символы в соответствии с таблицей ASCII кодов. Оба полученных фрагмента кода исполняются с помощью команды “eval” (строки отмечены стрелками).

 

Весь этот алгоритм можно было бы уложить в несколько строчек, но, чтобы усложнить детектирование, злоумышленники применяют специальные техники (на скриншоте отмечены желтыми овалами):

1. намеренный вызов исключения с помощью команды “document.body*=document”;
2. проверка стиля первого элемента <div> с помощью команды “document.getElementsByTagName("d"+"iv")[0].style.left===""”; отметим, что с этой целью в документ специально вставляется пустой элемент <div> (вторая строка);
3. вызов “if(123)”, который не имеет смысла, так как это выражение всегда верно;
4. дробление названий функций с последующей склейкой.

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

После расшифровки кода в оперативной памяти появится код — назовём его «расшифрованным скриптом». Он состоит из двух частей.

Первая часть — модуль бесплатной библиотеки PluginDetect, которая позволяет определить версии и возможности большинства современных браузеров и их плагинов. Злоумышленники используют различные библиотеки, но этот модуль является одним из ключевых элементов любого эксплойт-пака. BlackHole использует PluginDetect, чтобы в зависимости от установленного на пользовательской машине ПО выбрать из набора подходящие эксплойты для загрузки. Под подходящими мы подразумеваем те эксплойты, у которых больше вероятность успешно отработать и запустить вредоносную программу на конкретном компьютере.

Вторая часть «расшифрованного скрипта» – код, отвечающий за обработку результатов выполнения функций PluginDetect и загрузку подобранных эксплойтов с их последующим запуском.

В марте 2013 BlackHole использовал эксплойты к следующим уязвимостям:

1. версия Java от 1.7 до 1.7.х.8 – CVE-2012-5076;
2. версия Java меньше 1.6 или от 1.6 до 1.6.х.32 – CVE-2012-0507;
3. версия Java от 1.7.х.8 до 1.7.х.10 – CVE-2013-0422;
4. версия Adobe Reader меньше 8 – CVE-2008-2992;
5. версия Adobe Reader равна 8 или от 9 до 9.3 – CVE-2010-0188;
6. версия Adobe Flash от 10 до 10.2.158 – CVE-2011-0559;
7. версия Adobe Flash от 10.3.181.0 до 10.3.181.23 и меньше 10.3.181 – CVE-2011-2110.

Далее мы рассмотрим эксплойты к Java-уязвимостям.

 

Эксплойт к CVE-2012-5076

Эксплойт к CVE-2012-0507

Эксплойт к CVE-2013-0422

Три в одном

Таким образом, механизм работы этих трех Java-эксплойтов практически идентичен – они получают привилегии и запускают PayLoad, который загружает и запускает целевой файл. Совпадает и Java класс-файл, генерируемый каждым из трех эксплойтов. Это однозначно говорит о том, что за разработку этих эксплойтов отвечала одна и та же группа людей или один и тот же человек. Различается лишь способ получения неограниченных привилегий для класс-файла.

Этот класс-файл способен загружать и запускать файлы, расшифровывая передаваемые из расшифрованного скрипта параметры. Чтобы усложнить детектирование, загружаемый вредоносный файл обычно зашифрован и, соответственно, не начинается с PE-заголовка. Загруженный файл расшифровывается в памяти обычно с помощью алгоритма XOR.

Передача параметров из расшифрованного скрипта – это удобный способ быстро менять ссылки, по которым будет скачиваться полезная нагрузка, так как для этого необходимо лишь поменять информацию на стартовой странице эксплойт-пака без перекомпиляции самого вредоносного Java-апплета.

Три рассмотренные уязвимости относятся к так называемым logical flaw, т.е. ошибкам в логике. Вызов эксплойтов к таким уязвимостям невозможно контролировать автоматическими средствами, проверяющими, например, целостность памяти или генерацию исключений. Поэтому обнаружить данные эксплойты не помогут технологии DEP и ALSR от Microsoft и аналогичные автоматические средства. Однако есть технологии, способные справиться и с этой напастью – в частности, наш Automatic Exploit Prevention (AEP).

 

Защита от Java-эксплойтов

Несмотря на все усилия злоумышленников, современные защитные решения способны эффективно противостоять drive-by атакам, реализуемым с помощью эксплойт-паков. Как правило, для защиты от эксплойтов используется целый комплекс технологий, который позволяет отражать подобные атаки на разных этапах. 

Выше мы разобрали принцип работы эксплойт-пака BlackHole. Рассмотрим на примере решений «Лаборатории Касперского», как осуществляется защита на каждом этапе атаки с использованием Java-эксплойтов BlackHole. Поскольку другие эксплойт-паки работают по аналогичной BlackHole схеме, рассматриваемая нами схема защиты может считаться универсальной.

  
Рисунок 3. Схема поэтапной защиты от drive-by атаки

 

Итак, посмотрим, какие защитные компоненты, как и в какой момент времени взаимодействуют с вредоносным кодом.

 

Первый этап: блокирование перехода на лендинг

Атака начинается, как только пользователь переходит на лендинг эксплойт-пака. Однако веб-компонент антивируса может предотвратить атаку еще до ее начала, т.е. до запуска скрипта лендинга. Этот компонент защиты выполняет проверку адреса веб-страницы, на которую должен произойти переход. По сути, это простая проверка на наличие URL в базе вредоносных ссылок, но она позволяет заблокировать переход пользователя на стартовую страницу эксплойт-пака, если соответствующий адрес уже известен как вредоносный.

Задача антивирусных компаний в контексте этой проблемы – максимально быстро добавлять вредоносные ссылки в базу. Базы вредоносных URL могут располагаться как на компьютере пользователя, так и в «облаке» (т.е. на удаленном сервере). В последнем случае облачные технологии позволяют сократить до минимума интервал времени, в течение которого защитный продукт начинает блокировать новые вредоносные ссылки.  Уменьшается «время реакции» потому, что защитное решение на компьютере пользователя получает сведения о новой угрозе сразу же после появления соответствующей записи в базе опасных ссылок, при этом нет необходимости дожидаться очередного обновления антивирусной базы.

Злоумышленники, в свою очередь, стараются быстро менять домены, на которых расположены стартовые страницы эксплойт-паков, чтобы обойти блокировку этих страниц защитным ПО. В конечном итоге это снижает рентабельность их бизнеса.

 

Второй этап: детектирование файловым антивирусом

Если пользователь все же попал на лендинг, то в игру вступают компоненты файлового антивируса – статичный детектор и эвристический анализатор. Они проверяют стартовую страницу эксплойт-пака на наличие вредоносного кода. Разберём принцип работы, преимущества и недостатки каждого из компонентов.

• Статичный детектор использует статичные сигнатуры для обнаружения вредоносного кода. Такие сигнатуры срабатывают строго на определённые фрагменты кода, по сути – на конкретные последовательности байт. Этот метод обнаружения угроз использовался еще в первых антивирусах, и его преимущества хорошо известны – скорость работы и простота хранения сигнатур. Чтобы вынести вердикт, детектору достаточно провести сравнение полученной в ходе анализа контрольной суммы либо последовательности байт анализируемого кода с соответствующими записями в антивирусной базе. Используемые сигнатуры занимают по несколько десятков байт и могут упаковываться, поэтому их легко хранить. Самый большой минус статичного детектора – это простота «обхода» сигнатуры. Злоумышленникам достаточно заменить лишь один задействованный байт, и объект перестанет детектироваться. Из этого минуса следует и второй – для покрытия большого количества файлов необходимо большое количество сигнатур, что ведёт к значительному увеличению размера баз.
• Эвристический анализатор также использует сигнатуры, но работает по совершенно другому принципу. В его основе лежит анализ поступившего объекта: сбор и интеллектуальная обработка сведений об объекте, выявление в них закономерностей, подсчёт статистики и прочее. Если полученные в результате анализа данные удовлетворяют условиям эвристической сигнатуры, объект детектируется как вредоносный. Основное преимущество эвристической сигнатуры – возможность обнаружить сразу большое количество однотипных объектов, незначительно отличающихся друг от друга. Недостаток – по сравнению с обработкой статичных сигнатур эвристический анализатор может работать медленнее и замедлять работу системы. Например, если эвристическая сигнатура написана неэффективно, что выражается в большом количестве операций, необходимых для выполнения алгоритма проверки, это может не очень хорошо сказаться на быстродействии системы, где работает антивирус.

Чтобы избежать обнаружения объекта статичной сигнатурой, злоумышленникам необходимо как можно чаще вносить минимальные изменения в код объекта (скрипта, исполняемой программы, файла). Этот процесс можно в определённой степени автоматизировать.

Для обхода эвристического детектирования вирусописателю необходимо провести исследование, чтобы понять,  за счет чего происходит обнаружение объекта. Когда алгоритм частично или полностью разобран, в код вредоносного объекта надо внести изменения, препятствующие работе эвристической сигнатуры.

Очевидно, что на «обход» эвристической сигнатуры злоумышленнику нужно потратить больше времени, чем на сбой детекта статичной сигнатуры. А это означает, что «время жизни» эвристической сигнатуры больше. С другой стороны, после того, как вирусописатели вносят в детектируемый объект изменения для обхода эвристического детектирования, антивирусному вендору тоже приходится тратить некоторое время на создание другой сигнатуры.

Таким образом, антивирусное решение использует разные наборы сигнатур для проверки лендинга. В свою очередь, на стартовой странице эксплойт-пака вирусописатели производят модификации объектов, позволяющие обходить сигнатурное обнаружение обоих типов. Если для обхода статичных сигнатур злоумышленники просто разбивают строки на символы, то для обхода эвристик им приходится использовать тонкости языка JavaScript – необычные функции, сравнения, логические выражения и прочее. Пример соответствующей обфускации мы продемонстрировали в первой части статьи. На этом этапе часто происходит детектирование, особенно из-за чрезмерной обфускации кода, которая может рассматриваться как признак вредоносного объекта.

Помимо баз, хранящихся на жестком диске, существуют и сигнатуры, расположенные в «облаке». Обычно такие сигнатуры чрезвычайно просты, но экстремально короткое время реакции на новые угрозы (до 5 минут от создания сигнатуры до появления в облаке) обеспечивает качественную защиту компьютеров пользователей.

 

Третий этап: сигнатурное детектирование эксплойтов

Если защитное решение не смогло распознать стартовую страницу эксплойт-пака, последний приступает к работе. Он проверяет установленные в браузере плагины (Adobe Flash Player, Adobe Reader, Oracle Java, и т.д.) и принимает  решение загрузить и запустить определенные эксплойты. При этом защитное решение будет проверять каждый загружаемый эксплойт так же, как стартовую страницу пака – с помощью  файлового антивируса и облачных сигнатур. Злоумышленники в свою очередь применяют приёмы ухода от детектирования - аналогичные тем, что были описаны выше.

 

Четвертый этап: проактивное детектирование эксплойтов

В случае если ни один из компонентов реактивной (сигнатурной) защиты не обнаружил ничего подозрительного во время проверки содержимого эксплойт-пака, и эксплойт запустился, за дело берутся модули проактивной защиты. Они в реальном времени следят за тем, как те или иные приложения ведут себя в системе, и выявляют вредоносную активность.

Каждое приложение на основе эвристическсого анализа, облака и других признаков классифицируется как «Trusted», «Low Restrictions», «High Restrictions» или «Untrusted». «Контроль программ» осуществляет ограничение деятельности приложения в зависимости от присвоенного класса. Для класса «Trusted» разрешены все виды активности, для «Low Restrictions» запрещён, например, доступ к хранилищу паролей, приложениям категории «High Restrictions» запрещено вносить изменения в системные каталоги и т.д. Все запускаемые и работающие приложения анализируются с помощью модуля, который в нашем продукте называется «Контроль программ»  (Application Control). Этот компонент контролирует исполнение программ в системе с помощью низкоуровневых перехватов.

Кроме того, для распознавания опасного поведения программы используются специальные поведенческие сигнатуры, описывающие вредоносную активность. Поведенческие сигнатуры пишутся вирусными аналитиками и сравниваются с поведением работающего приложения. Это даёт возможность проактивной защите обнаруживать новые версии вредоносного ПО, которые не попали в категорию «Untrusted» или «High Restrictions». Стоит отметить, что такой тип детектирования наиболее эффективен, так как анализируются данные о реальной активности программы в настоящий момент, а не статический или эвристический анализ. В результате такие методы, как обфускация и шифрование кода становятся совершенно неэффективными, так как они никак не влияют на поведение вредоносной программы.

Для более тщательного контроля приложений, уязвимости в которых могут эксплуатироваться эксплойтами, мы используем технологию «Защита от эксплойтов» (Automatic Exploit Prevention). Компонент AEP осуществляет контроль запуска каждого процесса в системе. А именно – обрабатывает стек вызовов на наличие аномалий, проверяет код, вызвавший запуск процесса, и другое. Помимо этого, выборочно осуществляется проверка динамических библиотек, загружаемых в процесс.

Все эти действия позволяют предотвратить запуск вредоносных процессов в результате эксплуатации уязвимости эксплойтом. Фактически, это последний рубеж обороны, который обеспечивает защиту от эксплойтов в том случае, когда не сработали другие компоненты защиты. Если приложение, например Oracle Java или Adobe Reader, ведёт себя подозрительно в результате запуска эксплойта, то уязвимое легитимное приложение будет заблокировано антивирусом, что не позволит запуститься эксплойту.  

Поскольку на этом этапе проверяется поведение программы, для противодействия проактивной защите злоумышленникам необходимо использовать довольно сложные и трудоемкие методы.

 

Пятый этап: детектирование загруженных вредоносных программ (полезной нагрузки)

Если эксплойт все же остался незамеченным, он пытается загрузить и запустить на компьютере пользователя полезную нагрузку.

Как мы уже писали, чтобы усложнить детектирование, загружаемый эксплойтом вредоносный файл обычно зашифрован и, соответственно, не начинается с PE-заголовка. Загруженный файл расшифровывается в памяти обычно с помощью алгоритма XOR. Затем файл либо запускается из памяти (обычно это динамическая библиотека), либо дропается на диск и запускается с диска.

Трюк с загрузкой зашифрованного PE–файла позволяет сбить с толку антивирус, так как для него такая загрузка выглядит как обычный поток данных. Но важно то, что на пользовательской машине эксплойт будет запускать уже расшифрованный исполняемый файл. И антивирус прогонит этот файл через все возможные защитные технологии, которые мы описали выше.

 

Выводы

Эксплойт-паки — это комплексная система проникновения на компьютер жертвы. Злоумышленники прикладывают много усилий, чтобы поддерживать эффективность эксплойт-паков и сбивать детекты. В свою очередь, антивирусные компании совершенствуют системы защиты. В настоящее время у антивирусных вендоров существует набор технологий, позволяющий блокировать drive-by атаки на всех этапах, в том числе на стадии вызова эксплойтов к уязвимостям.

 

Источник