Venom, una nueva amenaza con los servicios de cloud y virtualización en el punto de mira

venom

De un tiempo a esta parte se han hecho frecuentes las vulnerabilidades mediáticas, aquellas que, cuando se presentan afirmando suponer un grave problema, ya van acompañadas de su bonito logo e incluso alguna que otra infografía explicando su funcionamiento.

La más reciente de estas vulnerabilidades es Venom, descubierta recientemente por Jason Geffner, investigador senior de la empresa de seguridad CrowdStrike. Según esta investigación, la vulnerabilidad permitiría a un atacante escapar del entorno controlado de una máquina virtual y llegar a afectar a la máquina anfitrión o a otras máquinas virtuales. Pero vayamos por partes.

¿Qué sistemas son vulnerables?

Venom se aprovecha de un fallo en el controlador de la disquetera virtual en QEMU, un conocido paquete de virtualización. Este controlador permitiría a un atacante (o a un malware) con permisos de administrador en una máquina virtual vulnerable acceder al sistema anfitrión y a otras máquinas virtuales que se estén ejecutando en él.

Hay que tener en cuenta que el controlador vulnerable se incluye por defecto en varios sistemas de virtualización además del cliente nativo de QEMU, como Xen, VirtualBox y KVM. También hay otros programas ampliamente usados que no se ven afectados, como VMWare, Microsoft Hyper-V y Bosch.

Debido a que la vulnerabilidad está presente en el código fuente del hypervisor de las máquinas virtuales, el fallo es multiplataforma y afecta a los principales sistemas operativos (Windows, GNU/Linux y Mac OS incluidos).

¿Cómo funciona?

El sistema operativo huésped se comunica con el controlador de disquetera mediante comandos de escritura, lectura, formateo, etc., enviados al puerto de ese controlador. El controlador virtual de disquetera de QEMU utiliza un tamaño fijo del búfer para almacenar estos comandos y los parámetros de datos asociados, y mantiene un registro de cuántos datos espera recibir de cada comando para, tras recibir esa información, ejecutar el comando y vaciar el búfer a la espera del siguiente comando.

El vaciado del búfer se realiza inmediatamente después de haber realizado los comandos admitidos por el controlador de la disquetera, excepto en dos comandos en concreto. Sabiendo estos comandos, un atacante podría enviar datos de parámetros especialmente modificados al controlador para causar un desbordamiento del búfer de datos y permitir así la ejecución de código arbitrario en el hipervisor del anfitrión, ganando así acceso al sistema.

La mayoría de vulnerabilidades anteriores que explotaban fallos similares en máquinas virtuales necesitaban de configuraciones especiales que no venían por defecto o que no se utilizaban normalmente en sistemas securizados. Venom es especial puesto que funciona en varios sistemas de virtualización, es explotable con la configuración por defecto y permite una ejecución directa de código arbitrario.

¿A quién afecta Venom?

Además de, obviamente, a todos los usuarios que utilicen cualquiera de los sistemas de virtualización que usen el controlador de disquetera vulnerable, el principal peligro de Venom es cómo puede afectar a grandes empresas que confían en servicios de virtualización para almacenar datos y sistemas de sus clientes.

Entre estos proveedores de servicios en la nube que hacen uso de sistemas que podrían verse afectados encontramos al gigante Amazon a través de Amazon Web Services, que rápidamente ha lanzado un comunicado para tranquilizar a sus clientes indicando que Venom no supone ningún riesgo para las instancias virtualizadas de sus clientes ni para los datos que se almacenan en estas.

Con la popularidad de los últimos años de los sistemas virtualizados y ubicados en proveedores de este tipo de servicios, algunos se han apresurado a decir que esta vulnerabilidad podría ser peor que Heartbleed. Sinceramente, el hecho de tener que conseguir permisos de administrador en el equipo huésped y que el controlador de disquetera de QEMU solo sea uno entre tantos disponibles, limita bastante las posibilidades de ataque con respecto a Heartbleed.

¿Cómo protegerse de Venom?

El hecho de que la vulnerabilidad se haya publicado de forma responsable ha permitido que muchos de los fabricantes de soluciones de virtualización u otro software que incorporan el controlador vulnerable tengan disponibles o estén trabajando en parches de seguridad al poco tiempo de conocerse el fallo de seguridad.

Así pues, Red Hat ya ha anunciado estar preparando nuevos paquetes que podrán descargarse en breve, para solucionar este agujero de seguridad en sus plataformas Red Hat Enterprise y OpenStack Platform. Asimismo, han publicado una serie de medidas que se pueden aplicar para mitigar posibles ataques.

Por su parte, QEMU y Xen también han publicado boletines de seguridad con instrucciones para mitigar posibles ataques.

Impacto real

Uno de los puntos que sorprende de esta investigación es que el fallo en el controlador de disquetera se introdujo en 2004 y ha estado activo desde entonces. Sin embargo, el investigador destaca que no tiene conocimiento de que se haya usado en ningún ataque y espera que la publicación de su investigación ayude a que se solucione este fallo de seguridad de una vez por todas.

Sabiendo esto, la ventana de exposición real a posibles  ataques empieza ahora que la vulnerabilidad real ya se ha hecho pública. Existen muchos sistemas que pueden ser vulnerables e incluso muchos de estos sistemas puede que no se actualicen incluso tiempo después de haberse publicado los parches que la solucionan. Por eso es importante que todos los administradores de este tipo de sistemas apliquen las soluciones cuando estas estén disponibles.

Recordemos que la posibilidad de acceder a otras máquinas virtuales ubicadas en la misma máquina anfitrión puede suponer el robo de datos confidenciales de todo tipo de empresas. Este es uno de los peores escenarios que muchas fuentes están planteando pero, de momento, no deja de ser eso, una suposición que con la adopción de las debidas medidas de seguridad es difícil que se llegue a producir.

Créditos de la imagen: ludoviς / Foter / CC BY-SA
Post de Josep Albors publicado originalmente en WeLiveSecurity

Crónica de las jornadas X1RedMasSegura Ontinyent