Что будет если запустить вирус в виртуальной машине
Может ли запущенный в виртуальной машине вирус проникнуть на хостовую систему
П оистине, достоин памятника тот разработчик, которому первому в голову пришла мысль о создании виртуальной машины как изолированной среды, в которой как в ограждённом загоне можно запускать программное обеспечение и даже эмулировать «чужеродные» архитектуры. К самым древним и как ни странно к самым надёжным в плане безопасности относятся виртуальные машины с так называемой полной эмуляцией, например, эмулятор Bochs, выпущенный в далёком 1994 году.
С тех пор, правда, много чего изменилось. Развился и сам Bochs, появились также гипервизоры, динамические виртуальные машины, среди которых особую популярность приобрели всем известные VirtualBox и VMware. Сегодня основной областью применения виртуальных машин является запуск и тестирование различного программного обеспечения, причём рядовые юзеры услугами эмуляторов пользуются даже чаще, чем разработчики.
В том же любимом всеми VirtualBox, к примеру, можно устанавливать операционные системы, а в них в свою очередь инсталлировать программы, игры, изменять параметры, применять твики и проделывать прочие трюки, не опасаясь за стабильность и работоспособность хостовой операционной системы. Некоторые идут ещё дальше, пробуя запускать на виртуальных машинах потенциально опасное или явно вредоносное программное обеспечения. Только вот насколько безопаснымм являются такие эксперименты и какова вероятность, что хитрый вирус, вырвавшись за пределы виртуальной машины, сможет нанести вред реальной операционной системе?
Увы, однозначного ответа на этот вопрос не существует, тем не менее, с большей долей вероятности можно утверждать, что запущенный на гостевой системе вирус, будь он хоть трижды зловредным, сделав своё чёрное дело, в её пределах и останется. Но для этого нужно соблюдать правила игры, иначе и до беды недалеко. Виртуальная машина, на которой предполагается запускать вирусы, должна быть максимально изолирована от основной системы. Максимально — значит не иметь с ней никаких связей насколько это возможно. Ни общих папок, ни дополнений гостевой ОС, ни расшаренных ресурсов, ни подключённых к компьютеру переносных носителей, кстати, прекрасно определяемых некоторыми типами эмуляторов, ни даже доступа к интернету.
Конечно, такие меры предосторожности делают обмен данными между виртуальной и хостовой машиной менее удобным, но в данном примере обеспечение безопасности является более приоритетной задачей. Впрочем, всем вышесказанным проблема не исчерпывается. Не стоит забывать о руткитах, уже давно научившихся распознавать виртуальные машины. Запускаясь в виртуальной среде, руткит ничем не выдаёт себя, а тестировщик, убеждённый в безопасности анализируемого ПО, запускает его на реальной системе, в результате чего последняя оказывается заражённой.
Так как же быть? Единственно верное решение – приобрести недорогой компьютер и проводить сомнительные эксперименты на нём, и если не деньги, то уж нервы себе точно сэкономите. В крайнем случае для запуска потенциально опасного ПО следует использовать виртуальные машины с полной эмуляцией, такие как Bochs, которые хоть и не обладают стопроцентной защитой от руткитов, но всё равно в плане безопасности на порядок превосходят VMware, VirtualBox, Virtual PC, мелких уязвимостей в которых хватало и будет хватать всегда.
Виртуальная машина и вирус
У меня есть требование, по которому я должен выходить в интернет без защиты (брандмауэр, антивирус). В то же время я не хочу рисковать заражением вирусами.
Если я установлю виртуальную машину (VirtualBox) для тестирования, и она будет заражена вирусами, это также заразит мою хост-систему? Другими словами, могу ли я использовать виртуальную машину для тестирования, не опасаясь вируса на виртуальной машине, заражающего мой хост?
Если я установлю виртуальную машину (VirtualBox) для тестирования, и она будет заражена вирусами, это также заразит мою хост-систему? Другими словами, могу ли я использовать виртуальную машину для тестирования, не опасаясь вируса на виртуальной машине, заражающего мой хост?
Кажется, есть некоторые неправильные представления о NAT и мостовых соединениях в виртуальных средах. Это не позволяет вашему хосту быть зараженным. Операционная система виртуальной машины не будет иметь никакого доступа к операционной системе хоста и совершенно не будет знать, что она работает как клиентская виртуальная машина. Программное обеспечение, работающее внутри этой операционной системы, будет еще менее мудрым.
Проблемы безопасности действительно могут быть более сложными, если вы используете большую структуру виртуальной машины, например, предложенную в топологиях VMware Server. Но если используются решения VMware Workstation для одного компьютера, проблем с безопасностью в соединениях NAT или Bridge нет. Вы в безопасности, если вы не используете общие папки.
РЕДАКТИРОВАТЬ: Для ясности, когда я говорю о соединениях NAT или Bridge, я говорю только о способности виртуальной машины совместно использовать соединение сети хоста со своими клиентами. Это не дает клиенту никакого доступа к хосту и остается полностью изолированным при условии, что такие функции, как общие папки виртуальных машин, отключены. Естественно, если вместо этого пользователь решает подключиться к сети Host и Client, то указанный пользователь явно решил соединить обе машины, и вместе с этим поменять внутреннюю безопасность виртуальной машины. Это тогда не станет отличаться от любой другой частной сетевой среды, и те же проблемы с ценными бумагами и проблемы должны быть решены.
Вирусы и руткиты в виртуальной машине
Виртуальная машина, на которой предполагается запускать вирусы, должна быть максимально изолирована от основной системы. Максимально — значит не иметь с ней никаких связей насколько это возможно. Ни общих папок, ни дополнений гостевой ОС, ни расшаренных ресурсов, ни подключённых к компьютеру переносных носителей, кстати, прекрасно определяемых некоторыми типами эмуляторов, ни даже доступа к интернету.
Не стоит забывать о руткитах, уже давно научившихся распознавать виртуальные машины.
В крайнем случае для запуска потенциально опасного ПО следует использовать виртуальные машины с полной эмуляцией, такие как Bochs, которые хоть и не обладают стопроцентной защитой от руткитов, но всё равно в плане безопасности на порядок превосходят VMware, VirtualBox, Virtual PC, мелких уязвимостей в которых хватало и будет хватать всегда.
4 ответа 4
Следует различать следующие сценарии выхода вируса из виртуалки:
он может атаковать хост-систему через виртуальную сеть как обычный сетевой червь;
вирус может воспользоваться эксплоитом для конкретной модели VM;
вирус может воспользоваться эксплоитом для процессора.
Так вот, по первому вашему вопросу. Атака вида 1 успешно предотвращается отключенными галочками. Атаки вида 3 отключенными галочками в общем случае не предотвращаются.
Однако, есть мнение что установка гостевых дополнений делает атаку 3 возможнее просто из-за увеличения количества компонентов и их сложности. Особенно сложными являются технологии виртуализации видеокарты. В частности, ранее найденные и сейчас закрытые уязвимости VirtualBox класса RCE относились именно к этой технологии.
Теперь о том сколько виртуальных машин может обойти руткит. Тут все просто: обойдя виртуальную машину, толковый руткит заражает систему одним уровнем выше, после чего начинает работать на ней. И начав работать, он опять делает попытку заразить те системы до которых дотянется.
Список известных «мелких уязвимостей» можно найти поискав в интернете «(имя продукта) CVE».
Обновление На процессорах Intel нашли уязвимость Meltdown, которая, в случае отсутствия закрывающих ее патчей, позволяет любому процессу произвольно читать любые места в оперативной памяти. Поэтому лучше не работайте с важными данными при запущенной виртуалке с вирусами если у вас Intel.
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 повлиять на главный компьютер?
может ли вирус виртуальной машины VirtualBox повлиять на главный компьютер?
8 ответов
очень хороший вопрос.
основная причина, по которой вирус может распространяться от виртуальной машины к операционной системе хоста через сеть. Как только вы начнете использовать сетевой мост между хозяином и гостем вещи становятся более рискованными. Компьютер и виртуальная машина рассматриваются как 2 узла в одной подсети. Червь, который видит эти 2 узла имеет возможность распространения если такая уязвимость нашли.
да, если у вас есть общие папки.
общие папки через ВМ, или сетевой стандарт.
Я не уверен, и не видел никаких вирусов в довольно долгое время, что распространение, как это и редактировать файлы по сети, но это возможно.
просто потому, что это виртуальная машина не означает, что это безопасно, вы просто должны относиться к нему как к другой физической машине в сети.
Так, если вы имеете анти-вирус на вашей главной машине (и других дальше ваша сеть) вы в безопасности, как вы собираетесь быть, но опять же. относитесь к любой виртуальной машине, как к любой другой физической машине.
единственный безопасный способ запустить виртуальную машину-отключить сетевые функции (или полностью отделить ее от сети VLAN). и не имейте никакого вида интерфейса управления на той VLAN.) и все хост/гостевая интеграция, которые включают совместное использование файлов.
Если в Virtualbox нет недостатка безопасности, который позволяет вам вырваться из виртуальной машины (и вы не исправили), то нет. Тем не менее, стоит помнить, что если есть какое-либо сетевое соединение между ними, есть возможность его перемещения на хост, так как он будет перемещаться между обычными машинами в той же сети.
Edit: с точки зрения проверки соединений, самый простой способ-nmap хост от гостя. Используйте ключ-PN, если ваш хост блокирует ping. Если есть какой-то ответ, значит, есть связь. Даже если вы этого не сделаете, все еще есть возможность подключения через другую машину, если она подключена как к хосту, так и к гостю.
технически, ответ да, и с виртуализацией растет все более популярным, ожидать больше атак на хостах через гостевую ОС в forseeable будущем.
Так как мы держим хост довольно голым и делаем всю работу в виртуалах, очень мало обновлений хоста необходимы, ядро, X и виртуализация кода в основном.
Я могу подтвердить, что это возможно, чтобы получить пострадавшие при просмотре в гостевой.
У меня есть Windows 7 в качестве хоста и Ubuntu 12.04 в качестве гостевой системы. У меня также есть ESET Smart Security в Windows 7.
Я работал над гостевой системой и вдруг захотел просмотреть. Я открыл Firefox в гостевой системе и во время поиска нажал на объявление. Это объявление, казалось, вредоносных программ, как ESET (в Хосте) выскочил предупреждение о том, что что-то было заблокировано от установка.
таким образом, объявление нажал на гостя, казалось, влияет на хост. Хотя он был заблокирован, надеюсь, антивирусом хоста. Я думал, что общая папка была единственной ссылкой до сих пор. Но простое сетевое подключение через NAT позволяет вирусу распространяться между системами.
надеюсь, это немного прояснит ситуацию. Это только мой вчерашний опыт, так как я не знаю полной технической информации о том, как это возможно.
немного поздновато для ответа, но влияет может иметь несколько значений. Вирус может содержаться и не иметь риска распространения с виртуальной машины. Однако он по-прежнему может потреблять ресурсы, такие как ЦП, ОЗУ, диск и сеть хост-компьютера.
технически да, потому что VM сохраняет файлы на хост-компьютере, так что его рискованно, и это зависит от вируса