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

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

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

Хакер, номер #101, стр. 052

Сегодняшний обзор эксплойтов мы посвятим Windows Vista, количество дыр в которой, несмотря на все заявления Microsoft, довольно значительно, и многие из них критические (а ведь поставки Висты только начались). Microsoft едва успевает выпускать заплатки, а хакеры тем временем находят все новые и новые дыры.

GDI: локальное повышение привилегий

Brief

Графическая подсистема Windows (GDI) продолжает оставаться одной большой дырой, значительная часть которой интегрирована в ядро и реализована в драйвере win32k.sys. Однако GDI активно использует адресное пространство пользовательского процесса, помещая все элементы интерфейса (такие, например, как окна) в специальные объекты-секции, защищенные от непреднамеренной записи со стороны пользовательского приложения, но допускающие умышленное проецирование секции на другой регион с атрибутами записи. Также существует возможность «повторного» выделения блока памяти внутри секции с присвоением ему необходимых атрибутов. Впервые это было обнаружено в далеком 2004 году хакером по имени Cesar Cerrudo. А чуть позже появился GDIKernelPoC-exploit, находящий GDI-объекты тупым перебором обработчиков (handles) и ставящий на то, что первый же найденный обработчик и есть указатель на секцию с GDI-объектом. Это справедливо для Windows 2000 с XP, но Виста и 2003 Server реализованы немного иначе, и потому GDIKernelPoC-exploit на них не работает. Joel Eriksson усовершенствовал технику поиска GDI-секции путем введения дополнительных проверок на соответствие размеров найденного блока минимально возможному размеру таблицы GDI, а также анализу полей nUpper, ProcessID и nType, значения которых известны заранее. Создав в результате модель эксплойта, пробивающую защиту Server 2003 и Виста, он выступил с ней на последней конференции Black Hat.

Targets

Уязвимости подвержены все платформы линейки NT до Windows Виста включительно.

Exploit

Исходный код эксплойта на Си, написанный хакером Ivanlef0u, можно скачать с www.milw0rm.com/exploits/3688. Он содержит shell-код, исполняющийся в режиме ядра и получающий управление путем модификации таблицы системных вызовов (SSDT). Это proof-of-concept exploit, всего лишь перезагружающий машину, однако shell-код может быть доработан, и тогда…

Solution

Microsoft не только не предоставила заплатку, но даже не обозначила сроки ее появления в обозримом будущем. Так что эта дыра обещает стать весьма продуктивной лазейкой для хакеров и всяких прочих червей.

CSRSS: множественные уязвимости

Brief

CSRSS (Client/Server Runtime Subsystem) – клиент-серверная подсистема времени выполнения, реализованная в процессе csrss.exe. Это важнейший компонент архитектуры Windows NT, обеспечивающий работу всех установленных подсистем, которых изначально было три: POSIX, OS/2 и win32. Но OS/2 уже давно сдулась; POSIX, реализованная нелучшим образом, никогда не входила в штатную поставку Windows и постепенно исчезла как никому не нужный костыль. В результате этого осталась единственная подсистема — win32, которая позднее (начиная с NT 4) была интегрирована в ядро, и за csrss.exe остались лишь консольные приложения и управление потоками. Тем не менее, с точки зрения хакеров, процесс csrss.exe представляет значительный интерес хотя бы уже потому, что он исполняется с привилегиями SYSTEM и обладает правами отладки, а завершение процесса csrss.exe приводит к появлению голубого экрана смерти. Практически сразу после выхода Висты в CSRSS обнаружились сразу три критических ошибки, позволяющие завешивать систему, повышать локальные привилегии и даже выполнять удаленный shell-код.

Первая ошибка, найденная хакером по кличке NULL, описана на www.securityfocus.com/bid/21688 и сидит внутри функции NtRaiseHardError, которая при передаче ей стартового адреса одного из потоков csrss.exe обрушивает систему. Вторая ошибка, обнаруженная компанией eEye Digital Security, связана с процедурами удаленного вызова LPC/ALPC, позволяющими приложениям взаимодействовать через ApiPort'ы, допускающие повторное открытие. Однако в LPC-коде присутствует ряд мест, ничего не знающих ни о каких счетчиках и уверенных, что LPC-соединение может быть установлено только однажды. Одним из таких мест является функция CsrApiRequestThread, экспортируемая библиотекой CSRSRV.DLL и позволяющая манипулировать чужими LPC-соединениями, что в конечном счете приводит к повышению привилегий. Технические подробности содержатся в отчете eEye: www.securityfocus.com/archive/1/465233. Третья ошибка, обнаруженная Tim'ом Garret'ом, сидит в библиотеке WINSRV.DLL (так же относящейся к CSRSS) и при выводе диалоговых окон с сообщениями о «тяжелых» ошибках (HardError-messages) может выполнить произвольный код, переданный как локально, так и удаленно. Подробности об этом можно почитать на www.securityfocus.com/bid/23324/info.

