Обходим детектирование виртуальной машины программами в virtualbox

Обход защиты от запуска приложений на виртуалке на примере VMWare

Часто случается, что при запуске какого-либо вин-приложения из-под виртуальной машины приложение мгновенно закрывается с такой вот ошибкой:

Sorry, this application cannot run under a Virtual Machine

Это в основном означает, что разработчики данного приложения пожелали не давать ему возможности запускаться из-под виртуалок.

Исследовав проблему, нашел её решение для VMWare — оно состоит в том что необходимо подправить конфиг файла с расширением .vmx, дописав туда несколько строчек:

А кто-то советует дописать чуть другое:

В обоих случаях мне удалось обойти защиту приложений и запустить их из под виртуальной машины! 😉

UPD: Для смены мака и других свойств виртуальной машины — пробуем также VmTweaker — http://sourceforge.net/projects/vmtweaker/

Некоторые советуют ставить VirtualBox вроде в нем с этим нет проблем. Я лично не пробовал.

Похожие записи:

20 thoughts on “ Обход защиты от запуска приложений на виртуалке на примере VMWare ”

напишите подробней как это сделать или путь к этому файлу и поможет этот метод на Virtual Box а то та этой машине теже проблемы

Очевидно, что от универсального метода детерминации эти «костыли» не спасут.

Источник

Обходим детектирование виртуальной машины программами в VMWare

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

Я использовал VMWare Fusion для Mac, однако с тем же успехом способ работает и в Workstation для Win.

1) Для работы необходима заново установленная система, как внести изменения в уже существующую — не нашёл.

Готовите виртуальный диск, указываете систему, как это обычно делаете, и в настройках к устанавливаемой машине, у меня этот пункт назван Isolation, выключаете любой обмен данными с хостовой ОС.

2) Далее надо найти конфигурационный VMX файл, создаваемый на этапе создания машины в VMWare, и в конец добавить строки:

isolation.tools.getPtrLocation.disable = «TRUE»
isolation.tools.setPtrLocation.disable = «TRUE»
isolation.tools.setVersion.disable = «TRUE»
isolation.tools.getVersion.disable = «TRUE»
monitor_control.disable_directexec = «TRUE»
monitor_control.disable_chksimd = «TRUE»
monitor_control.disable_ntreloc = «TRUE»
monitor_control.disable_selfmod = «TRUE»
monitor_control.disable_reloc = «TRUE»
monitor_control.disable_btinout = «TRUE»
monitor_control.disable_btmemspace = «TRUE»
monitor_control.disable_btpriv = «TRUE»
monitor_control.disable_btseg = «TRUE»

Эти опции предотвращают детектирование программами виртуального окружения через такие сложные проверки, как отслеживание адресного пространства памяти, счётчиков.

Важно! Если на этапе настройки установки будет опция вроде «Express install», «Быстрая установка» — выключайте их. Также не стоит устанавливать VMWare Tools в установленную систему, т.к. некоторое ПО в проверку включает и наличие этого пакета.

3) Сохраняем файл, указываем для загрузки ISO с установщиком системы, устанавливаем ОС как обычно.

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

Чтобы победить и их в Windows, идём в редактор реестра в ветку HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum. Как видите, там есть вполне явная отсылка к тому, что диск — виртуальный.

Нам нужно изменить его, убрав из параметра VMware, Virtual, Ven, итп, и сохранить её так.

Также имеет смысл заменить в реестре поиском по VMware/Virtual на какой-нибудь Intel или IBM всё, что меняется, а не только дисковые переменные.

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

Важно! Значение в HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum перезаписывается после каждой перезагрузки, так что его нужно менять после каждого нового запуска системы.

Естественно, это не исчерпывающее руководство, некоторое ПО также может пытаться определять виртуальную систему следующими методами:

1) Проверками диапазона MAC адресов (просто подменяется в настройках виртуального сетевого адаптера до запускa виртуальной машины)
2) Через WinAPI опросом конфигурации ОС и прочей системной информации (FirmwareTable)
3) Низкоуровневыми трюками.

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

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

