Hackear Azure Bastion y Azure Container Registry a través de vulnerabilidades XSS

Se ha descubierto que Microsoft Azure Bastion y Azure Container Registry tienen una falla de seguridad potencialmente “peligrosa” que, si se aprovecha, puede haber resultado en un ataque de secuencias de comandos entre sitios (XSS) que se lleva a cabo en el servicio afectado. Los ataques XSS ocurren cuando los actores de amenazas insertan código arbitrario en un sitio web en el que, de otro modo, se confiaría. Este código se ejecuta cada vez que los visitantes que no conocen el ataque visitan el sitio web.

Ambas vulnerabilidades que encontró Orca utilizan una vulnerabilidad en el iframe posterior al mensaje, lo que hace posible que los objetos de Windows se comuniquen entre sí a través de dominios. Las vulnerabilidades permitieron el acceso ilegal a la sesión de la víctima dentro del iframe del servicio de Azure comprometido. Esto puede resultar en repercusiones graves, como el acceso no autorizado a los datos, las alteraciones no autorizadas y la interrupción de los iframes de los servicios de Azure, entre otras cosas. Esto significaba que la vulnerabilidad podría explotarse para incrustar puntos finales en servidores remotos utilizando el elemento iframe. Eventualmente, esto resultaría en la ejecución de un código JavaScript malicioso, que comprometería los datos confidenciales.

Sin embargo, para aprovechar estas vulnerabilidades, un actor de amenazas primero necesitaría realizar un reconocimiento en varios servicios de Azure para identificar los puntos finales vulnerables contenidos dentro de la interfaz de Azure. Es posible que a estos puntos finales les falten encabezados de X-Frame-Options o tengan políticas de seguridad de contenido (CSP) que no sean adecuadas.

El atacante continuará explotando el punto final mal configurado después de haber incrustado con éxito el iframe en un servidor remoto. Se están concentrando en el controlador postMessage, que es responsable de manejar eventos remotos como postMessages.

Posteriormente, el adversario podría construir cargas útiles adecuadas al incorporar el iframe vulnerable en un servidor controlado por un actor (por ejemplo, ngrok) y establecer un controlador de mensaje posterior que entregue la carga útil maliciosa si primero analizaron los mensajes posteriores enviados al iframe desde portal.azure[ .]com y luego analizó los mensajes posteriores enviados desde portal.azure[.]com al iframe.

Debido a esto, cuando se engaña a una víctima para que visite el punto final comprometido, la “carga maliciosa posterior al mensaje se entrega al iframe incrustado, lo que activa la vulnerabilidad XSS y ejecuta el código del atacante dentro del contexto de la víctima”.

Durante el curso de una prueba de concepto (PoC), se descubrió que un postMessage que se había escrito cuidadosamente podría usarse para modificar el exportador SVG de Azure Bastion Topology View o el inicio rápido de Azure Container Registry para llevar a cabo una carga útil XSS.