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

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

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

Хакер, номер #107, стр. 107-050-1

Виста захватывает рынок ударными темпами, а тут еще обозначился Server 2008 RC0, позиционируемый как самая безопасная ось из всех существующих, что плохо согласуется с действительностью. Количество ошибок, обнаруживаемых как в самой системе, так и во входящих в ее состав прикладных компонентах, неуклонно растет, причем практически все ошибки критические, то есть допускающие возможность удаленного захвата управления.

Виста/Server 2008: ARP-атака на отказ в обслуживании

Brief

В начале апреля 2007 года сотрудники исследовательского центра корпорации Symantec Dr. James Hoagland, Matt Conover, Tim Newsham и Ollie Whitehouse провели анализ нового сетевого стека ранних бет Висты и нашли огромное количество ошибок, часть из которых была исправлена Microsoft, а часть благополучно перекочевала в финальную версию Висты и... Server 2008 Release Candidate, выпущенный в октябре 2007 года. В частности, если отправить жертве специальный ARP-пакет, насильно прописав в поле отправителя адрес получателя, система рухнет и будет лежать до тех пор, пока администратор не перезагрузит тачку или не перенастроит ARP-таблицы вручную. При этом хакер должен находиться внутри локальной сети или в пределах досягаемости беспроводных устройств, что очень полезно для атак на WI-FI-кафе и прочие заведения. Более подробную информацию об этом можно получить на www.securityfocus.com/bid/23266.

Targets

Microsoft Windows Vista December CTP, Ultimate, Home Premium/Basic, Enterprise, Business, beta 0/beta 1/beta 2, Server 2008 Enterprise/Datacenter Edition RC0.

Exploit

Боевая версия эксплойта, написанная на Питоне, заточенная хакером по кличке Kristian Hermansen (при содействии товарищей Newsham'а и Hoagland'а), лежит на downloads.securityfocus.com/vulnerabilities/exploits/Microsoft_Vista_ARP_DoS_exp.py, но, прежде чем она зафурычит, придется изрядно потрудиться. Во-первых, необходимо скачать библиотеку Scapy, предназначенную для хакерских манипуляций с пакетами (она бесплатна и доступна по адресу www.secdev.org/projects/scapy). Во-вторых, под XP она функционировать все равно не будет, поскольку XP (с установленной заплаткой безопасности MS05-019) вообще не поддерживает сырые сокеты (RAW SOCKETS), через которые и работает Scapy. А вот горячо любимая мной W2K поддерживает сырые сокеты в полном объеме, равно как xBSD, Linux, Mac OS X и другие «правильные» системы, в том числе и Server 2003 с отключенным брандмауэром (net stop alg). Причем во всех этих случаях мы должны обладать правами root'а/администратора. Как вариант - можно установить бесплатную библиотеку WinPCAP (www.winpcap.org), возвращающую XP должную функциональность, но она имеет свой интерфейс (для согласования с которым придется дорабатывать Scapy), и к тому же на пакеты, переданные через PPP-соединения, все равно наложены суровые ограничения. Так что XP идет лесом, уступая место W2K/Linux/xBSD. На диске ты найдешь ключевой фрагмент эксплойта с моими комментариями, а пока рекомендую почитать следующие материалы по Scapy: pacsec.jp/psj05/psj05-biondi-en.pdf, www.secdev.org/conf/scapy_lsm2003.pdf и www.secdev.org/projects/scapy/files/scapydoc.pdf.

Solution

Да ну на хрен эту Висту и Server 2008 вместе с ней! Короче, в переводе с албанского: заплаток пока нет, и когда они появятся - неизвестно.

MS Outlook Express/Mail: удаленное переполнение кучи

Brief