Как видно, улучшить скрытность можно также выделив виртульной машине больше системных ресурсов. Что касается памяти, выбирать стоит значения, кратные 1024.

Спасибо всем, кто осилил статью и помог в дополнении её толковыми комментариями!

Источник

VM escape: 101

В данной статье я попытаюсь рассказать об очевидных (и не очень) методах побега из VMware WorkStation и VirtualBox, а также рассмотрю несколько интересных частных случаев.

VMware WorkStation, VirtualBox (Oracle VM VirtualBox) – программные продукты для виртуализации, позволяющие запустить на компьютере несколько операционных систем одновременно.

Вместо вступления

VM escape будоражит умы многих исследователей безопасности. Среди хакеров данные эксплойты считаются весьма продвинутыми и сложными. Такие примеры есть, но их совсем немного (одни из самых интересных: VMware CloudBurst, Advanced Exploitation of Xen Hypervisor Sysret VM Escape Vulnerability). Но не всегда для того чтобы ваш код из виртуальной машины попал на реальную (или на оборот) надо придумывать что-то эдакое. Так, в случае атаки на рядового пользователя мы можем взять наш топор и рубить по самым банальным вещам. Без лишних слов – поехали.

Заражение общих папок

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

Параметры общих папок для VMware Workstation

Параметры общих папок для VirtualBox

Заражение захваченных USB-устройств

Не уступающий по эффективности предыдущему рассмотренному методу вариант. Также достаточно реализованных ITW-вредоносов (как исторический пример – Flame) со встроенными watchdogs, мониторящими подключение USB-устройств, автоматически распространяющихся путем заражения исполняемых файлов, проброса злосчастного файла autorun.inf, уязвимости LNK и т. д.

Естественно, главным условием данного метода является наличие устройства USB-контроллера с определенной конфигурацией у виртуальной машины.

В VMware Workstation, как мне кажется, настройки USB-контроллера реализованы некорректно: работа фильтра распространяется сразу на все устройства, причем эти опасные настройки выставлены по умолчанию при создании новой виртуальной машины.

Параметры USB-контроллера для VMware Workstation

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

Параметры USB-контроллера для VirtualBox

Атака на общий буфер обмена

VMware Workstation

Параметры виртуальной машины

