книги хакеры / журнал хакер / 185_Optimized

Трудно быть богом

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

ВИРТУАЛИЗАЦИЯРЕСУРСОВ

Технологии Intel-VT и AMD-V расширили 32- (Protected Mode)

и64- (Long Mode) битные режимы работы процессора новыми инструкциями и регистрами, которые позволяют запускать виртуальные машины. Возможностью запуска виртуальных машин и полным доступом к данным виртуальных машин обладает только нулевое кольцо защиты в Protected Mode и Long Mode, что соответствует привычному ядру операционной системы. Это означает, что в случае использования VMware Workstation полным доступом к ресурсам виртуальных машин обладает только ядро Windows или Linux, в то время как привычный веб-браузер доступа к виртуальным машинам не имеет. Впрочем, для работы виртуальных машин одной технологии Intel-VT или AMD-V мало: чтобы обеспечить работу полноценной операционной системы внутри виртуальной машины, хостовая система должна предоставить эмуляцию работы значительного количества различных устройств. В большинстве средств виртуализации, от домашних до серверных, эмуляторы устройств для каждой виртуальной машины работают внутри обычных процессов хостовой операционной системы (например, для VMware это vmware-vmx.exe).

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

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

иуправляющие регистры), оперативная память, видеопамять

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

Нарушителя чаще всего интересуют именно ресурсы операционной системы, поэтому для совершения атаки с кражей данных ему потребуется преобразовывать ресурсы виртуальной машины в ресурсы гостевой операционной системы. Например, файлы необходимо собирать по секторам, используя формат файловой системы, а адресное пространство процесса внутри гостевой — по страничке, используя таблицы трансляции адресов. Для прохождения задания NeoQUEST участни-

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

ВИРТУАЛЬНЫЙАНАЛИЗ

Для получения ресурсов гостевой системы из ресурсов вирту-

2

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

КАКCMATИVOLATILITYРАСПУТЫВАЮТПАУТИНУ

WINDOWS

Рассмотрим один из самых простых методов анализа, реализованных в утилитах CMAT и Volatility: поиск структуры данных ядра Windows KDDEBUGGER_DATA64. Структура KDDEBUGGER_DATA64 предназначена для использования отладчиком уровня ядра и включает значения, знание которых может помочь в идентификации версии Windows и дальнейшем анализе. Описание структуры содержится в заголовочном файле wdbgexts.h из Windows SDK. Отличительная ее особенность — она не меняется в различных версиях ОС. Это сделано для того, чтобы избавиться от необходимости иметь различные версии отладчика WinDbg. Определение данной структуры в памяти позволяет сделать вывод о наличии запущенной ОС Windows в момент снятия дампа памяти. После этого можно анализировать память на наличие прочих структур, специфичных для Windows.

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

гая структура — DBGKD_DEBUG_DATA_HEADER64, которая, в свою очередь, содержит метку владельца блока данных и его размер. Блок, предназначенный для WinDbg и присутствующий всегда, обладает меткой KDBG. Это значение можно использовать как сигнатуру для поиска структуры. Для повышения точности в случае возникновения проблем определения правильной структуры можно применять дополнительную проверку следующего поля структуры — размера блока данных. По описанию в заголовочном файле можно определить ее размер и сравнивать с размером кандидата. После определения структуры KDDEBUGGER_DATA64 необходимо найти структуру DBGKD_GET_VERSION64 для получения версии. Эти две структуры всегда находятся рядом в памяти, поэтому для поиска второй структуры нужно проверить лишь небольшой участок около найденной, например одну страницу. DBGKD_GET_VERSION64 не имеет постоянной сигнатуры, однако дублирует значения

полей KernBase и PsLoadedModuleList структуры KDDEBUGGER_ DATA64, поэтому сигнатура может быть составлена в процессе анализа. Еще одной частью анализа является определение значения регистра CR3, которое реализуется с помощью перебора всех страниц памяти и попыток преобразования некоторых адресов: например, из KDDEBUGGER_DATA64 узнаем адрес базы ядра, а затем выполняем проверку наличия корректного PE-образа по полученному адресу. Однако в Windows таблицы страниц могут мапить сами себя, поэтому такую структуру в памяти можно найти достаточно быстро.

После определения всех перечисленных выше данных можно однозначно определить набор символов для найденной версии Windows путем просмотра секции отладки PEобраза ядра или же с использованием полученного номера версии.

ЧТОУНАСПОДМИКРОСКОПОМ?

Чтобы не быть голословными, давай рассмотрим все сказанное на практике. Для примера возьмем одно из заданий недавно прошедшего NeoQUEST-2014, которое называлось «Отмороженный компьютер». Участникам нужно было найти ключ (ответ на задание) в дампе оперативной памяти, полученном путем простого копирования файла xxx.vmem от запущенной и настроенной заранее виртуальной машины. Сложность заключалась в том, что внутри виртуальной машины VMware, от которой и предоставлялся дамп, была создана и запущена другая виртуальная машина под управлением VirtualBox. Причем обе виртуалки были под управлением одинаковых версий Windows 7, поэтому в дампе памяти присутствовало одновременно две операционные системы, чьи страницы памяти были сильно разбросаны по дампу. Вот и попробуй найди в этой паутине нужный ключ… Еще одной особенностью задания было то, что ключ был только в виде графического изображения в видеопамяти виртуальной машины VirtualBox. Поэтому для решения участникам необходимо было восстановить видеопамять этой виртуалки.

