¿Qué tan seguras son realmente las máquinas virtuales? ¿Falsa sensación de seguridad?

Las máquinas virtuales definitivamente pueden cruzar. Por lo general, los tiene conectados en red, por lo que cualquier malware con un componente de red (es decir, gusanos) se propagará a donde su direccionamiento / enrutamiento lo permita. Los virus regulares tienden a operar solo en modo de usuario, por lo que si bien no pudieron comunicarse abiertamente, aún podrían configurar un canal oculto. Si está compartiendo CPU, un proceso ocupado en una máquina virtual puede comunicar efectivamente el estado a otra máquina virtual (ese es su canal secreto de tiempo prototípico). El canal secreto de almacenamiento sería un poco más difícil, ya que los discos virtuales tienden a tener un límite estricto, por lo que, a menos que tenga un sistema que pueda sobrepasar el espacio en disco, no debería ser un problema.

El enfoque más interesante para proteger las máquinas virtuales se llama Kernel de separación . Es un resultado del documento de 1981 de John Rushby, que básicamente establece que para tener máquinas virtuales aisladas de una manera que podría ser equivalente a la separación física, la computadora debe exportar sus recursos a máquinas virtuales específicas de manera que en ningún punto ningún recurso que pueda almacenar el estado se comparta entre las máquinas virtuales. Esto tiene profundas consecuencias, ya que requiere que la arquitectura de la computadora subyacente se diseñe de una manera en que esto pueda llevarse a cabo de una manera que no pueda evitarse.

30 años después de este documento, finalmente tenemos pocos productos que dicen hacerlo. x86 no es la mejor plataforma para esto, ya que hay muchas instrucciones que no se pueden virtualizar, para apoyar completamente la idea de "no compartir". Tampoco es muy práctico para los sistemas comunes, ya que para tener cuatro máquinas virtuales, necesitaría cuatro discos duros que cuelgan de cuatro controladores de disco, cuatro tarjetas de video, cuatro controladores USB con cuatro ratones, etc.

A lo largo de los años, se han publicado algunos informes que describen las formas en que los investigadores han logrado infestar un sistema operativo host desde una máquina virtual. Estos se suelen considerar, con razón, como vulnerabilidades de seguridad por parte de los proveedores de máquinas virtuales y se tratan como tales. Desde la primera vez que vi esos documentos, Intel ha realizado algunas mejoras significativas en el conjunto de instrucciones del procesador al permitir la separación de la máquina virtual y el hipervisor.

Las pocas vulnerabilidades que veo en estos días se basan más en la parte 'vmtools'. Este es el software que instala para hacer que el sistema operativo invitado se ejecute de manera más eficiente (para VMWare esto es lo que permite la captura del cursor de vuelo y el intercambio entre el invitado y el host sin una red). Esta es una ruta de software especial para la infección; no instale las herramientas, no tiene la vulnerabilidad.

Algunos programas maliciosos han demostrado la capacidad de detectar que se están ejecutando dentro de una máquina virtual y, por lo tanto, cambian su comportamiento, en gran medida por la cantidad de investigadores malintencionados que intentan usar máquinas virtuales como una forma de probar el software malicioso. . Sin embargo, no sé cuán frecuente es en estos días.

Un ejemplo de ejecución de código de invitado a host se puede encontrar en el exploit de Cloudburst. Hay un video que lo demuestra y un documento de Immunity detallando su éxito en VMware Workstation 6.5.0 build118166 en un Windows Vista SP1, VMware Workstation 6.5.1 build126130 en un Windows Vista SP1, y (aún más aterrador) VMware ESX Server 4.0.0 build133495.

Es probable que esto sea poco reconfortante, pero nunca he escuchado que se use de forma salvaje y que el exploit sea de 2009. Ese libro se publicó en 2010, por lo que el autor debería limpiar esa afirmación.

Una máquina virtual es exactamente eso, una máquina lógicamente separada, por lo que debe tener las mismas capas de seguridad colocadas en ella como lo haría con un sistema simple. El uso de una máquina virtual no detendrá una vulva si utiliza canales normales para llegar a la máquina host.

La verdadera belleza de la virtualización es la capacidad de revertir las máquinas virtuales a un estado en el que no fueron afectadas, así como la capacidad de administrar mejor los recursos disponibles.

Si se toman los pasos adecuados para proteger la máquina host, la virtualización puede ser extremadamente segura. Prácticas como mantener la administración del servidor ESX / VM en una red lógica diferente y no usar las herramientas de interconexión de VM-host mantendrán a los atacantes mayormente ajenos al hecho de que una máquina es virtual, y mucho menos cómo llegar al host.

También, existen vulnerabilidades conocidas que afectan a los hosts de VM (he jugado con ellos en VMWare y Hyper-V). Actualmente solo soy consciente de las vulnerabilidades del DoS del host cuando se trata de hyper-v (consulte esto ), pero estoy Seguro que hay otros hallazgos en el horizonte. VMWare también tiene algo en su historial (es decir, esto , se basa en las herramientas de VMWare, pero aún se aplica).