Для начала обобщенно рассмотрим архитектуру DnD (Drag’n’Drop) и общего буфера обмена. Передача данных между гостем и хостом реализована через механизм GuestRpc, который по сути является командой (0x1E) BackDoor I/O (для тех кто не знает или забыл, что такое VMware BackDoor I/O: https://sites.google.com/site/chitchatvmback/backdoor).

Модель DnD, общего буфера обмена на основе иерархии классов (взято из исходников OpenTools):

В свою очередь, GuestRpc также имеет таблицу команд, весь список которых можно получить только после тщательного реверсинга VMware (кстати говоря, в стандартный набор гостевых утилит входит RpcTool, с помощью которого вы можете, соответственно, отправлять GuestRpc-команды). В случае DnD и общего буфера обмена используются такие команды (также именуемые «транспортные интерфейсы»):
dnd.transport
copypaste.transport

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

Так, например, выглядит набор команд для copypaste.transport:

Пакет CP_CMD_SEND_CLIPBOARD, красным выделен непосредственно буфер обмена в
кроссплатформенном формате:

Итак, возможные сценарии подмены общего буфера обмена VMware:

Очевидно, что вместо исполняемого файла может быть любой офисный документ-эксплойт и т. д.

Простая демонстрация данной атаки (используется непосредственно инжект в гостевую утилиту):

VirtualBox

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

Но не могу не упомянуть сторонний проект VMTransferFiles, расположенный на официальном форуме VirtualBox.

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

Атака на софт, косвенно относящийся к виртуализации

Не секрет, что множество разнообразных исследователей в области ИБ так или иначе используют виртуальные машины в своей работе. Так, например, malware-аналитики зачастую анализируют трафик или поведение вредоносов, используя прелести виртуализации.
Отсюда и растут корни этой подтемы: бить по софту, используемому ими при той или иной работе.

Wireshark

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

Пример блэк-листа буткита Rovnix:

Поэтому очень часто я наблюдал простое и ленивое решение обхода детектирования Wireshark: попросту запускать его на своем хосте, анализируя трафик виртуальной машины. Кроме того, многие sandbox-системы автоматически генерируют pcap-файлы трафика, которые, в свою очередь, обычно анализируют также на хосте с помощью Wireshark. Значит неплохой идеей будет использовать различные удаленные и локальные баги в диссекторах Wireshark, для VM-escape целей.

Как пример уязвимости, я решил использовать CVE-2014-2299 – переполнение буфера в парсере MPEG-файлов. В наличии уже имеется исходный код эксплойта, модуль под MetaSploit.

Видео демонстрация с боевыми калькуляторами:

VirtualKD

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

VirtualKD – это open-source-проект, призванный улучшить производительность отладки ядра под VMware либо VirtualBox. Реализовано это весьма кастомным методом (я рассмотрю реализацию с VMware) – на стороне хоста в процесс vmware-vmx (процесс нашей виртуальной машины) инжектируется dll, которая в свою очередь патчит/добавляет в таблицу GuestRpc новые команды и ее обработчики. Со стороны же гостя перехватывается ряд функций Kd* (KDCOM.DLL) на свою имплементацию, реализованную в драйвере KDVM.DLL.

По сути получается простая схема – протокол KDCOM туннелируется через VMware BackDoor I/O (GuestRpc) на хост и далее разворачивается напрямую в пайп-канал, который прослушивает WinDbg.

Архитектура VirtulKD (специфичная для VMware):

И все бы прекрасно, утилита действительно работает, но я решил ввиду моей темы пройтись по ее исходникам в поисках быстрых багов. И действительно, в течение часа был найден тривиальный integer overflow.

Итак, в заголовочном файле rpcdisp.h, в методе KdRpcDispatcher::SendPacket обрабатываются данные KDCOM-пакета, обернутого дополнительной служебной информацией.
Некоторые из этих данных валидируются неправильно.

Как мы видим на рисунке, результат сложения pParams[1] и pParams[2] можно спокойно переполнить (например, pParams1== 0xFFFF0000 и pParams2==0x18000 в результате даст нам 0x8000). И далее по коду pParams[1] будет использоваться как смещение до данных, что в результате приведет к общей ошибке чтения.

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

Естественно, я написал об этой баге команде sysprogs, на что они ответили в стиле: “Спасибо, но патчить мы это не будем, так как не видим impact”. К тому же они почему-то посчитали, что бага эксплуатируется только в kernel-mode под гостем, хотя в реальности все как раз наоборот и даже лучше – эксплуатация не нуждается ни в каких привилегиях вообще! По факту эксплойт шлет напрямую в BackDoor I/O наши злобные пакеты, размер концепта в принципе получается очень мал, и его легко, при желании, внедрить в любую malware.

Также хочу заметить, что данная DoS VM бага найдена очень быстро, и кто знает – может быть, в VirtualKd зарыты более весомые уязвимости ведущие уже к действительному VM-escape. Для тех, кто хочет поближе ознакомиться с эксплойтом, здесь его исходный код.

И небольшая демонстрация данной атаки:

Использование устаревших уязвимых технологий

Этот частный случай, хоть и относится больше к KVM и Xen, как мне кажется, прекрасно характеризует данную под тему.

VMGL – это уже давно заброшенный проект по front-end OpenGL 3d hardware акселерации, на который, однако, до сих пор есть ссылки – например, на официальной странице KVM-проекта.

Сайт проекта, откуда можно взять исходный код.

Грубо говоря, VMGL является клиент-серверной технологией, туннелирующей через стек TCP/IP-протоколов поступающие с виртуальной машины гостя GL-команды напрямую в GPU на хосте.

Архитектура VMGL

Изучив глубже реализацию и взглянув на исходные коды, я увидел, что в основе VMGL лежит проект Chromium. Так вот, этот самый проект Chromium также лежит в основе 3D-акселерации виртуальных машин VirtualBox и уже был достаточно успешно изучен на наличие багов.

Итак, с установкой VMGL вы получаете не просто акселерацию, а к тому же как минимум три известные уязвимости (CVE-2014-0981; CVE-2014-0982; CVE-2014-0983) дизайна Chromium-движка.

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

Источник

Детектим виртуалки

Определяем факт запуска приложения в VirtualBox, VMware Workstation, Virtual PC и Parallels Workstation

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

Как распознать виртуальную машину?

Во-первых, любая виртуальная машина несет на своем борту какое-нибудь специфическое оборудование. Это касается видеоадаптера, жесткого диска, идентификатора процессора, версии BIOS, MAC-адреса сетевой карты.

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

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

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

Что же касается общих признаков наличия виртуальной машины, предложенных в свое время госпожой Рутковской (характерное расположение таблиц IDT, GDT и LDT, а также время выполнения операций процессором), то в настоящий момент все эти признаки трудно поддаются анализу и приведению к какому-нибудь общему знаменателю, главным образом из-за многоядерности и многоликости современных процессоров.

Анализируем оборудование

Начнем, пожалуй, с жесткого диска. Если посмотреть идентификатор жесткого диска в диспетчере устройств на виртуальной машине, то в его составе можно увидеть интересные строчки:

Самый простой способ узнать наименование жесткого диска — прочитать значение ключа с именем «0» в ветке реестра HKLMHARDWARESYSTEMCurrentControlSetServicesDiskEnum.

В этом месте перечисляются все дисковые накопители в системе, и первым, как раз в ключе с именем «0», будет тот диск, с которого произошла загрузка системы.

Идентификатор жесткого диска VirtualBox в реестре

Хакер #174. Собираем квадрокоптер

Как читать реестр, я думаю, ты знаешь. Используем сначала API RegOpenKeyEx для открытия нужного ключа, далее с помощью RegQueryValueEx читаем значение. Выглядеть это должно примерно вот так:

Далее все просто — используем strstr для поиска нужных нам строк в считанном значении и, в зависимости от результата сравнения, делаем вывод. Версия BIOS содержится в ключе «SystemProductName» в ветке HKLMHARDWAREDESCRIPTIONSystemBIOS. К примеру, для VMware там будет лежать строка «VMware Virtual Platform», а для VirtualBox — «VBOX –1».

Прочитать это все можно с помощью все тех же API — RegOpenKeyEx и RegQueryValueEx.

Версия BIOS Parallels Workstation в реестре

Данные о видеоадаптере можно подглядеть в HKLMSystemCarrentControlSetEnumPCI. В этой ветке перечислено все, что подключено к шине PCI, в том числе и видеокарта. Для VirtualPC это строчка вида VEN_5333&DEV_8811&SUBSYS_00000000&REV_00, которая определяет видеоадаптер S3 Trio 32/64, эмулируемый виртуалкой от Microsoft — на реальном железе такое оборудование нынче днем с огнем не сыскать (а у меня такая была в конце прошлого века. — Прим. ред.). Для VirtualBox видеокарта описана последовательностью VEN_80EE&DEV_BEEF&SUBSYS_00000000&REV_00, что расшифровывается как «VirtualBox Display», а у Parallels Workstation — строка VEN_1AB8&DEV_4005&SUBSYS_04001AB8&REV_00 определяет видеоадаптер «Parallels Display».

Помимо этого, в VirtualBox можно найти строку VEN_80EE&DEV_CAFE&SUBSYS_00000000&REV_00, определяющую некий «VirtualBox Device», а у Parallels Workstation строки VEN_1AB8&DEV_4000&SUBSYS_04001AB8&REV_00 и VEN_1AB8&DEV_4006&SUBSYS_04061AB8&REV_00, определяющие «Parallels Tools Device» и «Parallels Memory Controller» соответственно.

Алгоритм действий следующий: пытаемся открыть нужный нам ключ, и если он открывается успешно, то оборудование, описанное этим ключом, в наличии и можно делать вывод о присутствии какой-либо виртуальной машины:

Идентификатор процессора определяется с помощью команды cpuid. Благодаря ей можно получить много всякой полезной информации об установленном процессоре. Вид выдаваемой этой командой информации зависит от содержимого регистра EAX. Результат работы команды записывается в регистры EBX, ECX и EDX. Подробно про эту команду можно почитать в любой книге по программированию на ассемблере. Для наших целей мы будем использовать эту инструкцию, предварительно положив в регистр EAX значение 0x40000000:

После выполнения этого кода на VMware Workstation в переменных ID_1, ID_2 и ID_3 будут записаны значения 0x61774d56, 0x4d566572 и 0x65726177 соответственно (в символьном представлении это не что иное, как «VMwareVMware»), на VirtualBox в ID_1 и в ID_2 будет лежать значение 0x00000340, а на Parallels Workstation в ID_1 0x70726c20, в ID_2 — 0x68797065 и в ID_3 — 0x72762020 (что соответствует строке «prl hyperv»).

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

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

Вытащить эти первые три байта из MAC-адреса нам поможет API-функция GetAdaptersInfo:

Вспомогательные процессы, окна и другие «подозрительные» объекты

Для нормальной работы практически все виртуальные машины требуют установки дополнений к гостевой операционной системе, например VBoxGuestAddition для VirtualBox или Parallels Tools для Parallels Workstation. Без этих дополнений работа с виртуальной машиной несколько затруднительна (ни тебе нормального разрешения экрана и полноэкранного режима, ни взаимодействия с USB-девайсами, ни нормальной настройки сетевых подключений). В общем, все производители виртуалок не рекомендуют использовать их без этих дополнений. А эти самые дополнения оставляют очень заметный след в виде запущенных процессов:

Для поиска процесса по имени мы воспользуемся функциями CreateToolhelp32Snapshot, Process32First и Process32Next:

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

Открытые окна для VMware (красным выделено окно класса VMSwitchUserControlClass)

Найти окно по имени класса очень просто — для этого есть функция FindWindow:

Помимо процессов и окон, указывающих на наличие ВМ, можно найти и другие «подозрительные» объекты — например, если покопаться в гостевой ОС виртуальной машины утилитой WinObj или какой-нибудь аналогичной, то можно найти вот такие объекты:

«Подозрительные» объекты в VirtualBox

Проверить наличие «подозрительного» объекта очень просто, достаточно попытаться открыть его с помощью CreateFile:

Что еще «подозрительного» можно найти в реестре?

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

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

Ключ PRLS__ в реестре Parallels Workstation

Возможности, заложенные производителем

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

В Virtual PC используются инвалидные (не «инвалидные», а «альтернативно одаренные». И вообще-то они «недействительные». — Прим. ред.) команды процессора с опкодами 0x0F, 0x3F, 0x07 и 0x0B, попытка выполнения которых на реальном процессоре вызовет исключение, в то время как на Virtual PC все пройдет нормально. С помощью этих команд можно достаточно просто задетектить виртуалку от Microsoft:

В VMware Workstation для взаимодействия гостевой и основной ОС реализован небольшой бэкдор в виде порта с номером 0x5658. Для его использования необходимо в EAX положить «магическое» число 0x564d5868 (в символьном представлении — «VMXh»), а в ECX записать одну из команд взаимодействия гостевой и основной ОС (например, команда 0x0A возвращает версию установленной VMware Workstation). Короче, выглядит все это приблизительно так:

Заключение

Как видишь, признаков, характерных для виртуальных машин, предостаточно, и для того, чтобы их увидеть, сильно глубоко копать совсем не нужно.

Источник