17 mar 2016

0Day: XSS en VMWare por Álvaro Trigo

Normalmente cuando uno prepara la revisión de seguridad de un producto comercial espera encontrarse una revisión complicada, donde la mayoría de los controles son correctamente implementados dificultando la labor del auditor. Sin embargo, en una de las últimas asignaciones que tuve el año pasado, tuve la ocasión de revisar un producto comercial de VMware donde pude detectar y reportar una vulnerabilidad no conocida por el fabricante. Desgraciadamente para mí, la vulnerabilidad no fue encontrada ni en un ESXi, ni en un Player o una Workstation, sino en un producto menos conocido destinado a servir de ayuda en la gestión financiera de los departamentos de TI: VMware vRealize Business (http://www.vmware.com/es/products/vrealize-business).

La vulnerabilidad en cuestión es un Cross-Site Scripting persistente en uno de los módulos de la aplicación destinado a mostrar cuadros de mando e informes pregenerados. Si bien estoy casi seguro que existen vulnerabilidades similares en otras secciones, por limitaciones en la ventana de pruebas, sólo pude verificar la existencia de la vulnerabilidad en este. La explotación de la vulnerabilidad no tiene mayor misterio: cuando detecté tras las primeras pruebas que al modificar el título de alguno de los informes no se realizaba un filtrado adecuado de los caracteres HTML enviados, lo siguiente fue hacer una batería de pruebas para ver si era capaz de inyectar en la respuesta del servidor código Javascript.


En los primeros intentos, pude percatarme como algunos tags clásicos como el “<script>” se encontraban correctamente filtrados, tanto si se eran enviados en texto claro como si eran encodeados de alguna manera. De este modo, para poder hacer la inyección, me tuve que valer de otras etiquetas acabando por encontrar la manera con aquella destinada a incluir imágenes en aplicaciones HTML, “<img>”. Si el título del informe es modificado de la siguiente manera, el código Javascript acaba siendo ejecutado por el navegador del usuario cada vez que éste acceda al módulo de informes (obteniendo así el carácter de persistencia):

Cost vs. Budget Trend</h2><img src="dummy" onerror="javascript:alert(23);"

Lo que hemos hecho es inyectar una imagen inexistente y forzar la ejecución de código en el evento “onerror”, en este caso la ejecución de un inofensivo cuadro de diálogo:


Investigando en las diferentes listas y páginas destinadas a recopilar vulnerabilidades conocidas, no encontré nada relativo a este producto, por lo que decidí ponerme en contacto con VMware a través de su Security Response Center y confirmar si se trataba o no de un Zero-Day. 

Para poder hacer un reporte de una vulnerabilidad a VMware, seguí el procedimiento publicado en la siguiente URL: https://www.vmware.com/support/policies/security_response.html. Básicamente el punto de contacto lo gestionan a través de un correo electrónico, security@vmware.com, recomendando hacer uso de cifrado PGP. Para ello, tienen a su vez disponible su clave pública en el siguiente enlace: kb.vmware.com/kb/1055

La comunicación del hallazgo se dio en malas fechas, y mi interlocutor cambió en varias ocasiones. Sin embargo, la respuesta por parte de VMware siempre fue diligente confirmándome a las dos semanas la vulnerabilidad. A partir de ese momento, el trabajo se centró en la investigación de las ramas o versiones de la aplicación que podían verse afectadas, ofreciéndome a colaborar en su resolución en todo momento. En total, los trabajos de investigación y corrección se llevaron a cabo en 3 meses aproximadamente, recibiendo cada cierto tiempo información de los avances realizados.

La experiencia con ellos ha sido muy buena y la satisfacción de que se reconozca tu trabajo muy grande. El único aspecto negativo de esta historia ha sido que aún no he recibido los regalos que me prometieron, seguramente porque se encuentren todavía dando vueltas en alguna de las cintas infinitas de algún aeropuerto…



Artículo cortesía de: Álvaro Trigo

No hay comentarios:

Publicar un comentario