Может ли запущенный в виртуальной машине вирус проникнуть на хостовую систему
П оистине, достоин памятника тот разработчик, которому первому в голову пришла мысль о создании виртуальной машины как изолированной среды, в которой как в ограждённом загоне можно запускать программное обеспечение и даже эмулировать «чужеродные» архитектуры. К самым древним и как ни странно к самым надёжным в плане безопасности относятся виртуальные машины с так называемой полной эмуляцией, например, эмулятор Bochs, выпущенный в далёком 1994 году.
С тех пор, правда, много чего изменилось. Развился и сам Bochs, появились также гипервизоры, динамические виртуальные машины, среди которых особую популярность приобрели всем известные VirtualBox и VMware. Сегодня основной областью применения виртуальных машин является запуск и тестирование различного программного обеспечения, причём рядовые юзеры услугами эмуляторов пользуются даже чаще, чем разработчики.
В том же любимом всеми VirtualBox, к примеру, можно устанавливать операционные системы, а в них в свою очередь инсталлировать программы, игры, изменять параметры, применять твики и проделывать прочие трюки, не опасаясь за стабильность и работоспособность хостовой операционной системы. Некоторые идут ещё дальше, пробуя запускать на виртуальных машинах потенциально опасное или явно вредоносное программное обеспечения. Только вот насколько безопаснымм являются такие эксперименты и какова вероятность, что хитрый вирус, вырвавшись за пределы виртуальной машины, сможет нанести вред реальной операционной системе?
Увы, однозначного ответа на этот вопрос не существует, тем не менее, с большей долей вероятности можно утверждать, что запущенный на гостевой системе вирус, будь он хоть трижды зловредным, сделав своё чёрное дело, в её пределах и останется. Но для этого нужно соблюдать правила игры, иначе и до беды недалеко. Виртуальная машина, на которой предполагается запускать вирусы, должна быть максимально изолирована от основной системы. Максимально — значит не иметь с ней никаких связей насколько это возможно. Ни общих папок, ни дополнений гостевой ОС, ни расшаренных ресурсов, ни подключённых к компьютеру переносных носителей, кстати, прекрасно определяемых некоторыми типами эмуляторов, ни даже доступа к интернету.
Конечно, такие меры предосторожности делают обмен данными между виртуальной и хостовой машиной менее удобным, но в данном примере обеспечение безопасности является более приоритетной задачей. Впрочем, всем вышесказанным проблема не исчерпывается. Не стоит забывать о руткитах, уже давно научившихся распознавать виртуальные машины. Запускаясь в виртуальной среде, руткит ничем не выдаёт себя, а тестировщик, убеждённый в безопасности анализируемого ПО, запускает его на реальной системе, в результате чего последняя оказывается заражённой.
Так как же быть? Единственно верное решение – приобрести недорогой компьютер и проводить сомнительные эксперименты на нём, и если не деньги, то уж нервы себе точно сэкономите. В крайнем случае для запуска потенциально опасного ПО следует использовать виртуальные машины с полной эмуляцией, такие как Bochs, которые хоть и не обладают стопроцентной защитой от руткитов, но всё равно в плане безопасности на порядок превосходят VMware, VirtualBox, Virtual PC, мелких уязвимостей в которых хватало и будет хватать всегда.
Источник
Виртуальная машина и вирус
У меня есть требование, по которому я должен выходить в интернет без защиты (брандмауэр, антивирус). В то же время я не хочу рисковать заражением вирусами.
Если я установлю виртуальную машину (VirtualBox) для тестирования, и она будет заражена вирусами, это также заразит мою хост-систему? Другими словами, могу ли я использовать виртуальную машину для тестирования, не опасаясь вируса на виртуальной машине, заражающего мой хост?
Если я установлю виртуальную машину (VirtualBox) для тестирования, и она будет заражена вирусами, это также заразит мою хост-систему? Другими словами, могу ли я использовать виртуальную машину для тестирования, не опасаясь вируса на виртуальной машине, заражающего мой хост?
Кажется, есть некоторые неправильные представления о NAT и мостовых соединениях в виртуальных средах. Это не позволяет вашему хосту быть зараженным. Операционная система виртуальной машины не будет иметь никакого доступа к операционной системе хоста и совершенно не будет знать, что она работает как клиентская виртуальная машина. Программное обеспечение, работающее внутри этой операционной системы, будет еще менее мудрым.
Именно через прямые отношения между клиентом и хост-машиной может существовать вероятность заражения. Это происходит, если вы разрешаете клиенту и хосту совместно использовать папки . Самая большая уязвимость VMware (чтобы назвать один популярный продукт) из когда-либо обнаруженных уязвимостей была прямо или косвенно связана с этой функцией. Полная изоляция достигается путем отключения общих папок. Любая другая уязвимость была обнаружена на стороне хоста, когда уязвимости на самом механизме виртуальной машины позволили бы потенциальному злоумышленнику подключиться через хост-компьютер и получить доступ к любым клиентам или запустить собственный код.
Проблемы безопасности действительно могут быть более сложными, если вы используете большую структуру виртуальной машины, например, предложенную в топологиях VMware Server. Но если используются решения VMware Workstation для одного компьютера, проблем с безопасностью в соединениях NAT или Bridge нет. Вы в безопасности, если вы не используете общие папки.
РЕДАКТИРОВАТЬ: Для ясности, когда я говорю о соединениях NAT или Bridge, я говорю только о способности виртуальной машины совместно использовать соединение сети хоста со своими клиентами. Это не дает клиенту никакого доступа к хосту и остается полностью изолированным при условии, что такие функции, как общие папки виртуальных машин, отключены. Естественно, если вместо этого пользователь решает подключиться к сети Host и Client, то указанный пользователь явно решил соединить обе машины, и вместе с этим поменять внутреннюю безопасность виртуальной машины. Это тогда не станет отличаться от любой другой частной сетевой среды, и те же проблемы с ценными бумагами и проблемы должны быть решены.
Источник
Создаем уязвимые виртуальные машины в два счета с SecGen
Сегодня я хочу обратить ваше внимание на интересный проект SecGen при помощи которого становится возможным иметь каждый день новый Metasploitable или другую виртуальную машину для изучения основ этичного хакинга.
Все происходит в автоматическом режиме, нужно лишь установить фреймворк. Начинаем!
Как это работает?
SecGen представляет из себя скрипт, написанный на ruby. В основе его работы лежат Vagrant и Puppet.
Напомню, что Vagrant — это инструмент, позволяющий быстро и удобно разворачивать целые инфраструктуры из виртуальных машин, используя гипервизоры VirtualBox, VM Ware локально или облачный сервис Amazon AWS. Вы можете описать все настройки будущей виртуальной машины в специальном файле Vagrantfile. И вам не придется скачивать ISO-образы ОС, т.к. Vagrant уже предлагает множество готовых образов виртуальных машин (box), которые можно скачать из специального каталога.
А Puppet — средство автоматизации настройки машин, пришедшее на замену bash скриптам. Puppet имеет понятный язык описания конфигураций. Скрипты хранятся в файлах с расширением .pp. Puppet может установить определенный софт на машину, прежде проверив, что система удовлетворяет требуемым условиям, выполнить его настройку, задать переменные окружения и многое другое.
Таким образом SecGen нужно лишь выбрать какой box скачать и развернуть при помощи Vagrant, какой софт установить и настроить при помощи Puppet и сгенерировать флаги, которые нужно найти пентестеру в процессе эксплуатации.
SecGen имеет модульную структуру и каждый модуль представляет из себя дистрибутив с уязвимым приложением, его настройки, puppet-скрипты и некоторые дополнительные файлы для его корректной обработки SecGen.
Установка
Официально тестирование проводится на дистрибутиве Ubuntu и процесс установки описан на официальном github. Я буду использовать 64-битную Ubuntu 16.04.3, которая сама является виртуальной машиной с 2.5 ГБ RAM.
Устанавливаем требуемые пакеты
Также вам (возможно) потребуется установить еще один пакет, не указанный на официальном сайте
Теперь клонируем репозиторий github
Переходим в созданный каталог и выполняем установку всего необходимого
Начнут устанавливаться необходимые библиотеки Ruby
Проверяем, что скрипт работает
И видим доступные опции
Создаем свою первую машину со случайным набором уязвимостей
Это базовый режим работы SecGen, если никакие ключи не задавать. Выполняем команду
Начнется скачивание Vagrant box-а, который для нас автоматически выбрал SecGen
Когда Vagrant образ виртуальной машины скачался и был импортирован, происходит запуск виртуальной машины
Автоматически настраивается форвард SSH для доступа к машине на порт 2222. Генерируется ключ, SecGen подключается к машине, устанавливает rsync и производит установку и настройку всего необходимого.
Обратите внимание, что если у вашей хостовой машины нет прямого доступа к репозиториям, а вы работаете, например, через прокси, то процесс установки прервется, так как гостевая виртуальная машине не сможет установить rsync. В таком случае вам нужно будет получить прямой доступ к репозиториям, удалить виртуальную машину и снова запустить SecGen с ключом build-vms.
Будут выполнены все необходимые Puppet скрипты
И в конце концов вы увидите сообщение в консоли
И при помощи команды virtualbox можете убедиться, что машина действительно запущена
Анатомия
В каталоге SecGen, помимо прочих, есть директории projects, scenarios и modules.
projects, как и ясно из названия, будет хранить все необходимое для создания виртуальной машины, описанной в проекте. Вы можете удалить машину и заново сгенерировать точно такую же. Для этого нужно будет выполнить следующую команду с указанием проекта
Чтобы получить список проектов, нужно выполнить команду
И получим результат
Аналогично есть ключ build-project, задав который будут созданы конфигурационные файлы для Vagrant и Puppet, но виртуальные машины созданы не будут.
SecGen при запуске без ключе создаст для нас виртуальную машину со случайным набором уязвимостей, но мы можем повлиять на их характер при помощи сценариев. Они хранятся в каталоге scenarios в виде XML файлов и разбиты на категории. По умолчанию используется default_scenario.xml и выглядит он следующим образом
Здесь сказано, что будет создана виртуальная машина с ОС Linux, содержащая две уязвимости типов remote и local. Т.е. сначала нужно будет попасть на сервер через одну уязвимость и потом проэксплуатировать вторую локально.
Обычно из названия сценария становится ясно, какую машину создаст SecGen, например сценарий any_random_vulnerability.xml. Рекомендую ознакомиться с примерами в каталоге scenarios/examples.
Есть довольно сложные сценарии в каталогах scenarios/security_audit и scenarios/ctf.
Для CTF предлагается воспользоваться фронтендом от разработчиков SecGen.
Из описания сценариев становится ясно, что модули делятся на категории. Все модули собраны в каталоге modules и разбиты на
- bases
- build
- encoders
- generators
- networks
- services
- utilities
- vulnerabilities
В свою очередь в каждой из групп есть подгруппы, вроде smb, webapp, bash, ftp и т.п.
Каждый модуль имеет примерно следующую структуру
Файл secgen_metadata.xml подробно описывает модуль. Это необходимо для корректной работы сценариев и выбора этого модуля для подходящего случая
Каталог manifes содержит puppet скрипты configure.pp, init.pp и install.pp
Каталог files содержит необходимые дистрибутивы. В данном случае один файл chkrootkit-0.49.tar.gz
Когда проект создан, вы можете найти в нем файл scenario.xml, описывающий, какие уязвимости были использованы и как вообще получить флаги.
Например в нашем проекте мы можем найти два XML тега vulnerability, указывающие на модули
modules/vulnerabilities/unix/misc/distcc_exec с описанием «Distcc has a documented security weakness that enables remote code execution» и modules/vulnerabilities/unix/desktop/xfce_lightdm_root_login с описанием «Configures XFCE w/ LightDM to automatically login as root without a password\.»
Если из описания модуля непонятно, в чем суть, можно перейти в соответствующий каталог и изучить файлы модуля.
Так же в каталоге проекта есть скрытая директория .vagrant, в которой, в частности, содержится приватный ключ для доступа к серверу по протоколу SSH под пользователем vagrant. Файл private_key.
Таким образом подключиться к виртуальной машине можно следующим образом
команда ifconfig выдаст нам следующий результат
Тестируем
IP адрес мы выяснили и теперь можешь провести тестирование на проникновение. Проверим доступность виртуальной машины с хоста
Сканируем и обнаруживаем следующие открытые порты
Далее при помощи вашего любимого дистрибутива для тестирования на проникновение можно начинать эксплуатацию distcc.
Единственное что, по умолчанию виртуальная машина имеет два интерфейса в режимах NAT и Host-Only, так что получать доступ к ней с внешней машины можно или через настройку проброса портов в NAT интерфейсе.
Или перенастроить машину, которая является точкой входа на использование другого типа интерфейса Virtualbox, доступного извне.
Можно изменить тип интерфейса Host-Only на Bridged, перезапустить машину и назначить статический IP адрес, если в вашей инфраструктуре нет DHCP. И не забыть задать маршруты через мост.
Источник
