Resumen
El 13 de mayo de 2015, el investigador de seguridad Jason Geffner de CrowdStrike reveló públicamente una vulnerabilidad en algunas plataformas de virtualización que podría permitir un atacante para saltar fuera de la zona de pruebas de una máquina virtual (VM) y obtener acceso al host de virtualización protegido. La vulnerabilidad ha sido bautizada como "VENOM", por Manipulación de operaciones descuidadas del entorno virtualizado (CVE-2015-345) y afecta a cualquier host de virtualización sin parches creado en el emulador QEMU de código abierto, incluidos Xen, KVM y VirtualBox de Oracle. Las tecnologías que no emplean QEMU, como VMWare, Hyper-V de Microsoft y Bochs, no se ven afectadas.
Manual de virtualización
La virtualización, en términos generales, es una implementación de tecnología que permite que una computadora grande subdivida sus recursos (procesador, memoria, espacio en el disco duro, por ejemplo) para ejecutar muchas computadoras virtuales más pequeñas. Cada una de estas máquinas virtuales se ejecuta como si fuera un sistema discreto, aislado de las otras máquinas virtuales que se ejecutan en el mismo host. Esta arquitectura permite a los operadores de servidores administrar e implementar servidores más fácilmente, ya que pueden crear una nueva máquina virtual en mucho menos tiempo del que se necesitaría para crear una versión física. También permite a los operadores de centros de datos y proveedores de hosting hacer un uso más eficiente de sus recursos. Un host de virtualización que ejecuta, por ejemplo, 10 VM usa una fracción del espacio, la energía y la refrigeración que usan 10 máquinas físicas equivalentes.
¿Qué puede hacer un exploit contra VENOM?
Uno de los otros beneficios de una plataforma de virtualización es la capacidad de segregar máquinas virtuales. Entonces, aunque puedan usar el mismo hardware compartido, las máquinas virtuales están aisladas. Tal aislamiento permite que un administrador de servidor aprovisione diferentes VM, ejecutando diferentes sistemas operativos, para diferentes clientes. Esos clientes nunca sabrían que estaban compartiendo recursos en un host de virtualización con otros clientes. E incluso si tuvieran privilegios de raíz o administrador en sus máquinas virtuales, la contención les impide hacer cualquier cosa que pueda afectar a cualquier otra máquina virtual.
Este concepto de infraestructura en silos es lo que hace que la idea de una vulnerabilidad como VENOM sea tan preocupante. Como describe Geffner en el sitio web de CrowdStrike:
Esta vulnerabilidad puede permitir que un atacante escape de los confines de un invitado de máquina virtual (VM) afectado y, potencialmente, obtenga acceso de ejecución de código al host. En ausencia de mitigación, este escape de VM podría abrir el acceso al sistema host y a todas las demás VM que se ejecutan en ese host, lo que podría otorgar a los adversarios un acceso elevado significativo a la red local del host y los sistemas adyacentes.
Para un proveedor que ha confiado en la seguridad del aislamiento de máquinas virtuales, una vulnerabilidad de este tipo puede causar bastante alarma.
¿Cuánta alarma?
Si bien el anuncio de esta vulnerabilidad se ha comparado, en algunos medios de comunicación, con Heartbleed, es importante sopesar lo que se sabe con lo que es posible y probable.
Según Geffner, la "vulnerabilidad de VENOM existe desde 2004", aunque no se ha documentado ningún exploit conocido (hasta el momento de escribir este artículo). Geffner compartió sus hallazgos con los principales proveedores de virtualización que utilizan QEMU el 20 de abril de 2015. Una vez que se desarrolló un parche, publicó sus hallazgos en el sitio web de CrowdStrike el 13 de mayo de 2015.
Sin embargo, hasta la fecha, no se ha demostrado ninguna prueba de concepto pública. Actualmente no sabemos qué tan simple o difícil es crear un código que pueda explotar VENOM. Dado que VENOM deja un sistema abierto al ataque a través del viejo amigo del pirata informático, el desbordamiento del búfer, podría, en su forma más simple, ser explotado para hacer que la máquina host se bloquee, lo que resultaría en una denegación de servicio. Con más cuidado e inteligencia, un atacante podría obtener acceso al propio host de virtualización y comprometer las otras máquinas virtuales que se ejecutan en ese mismo host.
¿Qué podemos hacer para protegernos?
Dado que VENOM se divulgó de manera responsable, dando tiempo a los proveedores para producir un parche, corresponde a los administradores de host de virtualización aplicar el parche lo más rápido posible. Las personas cuyos servicios se ejecutan en máquinas virtuales que se ejecutan en una plataforma de virtualización compartida pueden hacer poco por sí mismas. Sin embargo, pueden visitar el sitio web de su proveedor para ver si son vulnerables y qué pasos se están tomando para abordar la vulnerabilidad. Si es necesario, pueden ejercer presión para obligar a sus administradores a parchear sus sistemas antes de que esta amenaza potencial se convierta en un exploit funcional muy utilizado por el lado más oscuro de Internet.
Para seguir más información sobre lo que está haciendo Atlantic.Net para abordar la vulnerabilidad de VENOM, consulte nuestro blog para conocer las últimas novedades. Nos esforzamos constantemente para ofrecer los servidores privados virtuales más seguros que ofrecen lo mejor en aplicaciones de instalación con un solo clic, como cPanel Hosting, entre otras.
Actualizado el 15 de mayo de 2015 para incluir el vínculo del blog de Atlantic.Net