книги хакеры / журнал хакер / 186_Optimized

Взлом

0DAY ťśŦśťŤšţśţŞśŗũŪśŦŖŘADOBE FLASH PLAYER ŘŠŤŢťŤţśţŨśPIXEL BENDER

CVSSv2: 10.0 (Av:R/Ac:L/A:N/C:C/I:C/A:C)

Дата релиза: 28 апреля 2014 года

Автор: неизвестен, @ohjeongwook CVE: 2014-0515

В середине апреля «Лаборатория Касперского» получила несколько Flashфайлов. Причем один из них был ранее задетектирован обычной эвристикой (удивительно, но кто-то до сих пор использует стандартные шелл-коды при атаках нулевого дня).

Уязвимость находится в обработчике компонента Pixel Bender. Помимо этого, он больше нигде не используется, но до сих пор поддерживается

в Flash Player. Как предполагают аналитики из ЛК, злоумышленники тем самым надеялись, что уязвимость в старом компоненте еще долго будет оставаться непропатченной.

Проанализировать вредоносный SWF-файл можно в SWF Investigator (bit. ly/1le4jTu) или SWFTools. SWF Investigator — официальная утилита от Adobe,

помогает быстро анализировать и выполнять небольшие куски ActionScriptкода. Это выручает, например, при восстановлении шелл-кода или другого зашифрованного SWF-файла в анализируемом. SWFTools же представляет собой просто набор консольных утилит для работы с SWF-файлами. В нашем случае мы будем использовать SWFDump.

После загрузки сэмпла обрати внимание на какие-то бинарные данные под тегом Definery Binary, это и есть атакующий набор данных.

Как и многие Flash-эксплойты, наш испытуемый начинается с технологии heap spray. Похожую ситуацию мы наблюдали в CVE-2014-1776 уязвимости для IE. В нашем случае эксплойт также использует тип данных Vector для получения контроля над областью памяти и данных, но есть несколько отличий.

Обзор эксплойтов

Взлом

8

13

14

9

15

10

Обзор эксплойтов

DWORD-значение на смещении 0xEA Pixel Bender, которое выступает триггером уязвимости.

Для того чтобы проанализировать, как эта область вызывает ошибку в коде обработчика Pixel Bender, воспользуемся утилитой dpbj (bit.ly/1sd3Eai), которая поможет отреверсить формат файла Pixel Bender. Автор также выложил исходный код этой программы, но нам будет достаточно исполняемого файла. Стоит заметить, что этот проект может очень помочь

висследовании, так как хорошая публичная документация по внутреннему формату Pixel Bender недоступна.

После того как мы загрузим данные, сразу поймем, где находится часть, которая вызывает падение (рис. 7).

Метаданные defaultValue должны быть только четырехбайтовыми, но этот код пытается конвертировать все 16 аргументов и поместить их в область памяти, тем самым вызывая ее повреждение.

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

Код, перезаписывающий область sel instruction, представлен на рис. 9. FSTP-инструкция сохраняет значение в области памяти этого операнда. В нашем случае оригинальное значение 0x000B3880 после изменения сохраняется напрямую в 0x000B3880. Инструкция 0x167EC63 показывает, что память будет увеличена на 0x14. Первый элемент defaultValue находится внутри правильной области памяти, но значение из второго аргумента лежит внутри памяти sel instruction.

Помимо первого повреждения памяти для замещения других инструкций байт-кода, существует второе. Поврежденный байт-код интерпретируется и запускается. Сам же код, ответственный за интерпретацию байт-кода в опкод, представлен на рис. 10.

Вкоде на рис. 11 каждый операнд инструкции обрабатыва-

ется функцией set_array_value.

Теперь посмотри рис. 12. На нем представлен код, который повреждает память второй раз. Функция вызывается для каждой инструкции, и когда повреждение проходит успешно, то значение arg_index становится равным 0x000B3880, которое пришло из поврежденной области памяти. Значение индекса преобразовывается в смещение в памяти и используется позже, чтобы сохранить некоторые данные. Из инструкции 0x0167BC78, видим, что ecx указывает на структуру данных

впамяти, а edi — на смещение, высчитанное из arg_index. Значение регистра eax — это небольшой битовый трюк.

Значение возвращается из предыдущего вызова sub_1909EE0, которое возвращает указатель на память.

Но более интересные вещи происходят дальше. Из ecx (базовый указатель), edi (смещение) и eax (значение, которое меняется по ходу выполнения) атакующий может контролировать, конечно же, edi. Также, в результате использования описанной выше техники heap spray, большая часть памяти забита дырами размером 0x88. Структура данных, на которую указывает ecx, имеет размер меньше 0x88, и с большой вероятностью указатель будет указывать на одну из наших дыр в области heap spray. Поэтому в итоге атакующий может контролировать ecx и edi.