Взлом

7

Адрес корневой таблицы виден в логе и равен 3dd8b000. Как и в любых таблицах трансляций, в ней используются исключительно физические адреса, которые соответствуют абсолютным смещениям в файле дампа, поэтому осталось прочитать видеопамять, которая также расположена в физическом адресном пространстве виртуальной машины VirtualBox и маппится при помощи EPT.

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

Шаг 3. Узнаем физический адрес видеопамяти для виртуальной машины VirtualBox. В дампе его нет, поэтому, чтобы его узнать, достаточно запустить VirtualBox у себя на компьютере и посмотреть во вкладке ресурсов видеоадаптера значение:

00:00:02.305353 VRamSize <integer> =

0x0000000001000000 (16 777 216, 16 MB)

Шаг 4. Определяем формат и размер видеоизображения. В видеопамяти графические данные хранятся в определенном формате, который схож с обычным BMP-форматом: последовательно байты RGBXRGBX… на каждый пиксель по три или четыре байта. Разрешение экрана и битность узнаем из лога:

Трудно быть богом

00:01:14.565973 Display::handleDisplayResize():

uScreenId = 0, pvVRAM=065c0000 w=800 h=600

bpp=32 cbLine=0xC80, flags=0x1

Шаг 5. Теперь нужно написать программу, которая прочитает из дампа только видеопамять. Для этого она должна разбирать таблицы страниц в заданном диапазоне (начиная с физического адреса 0xE0000000 и длиной, равной размеру картинки, — 800 × 600 × 4). Физический адрес соответствует адресу Linear Frame Buffer (LFB), взятому из ресурсов видеокарты, которые репортуют PCI- и VBE-расширения.

ТО,ЧТОМОЖНОСДЕЛАТЬСАМОМУ

Полностью рассматривать код программы не будем, вместо этого сосредоточимся на основных функциях. Первая функция преобразует физический адрес виртуальной машины (GPA — Guest Physical Address) в физический адрес хостовой системы

(HPA — Host Physical Address).

DWORD TranslateGPA2HPA( DWORD gpa )

{

vmxGuestPysicalAddress addr;

addr.Value = gpa;

vmxEPTP eptp;

eptp.Value = EPT_base;

DWORD64 pml4_base = (eptp.PML4ShiftedAddr << 12);

vmxEptPML4Entry pml4_ent;

pml4_ent.Value = DumpRead64(pml4_base + 8 *

addr.eptPML4EntryOffset);

DWORD64 pdpt_base = (pml4_ent.

eptPDPTShiftedAddr << 12);

vmxEptPDPTEntry pdpt_ent;

pdpt_ent.Value = DumpRead64(pdpt_base + 8 *

addr.eptPDPTEntryOffset);

DWORD64 pd_base = (pdpt_ent.

eptrfPDShiftedAddr << 12);

vmxEptPDEntry pd_ent;

pd_ent.Value = DumpRead64(pd_base + 8 *

addr.eptPDEntryOffset);

DWORD64 pt_base = (pd_ent.eptrfPTShiftedAddr

<< 12);

vmxEptPTEntry pt_ent;

pt_ent.Value = DumpRead64(pt_base + 8 *

addr.eptPTEntryOffset);

return (pt_ent.Shifted4KPageAddr << 12) |

addr.eptByteOffset;

}

Следующая функция читает из файла (который выдавался в задании) данные виртуальной машины, используя предыдущую функцию.

void ReadPage(void *data, DWORD gpa)

{

DWORD offset = TranslateGPA2HPA(gpa &

(~0xFFF));

fseek(g_fdump, offset, SEEK_SET);

fread(data, 4096, 1, g_fdump);

}

Последняя из рассматриваемых функций читает видеопамять виртуальной машины и создает из нее файл BMP с картинкой.

HBITMAP ReadVideoMemory( DWORD width, DWORD

height, DWORD bpp )

{

DWORD size = ((width * height * (bpp / 8) /

4096) + 1) * 4096;

char *bmp = (char *)malloc(size);

for (int i = 0; i < size; i+=4096)

{

ReadPage(bmp + i, 0xE0000000 + i);

}

return CreateBitmap(width, height, 1, 32, bmp);

}

9

10

ЗАКЛЮЧЕНИЕ

Теперь ты понимаешь, в какую виртуальную паутину превращают оперативную память разработчики операционных систем и процессоров. Проанализировать память виртуалки можно с помощью утилит Volatility Framework и CMAT, но что-то и они сделать не в силах, и тогда помогут только собственные знания об устройстве видеопамяти и технологии виртуализации. Так или иначе, получение доступа к гостевой операционной системе из хостовой не так сложно, как кажется на первый взгляд.

Взлом

MITM в мобильном мире