Хотя сабжевые продукты соотносятся с операционной системой так же, как я с панталонами, они входят в состав Windows, и туева хуча юзеров пользует их, упорно не признавая The Bat. И вот 9 октября 2007 года Greg MacManus из исследовательской лаборатории VeriSign iDefense Labs обнаружил, что практически все версии Outlook и Windows Mail некорректно обрабатывают команду XHDR протокола NNTP (News Network Transfer Protocol), подробно описанную в RFC-2980: «Common NNTP Extensions» (www.ietf.org/rfc/rfc2980.txt), в результате чего происходит переполнение кучи с возможностью передачи управления на shell-код. Протокол NNTP используется для чтения новостей (a-ля Фидо), то есть практически никак не используется, поскольку с появлением web-форумов NNTP-серверы ушли в подполье, оставшись уделом энтузиастов. Однако почтовые клиенты все еще продолжают поддерживать их, а браузеры воспринимают префикс «news://» как команду вызова встроенного/внешнего NNTP-клиента, которым у IE по умолчанию является Outlook Express, то есть пользователь может быть атакован через URL, переданный, например, с помощью электронной почты. За подробностями обращайся по следующим адресам: https://strikecenter.bpointsys.com/articles/2007/10/10/october-2007-microsoft-tuesday, http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=607, а также www.securityfocus.com/bid/25908.

Targets

Уязвимость затрагивает Microsoft Windows Mail 0 (входящий в состав Microsoft Windows Vista/Vista x64 Edition), а также Microsoft Outlook Express 5.5 SP2/6.0/6.0 SP1 (входящий в состав W2K и XP), так что угроза очень серьезная!

Exploit

Команда XHDR передает клиенту заданное количество заголовков статей, однако по умолчанию Outlook Express и Windows Mail используют альтернативную команду XOVER, реализованную без ошибок. Ситуация кажется безнадежной, но стоит покурить хорошей травы, и решение придет само собой. Если NNTP-сервер в ответ на XOVER возвратит сообщение об ошибке, то NNTP-клиент задействует «резервную» команду XHDR, которая не была протестирована должным образом и содержит очень древний, но могучий баг. Таким образом, для атаки нам потребуется: во-первых, подсунуть жертве URL вида news://news.nezumi.org.ru/alt.news.hacker, а во-вторых, установить по адресу news.nezumi.org.ru свой собственный мини-NNTP-сервер, навязывающий клиенту команду XHDR и вместе с фиктивными заголовками статей передающий shell-код, который захватывает управление. Протокол обмена между клиентом и сервером смотри на диске.

Solution

Microsoft уже выпустила заплатку MS07-056 для всех систем, так что легче всего просто взять и обновиться. Однако если не использовать IE, то можно просто забить на эту проблему или залезть в настройки IE и запретить использование Outlook Express в качестве клиента для чтения новостей по умолчанию.

Kodak Image Viewer: удаленное исполнение кода

Brief

Сабжевый продукт входит в состав W2K и переходит в XP при обновлении системы. В свою очередь, при обновлении XP до Висты последняя получает в наследство Kodak Image Viewer со всеми багами, которые там только есть, а отдуваться приходится Microsoft. Забавно, не правда ли? Но ближе к делу. 9 октября 2007 года хакер по имени Cu Fang обнаружил ошибку в парсере TIFF-файлов, для просмотра которых Kodak Image Viewer, собственно говоря, и предназначен. Не вдаваясь в анатомические подробности строения TIFF-файлов, отметим, что в TIFF-заголовке хранится смещение структуры Image File Directory (или сокращенно IFD), которая содержит связанный список со ссылками на изображения и может располагаться в любом месте TIFF-файла. IFD состоит из нескольких структур, из которых мы рассмотрим всего лишь одну - BitsPerSample, включающую в себя 32-битный указатель на данные, корректность которого не проверяется, и потому он может указывать на любую область памяти, в том числе и не относящуюся к файлу. Это может привести как минимум к краху приложения, а как максимум к передаче управления на shell-код со всеми вытекающими отсюда последствиями.

Targets

W2K; W2K, обновленная до XP; W2K, обновленная до XP, обновленной до Висты.

Exploit

В дикой природе живых эксплойтов пока не встречалось, но их легко изготовить самостоятельно из «честного» TIFF-файла, пропатчив его hex-редактором, как на рисунке.

Solution

Снести сабжевый продукт к едрени фени и использовать IrfanView.

MS XML Core Services: удаленное переполнение кучи

Brief

Microsoft очень сильно любит XML. Настолько сильно, что пихает его всюду, вот только XML-движок (XML Core Services, он же MSXML) до ума довести все никак не успевает, что ставит Висту в очень неприятное положение, подвергая ее угрозе переполнения кучи с потенциальной возможностью передачи управления на shell-код, захватывающий управление с привилегиями пользователя, запустившего IE или Office. Но не будем забегать вперед.