Targets

Уязвимы практически все системы линейки NT, включая Microsoft Windows Vista x64 Edition 0, Vista Ultimate и т.д.

Exploits

В сети уже появилось множество эксплойтов, использующих эти уязвимости. Вот только малая часть их них:

Solution

Microsoft выпустила заплатки для всех трех дыр. Поэтому для защиты своего компьютера достаточно скачать последние обновления (по умолчанию система это делает автоматически).

Windows Genuine Advantage: взлом через OEM BIOS

Brief

Windows Genuine Advantage (сокращенно WGA) – самый мерзкий компонент Windows, ответственный за проверку подлинности регистрационных ключей, привязывающийся к железу и требующий повторной активации при его замене, что напрягает не только любителей халявы, но и обладателей лицензионных копий. Являясь в связи с этим соблазнительным объектом атак, WGA уже давно и с треском взломан, несмотря на яростное сопротивление со стороны Microsoft, которая, вместо того чтобы думать головой, угрожает хакерам судебными исками. Но для этого их (хакеров) сначала надо найти!

Очередной метод взлома базируется на том факте, что ряд крупных OEM-поставщиков отказались от предустановки Висты, раздражающей пользователей своей глупой активацией, и стали коситься в сторону лагеря Linux и BSD. Microsoft тут же пошла на уступки и включила в Висту специальный код, проверяющий BIOS на принадлежность к определенному кругу OEM-поставщиков (с которыми Microsoft заключила специальное соглашение) и в подобном случае не требующий активации. Хакеры тут же дизассемблировали код и выяснили, что WGA ищет в BIOS'е специальную идентификационную строку, находящуюся в boot-блоке и проецирующуюся в адресное пространство ЦП. Одни, лихие головы, тут же кинулись перешивать BIOS'ы, рискуя угробить компьютер, в то время как другие внедрили в загрузчик операционной системы специальную программу, проецирующую boot-блок в оперативную память и уже там, в памяти, дописывающую подходящую идентификационную строку. Третьи же пошли по пути перехвата системных функций, читающих BIOS и возвращающих результат «ОК» или «не ОК». Короче, вариантов взлома полно — выбирай!

Targets

Все версии Висты: Microsoft Windows Vista x64 Edition 0, Vista Ultimate, Vista Home Premium, Vista Home Basic, Vista Enterprise, Vista Business и Windows Vista 0.

Exploits

Microsoft ведет борьбу со всеми, кто отваживается выложить код (неважно, исходный или откомпилированный) «ломалки» в сеть, поэтому линки постоянно меняют адреса и мрут как мухи, зачастую не продержавшись и нескольких часов. То же самое относится и к списку идентификационных строк.

Solution

Купить лицензионную версию Висты.

ANI-формат: удаленное переполнение буфера

Brief

