Добрый день уважаемые форумчане.
Не нашел подобной темы на форуме, решил задать свой вопрос здесь.
Есть ли специальные утилиты или свежие статьи в которых был бы описан процесс обхода детектирования программами, на то что они запустились на виртуальной машине, в моем случае на VirtualBox.
Хочу запустить несколько копий игры на одной физической машине, но разработчики заявили в этого сделать будет нельзя (в данный момент игра в альфе), они будут отслеживать попытки таких запусков.
Вот заранее, так сказать готовлюсь что можно будет сделать.
Заранее спасибо за любую помощь.
Tony
Green Team
21.09.2019 87 14
Думаю разаработчики так же озадачены этим вопросом)) На самом деле не всё так просто и техник определения VM достаточно много, некоторые можешь здесь посмотреть. Нужно знать какую конкретно технику применяет софт и уже от этого отталкиватся. Поэтому заранее врядли получится подготовится и защитится от всех возможных лазеек.
Denver666
Green Team
02.07.2019 10 3
VMware Решение программа не может быть запущена на виртуальной машине
Спасибо за наводку, буду изучать. Надо попробовать посмотреть сниффером что игра отправляет, может что и будет понятно.
Marylin
Mod.Assembler
Red Team
05.06.2019 295 1 298
Надо попробовать посмотреть сниффером что игра отправляет
Как-правило, виртуальные машины имеют на борту строго-определённое железо, типа сетевая карта, чипсет и прочее (смотри в настройках). Поэтому запуск под VM можно определить по этому железу, например запустив API-шпиона (kerberos, apimon, regmon), или иными путями. Софт скорей-всего так и поступает..
Tony
Green Team
21.09.2019 87 14
(kerberos, apimon, regmon)
Возможно ли подобным софтом отследить WMI запросы? Всмысле не запросы классов, а какими иммено объектами этих классов интересуется софтина)
robox
Member
20.09.2019 5 0
Начать можно с этого
Ссылка скрыта от гостей
Ссылка скрыта от гостей
Слава18
Green Team
30.03.2018 28 10
вот ответ на ваш вопрос Романтическая анонимность
Marylin
Mod.Assembler
Red Team
05.06.2019 295 1 298
Возможно ли подобным софтом отследить WMI запросы?
легко написать софт, который будет парсить на VM машину.
Если софт отправляет данные на сервер, то чекай сеть
WMI в любом случае общается с реестром, можно отследить при помощи regmon
InvisibleMan
Green Team
21.11.2019 22 12
Добрый день уважаемые форумчане.
Не нашел подобной темы на форуме, решил задать свой вопрос здесь.
Есть ли специальные утилиты или свежие статьи в которых был бы описан процесс обхода детектирования программами, на то что они запустились на виртуальной машине, в моем случае на VirtualBox.
Хочу запустить несколько копий игры на одной физической машине, но разработчики заявили в этого сделать будет нельзя (в данный момент игра в альфе), они будут отслеживать попытки таких запусков.
Вот заранее, так сказать готовлюсь что можно будет сделать.
Как ускорить работу виртуальной машины Vmware, Oracle VirtualBox и Microsoft Hyper-V
Заранее спасибо за любую помощь.
Источник: codeby.net
VMware: Обход проверки на виртуальную машину.
Некоторые программы, такие как online-игры и специализированный софт, отказываются запускаться на виртуальной машине. Как я понял, программа проверяет некоторые признаки виртуально машины (имена вендоров, VID/PID оборудования и т.д.) и найдя совпадение пишет что-то типа «Sorry, this application cannot run under a virtual machine». Ниже небольшой мануальчик по обходу детекта виртуальной машины для VMware Workstation. Не ручаюсь что на 100% рабочий, потому что вариантов определения виртуалки вагон и маленькая тележка, но самые распространенные проверки он обходит.
Для обхода детектирования виртуальной машины нам понадобятся:
- VMware Workstation v 12.1.0 build 3272444
- Пропатченый файл vmware-vmx.exe с изменными вендорами. Образ BIOS из которого были убраны строки с «VMware» и добавлен серийный номер материнской платы. Скачать можно отсюда.
- Прямые руки.
1. Устанавливаем VMware Workstation. Правилами хостинга запрешено публиковать ломанный софт, можете зайти на самый большой русскоязычный торрент трекер — там есть. Версия нужна 12.1.0 build 3272444, потому что патченный exe-файлик данной версии. Можете попробовать другую на свой страх и риск.
2. Создаем виртуальную машину и устанавливаем на неё операционную систему. Ваш покорный слуга использовал Windows 7, она работает стабильнее и менее требовательна к ресурсам.
3. Устанавливаем VMware Tools. Запускаем виртуальную машину. Далее идем «Виртуальная машина» —> «Установить пакет VMware Tools. «. В виртуальной машине появляется CD с установщиком. Запускаем программу установки, устанавливаем с настройками по умолчанию.
4. Меняем vmware-vmx.exe на файл из архива. (Путь по умолчанию: C:Program Files (x86)VMwareVMware Workstationx64vmware-vmx.exe)
5. Копируем образ BIOS в папку с виртуальной машиной. Можно скопировать в другую папку, только тогда в файле настроек нужно прописывать полный путь к файлу.
6. Правим файл с настройками виртуальной машины (файл с расширением .vmx) любым текстовым редактором. Добавляем строки:
monitor_control.restrict_backdoor = «true»
cpuid.1.ecx=»0—:—-:—-:—-:—-:—-:—-:—-«
bios440.filename = «6006.ROM»
isolation.tools.copy.disable = «TRUE»
isolation.tools.dnd.disable = «TRUE»
isolation.tools.paste.disable = «TRUE»
7. Устанавливаем нужную программу и пробуем запустить.
Обратите внимание, что пакет VMware Tools нужно установить ДО замены exe-файла и правки настроек виртуальной машины. В противном случае установщик скажет, что его нужно ставить только на виртуальную машину и отменит установку. А без установленного пакета недоступны некоторые важные функции, например, работа с 3D графикой.
БОльшая часть информации и файлы взяты отсюда. За что автору огромное спасибо!)
Источник: tmie.ru
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:
typedef enum < CP_CMD_REQUEST_CLIPBOARD = 2000, CP_CMD_REQUEST_FILES, CP_CMD_RECV_CLIPBOARD, CP_CMD_SEND_CLIPBOARD, CP_CMD_GET_FILES_DONE, CP_CMD_SEND_FILES_DONE, >CopyPasteCmdV4;
Пакет 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. Для тех, кто хочет поближе ознакомиться с эксплойтом, здесь его исходный код.
И небольшая демонстрация данной атаки:
Использование устаревших уязвимых технологий
VMGL
Этот частный случай, хоть и относится больше к 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 все же возможен, что определенно должно вас заволновать, если вы, по какой-либо странной причине, все еще используете этот заброшенный проект.
Фрагмент патченого Chromium (utilnet.c) в составе VirtualBox (теперь уязвимые обработчики команд попросту физически не существуют на хосте):
Заключение
Эти незамысловатые и довольно простые в эксплуатации методы приносят результат и встречались нам на практике в некоторых атаках. Так что VM escape – это не только хардкорная эксплуатация бинарных уязвимостей с обходом различных механизмов безопасности, но и хорошо забытое старое.
- Блог компании Digital Security
- Информационная безопасность
Источник: habr.com