14 августа 2007 года кодокопатель, пожелавший остаться анонимным, связался с компаниями VeriSign iDefence VCP и Zero Day Initiative, сообщив им, что в методе substringData(), реализованном в ActiveX-компоненте Microsoft.XMLDOM, отсутствует контроль входных параметров, что приводит к ошибке целочисленного переполнения. Компании уведомили об этом Microsoft, которая в спешном порядке выпустила пару заплаток, но финальные версии Висты уже поступили в продажу и потому остались незалатанными, не говоря о новом Office и программных продуктах сторонних разработчиков, использующих XML Core Services. Все это открывает огромный простор для атак, а потому остановимся на этой ошибке поподробнее и покажем, как ее можно использовать в хакерских целях, предварительно прогнав уязвимый ActiveX-модуль под отладчиком и дизассемблером. Собственно говоря, этот обширный раздел как раз и посвящен методам исследования уязвимого кода, но иметь секс с отладчиком мы будем чуть позже, а пока же изучим следующие ссылки на предмет получения дополнительной информации об инциденте: securityfocus.com/archive/1/476602 и https://studio.tellme.com/dom/ref/methods/substringdata.html.

Targets

Дыра подтверждена в ActiveX-компоненте Microsoft.XMLDOM, входящем в состав Microsoft Windows Vista 0/Business/Enterprise/Home Basic/Home Premium/Ultimate/x64 Edition, а также более ранних систем: W2K, XP, Server 2003, etc. Компонент Microsoft.XMLDOM используется IE 6.x/7.x, Microsoft Office 2003/SP1/SP2/2007 и программным обеспечением сторонних производителей, благодаря чему жертва может быть атакована через URL, Word/Excel/PowerPoint-документ и множеством других способов.

Exploit

16 августа в Сети появился исходный текст демонстрационного эксплойта, написанного хакером по имени Alla Bezroutchko из бельгийской компании Scanit (www.scanit.be). Боевой shell-код на его борту отсутствует, и результатом атаки становится аварийное завершение приложения:

Демонстрационный эксплойт, атакующий Microsoft.XMLDOM

<SCRIPT>

var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");

xmlDoc.loadXML("<dummy></dummy>");

var txt = xmlDoc.createTextNode("huh");

var out = txt.substringData(1,0x7fffffff);

</SCRIPT>

Solution

Установить заплатки MS07-042/MS07-043 или же отказаться от использования IE и Office. Однако залататься все же лучше, поскольку неизвестно, сколько существует программных продуктов сторонних разработчиков, использующих Microsoft.XMLDOM, что весьма чревато.

Full disclose

В качестве подопытной лабораторной крысы будет выступать Microsoft Windows Server 2003 ENG в конфигурации по умолчанию. Итак, помещаем HTML-код эксплойта в файл и открываем его с помощью IE. Осел думает некоторое время и, когда наше терпение уже начинает иссякать, внезапно исчезает с экрана, закрывая все свои окна, а при следующем перезапуске предлагает отослать рапорт в Microsoft. Но мы же не стукачи какие-нибудь! Мы и сами разберемся, что к чему. Загружаем свой любимый SoftICE и повторяем открытие HTML-файла еще раз. SoftICE лихо отлавливает exсeption, спотыкаясь на инструкции REPZ MOVSW, расположенной по адресу 72E5D56Fh, очевидно, копирующей строку за пределы буфера и вызывающей исключение STATUS_ACCESS_VIOLATION. Как мы сюда попали? И куда нам теперь идти? Сперва изучим исходный код эксплойта. Что мы видим? Методу substringData() в качестве количества извлекаемых из строки символов передается число 7FFFFFFFh, по всей видимости, и вызывающее переполнение, поскольку оно превышает объем динамической памяти, выделенной процессу!

Сразу же по ходу дела возникает вопрос: куда Microsoft заныкала свою библиотеку Microsoft.XMLDOM? Запускаем редактор реестра, нажимаем <Ctrl-F> (Find) и вводим «Microsoft.XMLDOM», после чего давим Find и через несколько минут обнаруживаем ее в разделе InProcServer32 под именем %SystemRoot%\System32\msxml3.dll.