В 2005 году компания eEye Digital Security обнаружила классическое переполнение буфера в функциях, обрабатывающих анимированные курсоры (ANI), уведомила Microsoft и выпустила свою собственную заплатку, не дожидаясь выхода официального обновления. Microsoft исправила ошибку, но полного аудита кода, естественно, не проводила. И вот в конце марта 2007 года та же самая компания eEye Digital Security выловила в дикой природе несколько атакующих программ, работающих по схожему принципу и поражающих XP SP2 вместе с только что вышедшей Вистой. eEye Digital Security снова уведомила Microsoft и выпустила обновленную версию своей заплатки вместе с исходными текстами. На их основе хакер по кличке devcode, со ссылкой на CVE 2007-1765, создал proof-of-concept exploit, попавший на milw0rm (www.milw0rm.com/exploits/3617). Затем последовал эксплойт от хакера marsu, заявившего, что эксплойт от devcode у него не работает. Эксплойту от marsu удалось засветиться на Security Focus (www.securityfocus.com/bid/23373) и milw0rm (www.milw0rm.com/exploits/3647), завешивая множество приложений: World, WinAmp, проводник и IE (последний - только при отключенном DEP'е). Тем не менее, уязвимости был присвоен «локальный» статус, и некоторое время ей не уделяли никакого внимания. Затем последовал бум эксплойтов, работающих даже при активном DEP'е (www.milw0rm.com/exploits/3652). Это позволило атаковать Висту с настройками по умолчанию путем посылки письма с анимированным курсором внутри или размещением этого же курсора на web-страничке, посещаемой жертвой. Тогда же появились эксплойты, пробивающие заплатку от eEye (www.milw0rm.com/exploits/3636), за которыми последовал готовый генератор эксплойтов (www.milw0rm.com/exploits/3651), и атаки возобновились с новой силой. Компания Zert, проанализировав ситуацию, установила, что заплатка от eEye исправляет лишь часть уязвимого кода, оставляя другую часть нетронутой. Заплатка, выпущенная компанией Zert, полностью ликвидировала уязвимость, заткнув течь (http://zert.isotf.org/advisories/zert-2007-01.htm), а через некоторое время вышло внеплановое официальное обновление от Microsoft, по умолчанию устанавливающееся на Висту в автоматическом режиме. Но, учитывая, что достаточно многие пользователи предпочитают скачивать обновления вручную (то есть не скачивать их вообще) и что данная уязвимость затрагивает не только Висту, но и всех ее предшественниц из линейки NT, атаки закончатся еще не скоро. Поэтому имеет смысл остановиться на этой дыре и рассмотреть ее поподробнее.

Targets

Все версии Висты: Microsoft Windows Vista x64 Edition 0, Vista Ultimate, Vista Home Premium, Vista Home Basic, Vista Enterprise, Vista Business и Windows Vista 0.

Exploits

Solution:

Официальное обновление от MS.

Full disclose

Анимированные курсоры хранятся в файлах с расширениями ani, cur и ico, которые представлены в RIFF-формате (Resource Interchange File Format — файловый формат для обмена ресурсами) и имеют тэговую структуру, состоящую из порций данных произвольного типа, называемых «чанками» (от английского «chunk» – «ломоть», «большой кусок»). RIFF-формат неплохо документирован и, помимо анимированных курсоров, используется для хранения аудио- и видеоданных. Примерами RIFF являются avi, wav и midi-файлы.

За анимированным курсором закреплен тэг «anih» (61h 6Eh 69h 68h), а сам чанк имеет следующую структуру:

Структура чанка «anih»

struct ANIChunk

{

char tag[4]; // ASCII-тэг «anih»

DWORD size; // длина чанка в байтах

char data[size]; // данные, описывающие «раскладку» курсора в файле

}

Образцы правильных анимированных курсоров можно выдернуть из штатной поставки Windows (они расположены в папке \WINNT\Cursors\). Ниже приведен фрагмент одного из них:

Фрагмент дампа анимированного курсора coin.ani, позаимствованный из штатного комплекта поставки Windows

0000000000: 52 49 46 46 C2 1B 00 00 ? 41 43 4F 4E 4C 49 53 54 RIFF?? ACONLIST

0000000010: 48 00 00 00 49 4E 46 4F ? 49 4E 41 4D 0E 00 00 00 H INFOINAM?

0000000020: 53 70 69 6E 6E 69 6E 67 ? 20 43 6F 69 6E 00 49 41 Spinning Coin IA

0000000030: 52 54 26 00 00 00 4D 69 ? 63 72 6F 73 6F 66 74 20 RT& Microsoft

0000000040: 43 6F 72 70 6F 72 61 74 ? 69 6F 6E 2C 20 43 6F 70 Corporation, Cop

0000000050: 79 72 69 67 68 74 20 31 ? 39 39 33 00 61 6E 69 68 yright 1993 anih

0000000060: 24 00 00 00 24 00 00 00 ? 09 00 00 00 09 00 00 00 $ $ ? ?

0000000070: 00 00 00 00 00 00 00 00 ? 00 00 00 00 00 00 00 00

0000000080: 02 00 00 00 01 00 00 00 ? 4C 49 53 54 3A 1B 00 00 ? ? LIST:?

0000000090: 66 72 61 6D 69 63 6F 6E ? FE 02 00 00 00 00 02 00 framicon?? ?

Несмотря на то что, по спецификациям от Microsoft, поле data может иметь произвольную (и формально ничем не ограниченную) длину, программисты из Microsoft своих собственных спецификаций не читают, размещая в dat'е структуру, состоящую ровно из 24h байт. Их функция user32.dll!LoadCursorIconFromFileMap, вызываемая из функции user32.dll!LoadAniIcon, копирует в буфер фиксированного размера посредством функции memcpy(dst, src, size), без всяких проверок size на корректность размера!

Естественно, если size больше 24h, происходит классическое стековое переполнение с подменой адреса возврата и возможностью передачи управления на shell-код, находящийся здесь же, в массиве data. Для предотвращения переполнения компания eEye модифицировала функцию LoadCursorIconFromFileMap (псевдокод которой приведен ниже), добавив явную проверку на размер. Точно так же поступала и Microsoft в своей заплатке, выпущенной под кодовым названием MS05-002.

Исправленный псевдокод уязвимой функции LoadCursorIconFromFileMap, читающий чанки из анимационных файлов

int LoadCursorIconFromFileMap(struct MappedFile* file, ...)

{

struct ANIChunk chunk;

struct ANIHeader header; // 24h-байтовая структура

...

// читаем первые 8 байт чанка (в них расположен ASCII-тэг)

ReadTag(file, &chunk);

// это наш тэг «anih»?

if (chunk.tag == "anih")

{

// проверяем размер на корректность

+ if (chunk.size != 36) // добавлено MS05-002 и eEye

// если размер != 24h, отваливаем

+ return 0;

// читаем чанк в локальный буфер фиксированного размера

ReadChunk(file, &chunk, &header);

}

Однако оказалось, что, если в файле присутствует более одного «anih»-чанка, второй и все последующие чанки обрабатывает совершенно другой код, сосредоточенный в функции USER32.DLL!LoadAniIcon и, естественно, работающий по той же схеме, что и первый (то есть никаких проверок не выполняющий), поскольку программисты из Microsoft уже давно освоили метод copy’n’paste, а выполнять аудит всего кода лень, да и времени нет:

Псевдокод уязвимой функции LoadAniIcon, обрабатывающий второй и все последующие «anih»-чанки

int LoadAniIcon(struct MappedFile* file, ...)

{

struct ANIChunk chunk;

struct ANIHeader header; // 24h-байтовая структура

...

while (1)

{

// читаем первые 8 байт чанка (в них расположен ASCII-тэг)

ReadTag(file, &chunk);

// в зависимости от типа тэга делаем либо то, либо другое

switch (chunk.tag)

{

case 'seq ': // обрабатываем тэг «seq» ...

case 'LIST': // обрабатываем тэг «LIST»

...

case 'rate': // обрабатываем тэг «rate»

...

case 'anih': // обрабатываем тэг «anih»

// читаем chunk.size в 24h-байтовую структуру

ReadChunk(file, &chunk, &header);

Таким образом, чтобы пробить заплатку от eEye или официальный патч MS05-002 от Microsoft, необходимо поместить в ani-файл два чанка: правильный и вызывающий переполнение.

Дамп одного из таких файлов приведен ниже. Он не несет на своем борту никакого shell-кода и «всего лишь» вызывает исключение при попытке просмотра анимированного курсора любым приложением, поддерживающим этот формат, например знаменитым Irfan Viewer:

Полный дамп ani-файла, пробивающего заплатку от eEye вместе с официальным патчем MS05-002 от Microsoft

00000000 52 49 46 46 90 00 00 00 41 43 4F 4E 61 6E 69 68 RIFF....ACONanih

00000010 24 00 00 00 24 00 00 00 02 00 00 00 00 00 00 00 $...$...........

00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030 00 00 00 00 01 00 00 00 61 6E 69 68 58 00 00 00 ........anihX...

00000040 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

00000050 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

00000060 00 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 .AAAAAAAAAAAAAAA

00000070 41 41 41 41 41 41 41 41 41 41 41 41 00 00 00 00 AAAAAAAAAAAA....

00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000090 42 42 42 42 43 43 43 43 BBBBCCCC

А что на счет Internet Exporer? Его, в отличие от Irfan Viewer, заставить выполнять shell-код не так-то просто. Помимо всего прочего, необходимо обойти защиту от выполнения кода в стеке (известную под кодовым именем DEP – Data Execution Prevention), обхитрить механизм рандомизации адресного пространства (ASLR – Address space layout randomization) и преодолеть проверку целостности адреса возврата, выполняемую функцией при трансляции программы компилятором Microsoft Visual C++ 7.x с ключом /GS.

DEP, ASLR и /GS – вот три причины, по которым большинство эксплойтов отказывается работать на Висте, функционирующей на процессоре с поддержкой флагов NX/XD (аппаратный DEP). Все эти защиты достаточно легко обойти (впрочем, как и все остальное, сделанное Microsoft), но это уже тема совершенно другого разговора. Любопытствующих отсылаю к сборнику моих статей (http://nezumi.org.ru/vista-overstack-pack.zip), подробно рассматривающих методику борьбы со всей «святой троицей».

WWW

Содержание