Но вот eax может быть случайным (хотя и правильным) местом памяти в куче. Атакующий не может контролировать его. Правда, в итоге атакующему это и не нужно. Eax всегда будет правильным указателем, но при этом его значение будет больше, чем диапазон значений (возможно, даже больше, чем 0x22+1). На рис. 13 показано, как выглядит память перед ее повреждением.

Далее ты можешь увидеть, что длина поля a[x+1] перезаписывается значением указателя. Значение может быть рандомным, но не больше, чем 0x22+1. Такая ситуация позволяет атакующему повредить длину поля следующего Vector.

Теперь значение ax+1 (.length имеет значительную величину. То есть, помимо возможности повредить дополнительные элементы Vector, это даст нам полный контроль над памятью процесса. Следующий код повредит длину поля Vector

до 0x40000001 (corrupt_index = x + 1):

var vector_size:uint = 0x22; a[corrupt_index][vector_size] = 0x40000001;

Теперь a[x+2].length становится равной 0x40000001.

На рис. 15 ты можешь увидеть этап, когда все дополнительные повреждения успешно закончились. В итоге из a[x+2] эксплойт может использовать произвольный индекс для доступа к любому месту памяти.

Эксплойт создает 64 FileReference объекты в куче.

var b:Array = new Array();

i = 0;

while(i < 64)

{

b[i] = new FileReference();

i++;

}

Далее ищем для каждого объекта FileReference из кучи место, подходящее нам, чтобы перезаписать указатель функции. Например, если мы запишем v = a[x+2], то адрес v[2] будет указателем функции. Область памяти вокруг этой ложной функции можно представить на ActionScript следующим образом:

var aaak:uint = this.aaal(v, opened_up_vector_pos);

var aaam:uint = this.read_memory(v,

opened_up_vector_pos, aaak + 32);

var aaao:Boolean = true;

var fake_func_ptr1:uint = 0;

var fake_func_ptr2:uint = 0;

if(aaao)

{

fake_func_ptr = this.search_fake_func_ptr

(v, opened_up_vector_pos);

fake_func_ptr1 = fake_func_ptr[0];

fake_func_ptr2 = fake_func_ptr[1];

shellcode_array =

this.allocate_vector_array_with_values

(0x45454545, 0x90909090);

shellcode_array_address =

this.search_vector_array

(v,opened_up_vector_pos, 0x46464646);

this.build_shellcode(shellcode_array,

shellcode_array_address,

file_reference_obj_addr);

v[7] = fake_func_ptr1 + 0;

v[4] = fake_func_ptr2;

v[0] = 4096;

v[1] = shellcode_array_address & 0xFFFFF000;

Теперь эксплойт может контролировать данные для указателей на объекты FileReference. Поиск нужного места ведется с помощью эвристического метода, и когда подходящее обнаруживается, то адрес с таблицей указателей заменяется на ложный. Полученная ложная таблица с аргументами представлена на рис. 17. v[7] становится указателем после вызова метода cancel. Код вызова метода довольно банален:

i = 0;

while (i < 64) {

b[i].cancel();

i++;

}

Дизассемблированный код, на который указывал аргумент v[7], представлен на рис. 18.

Эта функция использует аргументы из таблицы указателей. Eax указывает на местонахождение v2 ( после вызова. Инструкции 0x6EB8D5D8 и 0x6EBD5DB показывают, что использовались два аргумента из eax-8(v0 () и eax(v[1]), которые были интерпретированы как размер и адрес памяти.

Далее происходит вызов функции call_virtual_protect, что в конечном итоге вызовет VirtualProtect API и даст права на выполнение кода в нужной области памяти. Повторное ис-

Рис. 6. Начало Pixel Bender данных — триггера уязвимости

Рис. 7. Pixel Bender

код, вызывающий уязвимость

Рис. 8. Повреждение памяти

Рис. 9. Код для повреждения памяти

Рис. 10. Перевод байткода в опкод

Рис. 11. Код, устанавливающий значения регистров

Рис. 12. Код для второго повреждения памяти

Рис. 13. Базовый адрес, указывающий на одну из heap spray

дыр размером 0x88

Рис. 14. После повреждения памяти a[x+1 (.length будет равна большому значению

Рис. 15. Память после повреждения дополнительных длин полей

Vector

Взлом

18

param1[_loc4_][12] = 3.847464024E9;

param1[_loc4_][13] = 10984;

param1[_loc4_][14] = 3.197145088E9;

param1[_loc4_][15] = param3;

param1[_loc4_][16] = 1749052048;

Следующий код заменяет указатель функции для метода cancel внутри ложного объекта FileReference и запускает его.

Или IE с библиотеками определенных версий:

'BrowserRequirements' =>

{

:source => /script/i,

:os_name => OperatingSystems::WINDOWS,

:ua_name => HttpClients::IE,

:ua_ver => "9.0",

:os_flavor => "7",

Взлом