Хорошая идея – загрузить msxml3.dll в дизассемблер, например в IDA Pro, который тут же предложит нам скачать с сервера Microsoft файл с отладочными символами, чтобы было удобнее дизассемблировать (многие символы не экспортируются, и остается только гадать, что это за функция такая и на хрена она вообще). Короче, IDA говорит нам: «Откройте Горящего Лиса или Оперу и введите http://msdl.microsoft.com/download/symbols/msxml3.pdb/3E800B232/msxml3.pd. Дождитесь завершения скачки, после чего распакуйте файл штатной утилитой expand.exe и положите его в один файл с дизассемблируемой DLL, после чего нажмите OK».

Итак, мы получили msxml3.pd_, и что же мы будем с ним делать? А вот что! Возвращаемся в командную строку и говорим:

$expand msxml3.pd_ msxml3.pdb

Программа распаковки файлов Microsoft (R), версия 5.00.2134.1

(C) Корпорация Microsoft, 1990-1999. Все права защищены.

Распаковка msxml3.pd_ в msxml3.pdb.

msxml3.pd_: 791399 байт распаковано в 3138560 байт, увеличение на 296%.

Сразу же после распаковки нажимаем OK и видим, как IDA Pro выводит перечень загружаемых символов. А выводит она их так долго, что возникает соблазн попить пива, чтобы не расслабляться.

Короче, нашли мы приключения на свою задницу! И как теперь предполагается искать substringData в дизассемблерном листинге? Обычно это делается по <Shift-F4> (List of names), но только не в этом случае, поскольку сейчас кроме метода нам еще необходимо указать класс, к которому он принадлежит, а вот класса мы как раз и не знаем. «File -> Produce output file -> Produce MAP file» - и вот теперь в сгенерированном map-файле можно искать substringData тривиальным контекстным поиском через FAR или любой другой редактор по вкусу:

Поиск функции substringData в map-файле

0001:00066428 loc_72EB7428

0001:00066440 W3CDOMWrapper::substringData(long,long,ushort * *)

0001:0006646A loc_72EB746A

Ага, правильное имя нашей подопечной оказывается W3CDOMWrapper::substringData, так что теперь можно смело жать <Shift-F4> и писать его. Искомая функция обнаруживается по адресу 72EB7440h. Запомним его, так как он нам впоследствии очень пригодится.

Дизассемблированный фрагмент функции W3CDOMWrapper::substringData

.text:72EB7440 ; public: virtual long __stdcall W3CDOMWrapper::substringData()

.text:72EB7440 ?substringData@W3CDOMWrapper@@UAGJJJPAPAG@Z proc near