Dependiendo de lo que esté haciendo, hay algunas herramientas en línea que pueden quitarle la necesidad de hacer el análisis en su propia máquina. Aquí hay algunos sitios para echar un vistazo a:
 - Threatexpert.com
 - anubis.iseclab.org
 - virustotal.com

Lo que se entiende por el material de Security + es que hasta ahora el malware no ha podido escapar de la caja de arena de la máquina virtual a través de la explotación del hecho de que es una máquina virtual y de alguna manera llegar al hipervisor. Otros mecanismos, como la difusión a través de una red compartida, son los mismos que si se tratara de cajas físicas diferentes.

No están perfectamente seguros, como se demuestra con esta vulnerabilidad:

VENOM, CVE-2015-3456, es una vulnerabilidad de seguridad que afecta a algunas plataformas comunes de virtualización de computadoras, especialmente Xen, KVM, VirtualBox y el cliente QEMU nativo.

Esta vulnerabilidad puede permitir a un atacante escapar de los confines de un invitado de una máquina virtual (VM) afectada y, potencialmente, obtener acceso de ejecución de código al host. Más detalles Aquí puede encontrar información sobre la vulnerabilidad .

Creo que la afirmación del autor es no completamente verdadera. En realidad, hay dos tipos de hipervisor en el área de virtualización. Hypervisor es una pieza de software, firmware o hardware que crea y ejecuta máquina virtual s. Esos tipos son:

• Hipervisores de tipo 1
• Hipervisores de tipo 2

El hipervisor tipo 1 se ejecuta directamente en el hardware del host para controlar el hardware y administrar los sistemas operativos invitados. Por esta razón, a veces se les llama hipervisores bare metal whereas El hipervisor de tipo 2 se ejecuta en un sistema operativo convencional Así como lo hacen otros programas de computadora. VMWare o VirtualBox son ejemplos de hipervisor de tipo 2 porque se ejecutan como programas en el host OS s.

Para los hipervisores de Tipo 2, existe el proyecto RoboLinux que tiene una característica única llamada Stealth VM . Instalador de software Stealth VM que le permite crear un clon de Windows 7 ejecutándose en una partición de Linux segura . El sistema está protegido contra malware, todo lo que descargue estará contenido en dentro de la máquina virtual y está destinado a personas que deben tener un programa específico de Windows con la comodidad de poder restaurar el sistema operativo como Nuevo en solo dos clics.

Hay Qubes OS que se desarrolla en Linux y Xen como ejemplo para hipervisores de Tipo 1. El sistema operativo Qubes adopta un enfoque llamado seguridad por aislamiento , que en este contexto significa mantener las cosas que hace en su computadora aisladas de manera segura en máquinas virtuales diferentes para que una máquina virtual no se vea comprometida. Afecta a los demás. A diferencia de los hipervisores de Tipo 2, tiene un sistema de transferencia de archivos entre máquinas virtuales para manejar el riesgo de compartir carpetas. En teoría, esa organización es más segura que la virtualización de tipo 2 según los desarrolladores.

En resumen, el autor debe indicar cuál hipervisor o sistema virtual.

Referencias :

• enlace
• enlace
• enlace
• enlace
• enlace

De interés y relevancia, el concurso de seguridad "Pwn2Own" para 2016 tiene como una de sus competencias, escapar de una máquina virtual VMWare Workstation. (Otros incluyen escaparates de arena del navegador o hacerse cargo de máquinas físicas). Eso debería dar una idea de que 1) es al menos plausible y 2) si es fácil, entonces tenemos una manera de escucharlo, simplemente verifique el resultado :)

Más en general, la seguridad de las máquinas virtuales podría, en teoría, escaparse de muchas maneras. Por ejemplo -

• Invitado para alojar comandos y API (por ejemplo, herramientas de VMware)

• Las debilidades explotables en el sistema operativo host en sí no se mitigan al ejecutarse en un proceso de máquina virtual (si algunas llamadas de sistema operativo huésped se consideran erróneamente "seguras" y se transfieren directamente al sistema operativo host o al controlador de dispositivo para velocidad, pero existe un exploit)

• Errores en los controladores del proveedor o en el código del proveedor (por ejemplo, un controlador del host permite el puente de la red para el sistema operativo invitado; tal vez un error en el mismo podría permitir que se realicen llamadas o códigos en el host en el nivel del kernel). / p>

• Vulnerabilidades resultantes de otro software en el host (ejemplo ideado: si el antivirus local intercepta todo el tráfico de red desde el host para escanear, y el tráfico de los invitados se analiza como parte de eso (en lugar de ignorarlo debido a la NIC virtual) dispositivo), entonces una vulnerabilidad del motor a / v a un paquete o tráfico malicioso podría ser capaz de permitir que el tráfico que se origina en la VM se escape al host)

• Configuración incorrecta por usuario (los archivos del host se asignaron o no están suficientemente seguros / separados para que el invitado pueda acceder a ellos)

El alcance existe y, dada su prevalencia, seguramente se está examinando activamente en busca de exploits. Seguramente se encontrarán vulnerabilidades si no se aprovechan las vulnerabilidades y necesitarán parches.

Las explotaciones que están específicamente diseñadas para ejecutarse en vms y dirigirse a errores en el núcleo del servidor subyacente son inevitables. Búscalos primero en las plataformas de nube populares.