Thursday, December 24, 2009

Hypervisors

Несколько недель назад на многих 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.


Download PDF

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


Исходный код BitVisor-а доступен на SourceForge под BSD лицензией.

В связи с тем, что 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 - была выдрана из комментариев в исходных текстах):
#include "stdio.h"
#include "stdlib.h"

#ifdef __MINGW32__

#include "conio.h"
#define NOECHO()
#define GETCHAR() getch()
#define PUTCHAR(_c_) putch(_c_)
#define ECHO()

#else

#define NOECHO() system("stty -echo -icanon")
#define GETCHAR() getchar()
#define PUTCHAR(_c_) putchar(_c_), fflush(stdout)
#define ECHO() system("stty echo icanon")

#endif

static int vmcall_dbgsh(int c)
{
    int r = 0, n = 0;

    asm volatile("push (%%ebx); push 4(%%ebx); lea 8(%%esp), %%esp; vmcall" : 
                 "=a" (n) : "a" (0), "b" ("dbgsh"));

    if (n == 0)
    {
        return -1;
    }

    asm volatile("vmcall" : "=a" (r) : "a" (n), "b" (c));
    return r;
}

void e(void)
{
    ECHO();
}

int main(int argc, char **argv)
{
    int s = -1, r = 0;
    FILE *fp = NULL;

    if (argc >= 2) 
    {
        fp = fopen(argv[1], "w");
    } 
    else 
    {
        fp = NULL;
    }

    vmcall_dbgsh(-1);

    if (vmcall_dbgsh(-1) == -1)
    {
        exit (1);
    }

    atexit(e);
    NOECHO();

    while (true) 
    {
        r = vmcall_dbgsh(s);
        s = -1;

        if (r == 0) 
        {
            s = GETCHAR();
        } 
        else if (r > 0) 
        {
            if (fp)
            {
                fprintf(fp, "%c", r);
                fflush(fp);
            }

            PUTCHAR(r);
            s = 0;
        }
    }
}

Будучи скомпилированной (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 версия программы для отладки и проверки работоспособности гипервизора).

Sunday, December 13, 2009

Обмануть антиотладку

Мне периодически попадаются экземпляры 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, с подменой значений обоих полей для соответствующего информационного класса.


Архив с бинарником и исходными текстоми доступен для загрузки.

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

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

На системе с активным удалённым отладчиком без патча:
nt!KdDebuggerEnabled: 0x8054b6c1 (TRUE)
   DebuggerEnabled=0x00000001
DebuggerNotPresent=0x00000000

На пропатченой системе с активным удалённым отладчиком:
nt!KdDebuggerEnabled: 0x8054b6c1 (FALSE)
   DebuggerEnabled=0x00000000
DebuggerNotPresent=0x00000001