.text:72EB7440 ; CODE XREF: [thunk]:W3CDOMWrapper::substringData`adjustor{4}' (long,

.text:72EB7440 push 30h

.text:72EB7442 push offset unk_72F4F228

.text:72EB7447 call __SEH_prolog

.text:72EB744C call ?g_pfnEntry@@3P6GPAUTLS@@XZA ; TLSDATA * (*g_pfnEntry)()

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

Казалось бы, в чем проблема? Вводи BPX 72EB7440 и можно курить дальше. Короче, запускаем IE (без эксплойта!!!) и, пока он загружает домашнюю страницу, быстро жмем <Ctrl-D>, чтобы успеть очутиться в контексте IE, а не псевдопроцесса Idle (имя которого SoftICE высвечивает в правом нижнем углу). Вообще-то, можно дать команду ADDR IEXPLORE, переключающую контекст вручную, но она не всегда срабатывает, как ты этого ожидаешь, поэтому первый метод надежнее. Итак, будем считать, что мы находимся в контексте IE. Даем команду u 72EB7440, чтобы дизассемблировать функцию W3CDOMWrapper::substringData, и нас ожидает жестокий облом, поскольку эта функция еще не загружена и соответствующий ей регион памяти не выделен, а потому вместо дизассемблерных инструкций отладчик пишет «INVALID».

Можно ли сейчас отдать команду BPX 72EB7440 в надежде, что, когда функция загрузится, точка останова сработает? А вот и нет! BPX подразумевает внедрение программной точки останова, которой соответствует машинная команда CCh, а ее внедрять пока что не во что (память-то не выделена), да и все равно она будет затерта при загрузке функции в память. На самом деле необходимо устанавливать аппаратную точку останова на исполнение, что делается так: BPM 72EB7440 X. После этого можно смело выходить из отладчика, загружать в IE наш эксплойт, и отладчик послушно всплывет в момент вызова функции W3CDOMWrapper::substringData.

Половину работы можно считать сделанной. Теперь, нажимая <F10> (Step Over), трассируем функцию без захода в дочерние функции, дожидаясь возникновения исключения. Долго ждать не приходится, и при выполнении String::substring(int,int), расположенной по адресу 72EB74FBh, происходит крэш.

Дизассемблированный фрагмент функции W3CDOMWrapper::substringData

.text:72EB74F4 call ?newString@String@@1@V?$_array@G@@@Z ; String::newString(_array<>)

.text:72EB74F9 mov ecx, eax

.text:72EB74FB call ?substring@String@@QAEPAV1@HH@Z ; String::substring(int,int)

.text:72EB7500 mov ecx, eax

.text:72EB7502 call ?getBSTR@String@@QBEPAGXZ ; String::getBSTR(void)

.text:72EB7507 mov ecx, [ebp+14h]

Выходим из отладчика, позволяя ему завершить процесс IEXPLORE.EXE, и повторяем всю процедуру вновь, только на этот раз при достижении функции String::substring(int,int) нажимаем не <F10>, а <F8> (Step into), чтобы войти внутрь нее и посмотреть, что интересного тут происходит:

Дизассемблированный фрагмент функции String::substring(int,int)

.text:72E98157 mov eax, [edi+0Ch]

.text:72E9815A push esi

.text:72E9815B lea eax, [eax+ebx*2]

.text:72E9815E push eax

.text:72E9815F call ?newString@String@@1@@Z ; String::newString(ushort*,int)

А происходит тут, собственно, следующее. При достижении функции String::newString(ushort*,int), которой в качестве параметра int передается значение 7FFFFFFFh в регистре ESI, возникает исключение, что совсем неудивительно, поскольку создать строку такого огромного размера, прямо скажем, затруднительно.

Что ж! Дизассемблируем саму функцию String::newString, где происходит финальное исключение. После нескольких незначащих проверок мы видим следующее.

Дизассемблированный фрагмент функции String::newString

.text:72E5D550 push ebx

.text:72E5D551 push esi

.text:72E5D552 mov ebx, ecx

.text:72E5D554 call ??0Base@@IAE@XZ ; Base::Base(void)

.text:72E5D559 mov esi, [esp+arg_0]

.text:72E5D55D test esi, esi

.text:72E5D55F mov dword ptr [ebx], (offset loc_72E85137+1)

.text:72E5D565 jz short loc_72E5D573

.text:72E5D567 mov ecx, [esp+arg_4]

.text:72E5D56B push edi

.text:72E5D56C mov edi, [ebx+0Ch]

.text:72E5D56F rep movsw ; <-- здесь возникает исключение

.text:72E5D572 pop edi

А вот и машинная команда REP MOVSW. Именно она и вызывает исключение! Бесконтрольное копирование памяти без каких бы то ни было проверок позволяет затирать служебные указатели строго дозированным образом, передавая управление на свой собственный shell-код по обычной методике переполнения кучи, которая здесь не рассматривается. То, что это куча, а не стек, видно из того, что память выделяется оператором new (на приведенных выше фрагментах он отсутствует). С другой стороны, выделенные адреса (куда осуществляется копирование строки) относятся к динамической памяти, что легко узнать, посмотрев на карту.

Подводя итоги, мы не без гордости можем сказать, что не только научились отлаживать ActiveX-компоненты, не только познакомились с файлами отладочных символов, но еще и освоили общие принципы исследования программ без исходных текстов. Кстати, если добавить в функцию substringData() дополнительную проверку (стартовая позиция + количество извлекаемых символов должно быть меньше или равно длине строки), что осуществляется прямо в hiew'е (место для нескольких машинных команд найти нетрудно), то можно отказаться от заплатки MS. Хотя при этом с цифровой подписью придется распрощаться, и ActiveX-компонент потребуется подписывать по новой, используя свою собственную подпись. А она денег стоит! Как вариант - можно править функцию прямо в памяти, но для этого придется отслеживать ее загрузку, что уводит нас в дремучие дебри online patch'а, о котором мы поговорим в другой раз.

WWW

Обязательно посмотри ссылки по теме:

Содержание