Взгляд на Silverlight эксплойт

[Prosper-H]

Оригинал: blog.trendmicro.com

Недавно, независимые исследователи обнаружили, что в Angler Exploit Kit был добавлен эксплойт для Silverlight использующий уязвимость CVE-2013-0074. Проанализировав имеющийся эксплойт, мы определили, что в дополнение к CVE-2013-0074, используется еще одна уязвимость CVE-2013-3896, которая предназначена для обхода ASLR. Эти уязвимости обсуждались в двух отдельных бюллетенях Microsoft, а именно в MS13-022 и MS13-087, соответственно.

Имеющийся эксплойт осуществляет проверку установленной версии Silverlight и выполняется только в том случае, если присутствовует одна из перечисленных ниже версий:

• 4.0.50401
• 4.0.60310
• 4.1.10329
• 5.0.61118
• 5.1.10411

Обновленные версии Silverlight не подвержены этому эксплойту, поэтому в данном случае ничего не происходило.


Методики противодействия анализу

Основным компонентом эксплойта является DLL-библиотека fotomaster.dll (MD5 hash: 5f36a4c019d559f1be9fdd0cd770be2e). Она представляет из себя PE-файл, который содержит MSIL (Microsoft Intermediate Language) код, что собственно и ожидается от приложения, написанного для Silverlight. Мы определяем её как TROJ_EXPLOIT.SVL. Эксплойт загружается с вредоносного сайта с помощью Silverlight приложения. Когда приложение загрузится, будет загружена fotomaster.dll и будет выполнен её MSIL-код.

Так же эксплойт использует несколько техник для предотвращения анализа. Они включают в себя:

Предотвращение декомпиляции

Как правило, первым шагом, при реверс-инжиниринге .NET файлов, является восстановление (декомпиляция) исходного кода. Это необходимо, чтобы понять логику исследуемого приложения. Однако, наш эксплойт имеет обфусцированный код. Это приводит к тому, что стандартные инструменты декомпиляции, терпят неудачу. Это можно видеть на рисунке ниже:

Рис 1. Failed decompilers

Предотвращение дизассемблирования

Если .NET приложение не может быть декомпилированно, его дизассемблируют в MSIL-код. Для этого в .NET SDK есть утилита ildasm.exe. Тем не менее, Microsoft сама предоставила технику, которая препятствует этому.

Рис 2. Failed disassembler

Обфускация кода и имен переменных

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


Анализ эксплойта

Используемые уязвимости

Как уже упоминалось ранее, в эксплойте используется две отдельные уязвимости Silverlight. Первая, CVE-2013-3896, является уязвимостью утечки информации (information leak), которая может быть использована для утечки важной информации из памяти. Эксплойт использует эту уязвимость для утечки указателя на адрес в памяти, после чего использует полученный адрес для вычисления базового адреса (base address) mscorlib.ni.dll, чтобы обойти ASLR. Позже, этот же адрес используется для вычисления ROP-гаджета для обхода DEP.

Вторая уязвимость, CVE-2013-0074, является уязвимостью двойного разыменования указателя (double-dereference vulnerability), которая используется для передачи управления на ROP-гаджет.

ROP-гаджет

Вместо того, чтобы использовать цепочку ROP-гаджетов, как это делают многие другие эксплойты, этот эксплойт содержит единственный ROP-гаджет, как показано ниже:

Code: ASM

83493440        or      dword ptr [ecx+34h],40h

b801000000      mov     eax,offset <Unloaded_pi.dll> (00000001)

ret     4

Этот ROP-гаджет предназначен для воздействия на поле Lenght .NET массива uint. После его выполнения, длина массива станет очень большим значением (0x40000003). В дальнейшем, это позволяет читать / писать в почти произвольную память адресного пространства процесса. Подобная техника, перезаписи длины буферов, хорошо известна в эксплойтах для Adobe Flash, Java и Internet Explorer.

Шеллкод

После изменения длины массива, эксплойт использует его для поиска адресного пространства процесса, чтобы найти некоторую исполняемую память (в области кода JIT-compiled функции). Затем копирует шеллкод в область исполняемой памяти и выполняет его. Сам шеллкод динамически ресолвит необходимые API и загружает payload с сервера, вызывая API из wininet.dll, как показано ниже:

Рис 3. Shellcode

Silverlight и Java

На сегодня Java является излюбленной целью для эксплойт паков. Тем не менее, существует много общего между Java и Silverlight:

• Оба являются языками, основанными на виртуальной машине (Java-байткод vs MSIL-код)
• Оба могут быть встроены в веб-страницу и выполнятся удаленно.
• Оба запускаются в песочнице (sandbox), которая основана на динамической проверке привилегий в критических библиотечных функциях. Запускаясь в браузере оба выполняются с пониженными привилегиями.
• Оба требуют поломки песочницы для создания эксплойта.

В будущем не исключено появление других эксплойтов для Silverlight, но в массовых атаках они вряд ли будут рассматриваться, ввиду превосходящего проникновения на рынок Java эксплойтов. Тем не менее, для целевых атака, они действительно предлагают заманчивую цель. Мы продолжим следить за угрозами, связанными с другими Silverlight угрозами.

© Translated by Prosper-H from r0 Crew