El servicio Azure API Management es una plataforma que está completamente administrada y ofrece a las empresas la capacidad de diseñar, administrar, proteger y evaluar sus interfaces de programación de aplicaciones (API) en cualquier entorno. Ofrece una ubicación centralizada desde la cual las API se pueden publicar fácilmente para desarrolladores internos y externos, así como para socios y empleados. Con Azure API Management, las empresas pueden hacer crecer con confianza su programa de API y, al mismo tiempo, garantizar que sus API sean accesibles, seguras y funcionen al máximo de sus capacidades. La capacidad de crear esquemas para la estructura de los datos que se enviarán a través de la API se incluye en la administración de las API. La estructura de los datos se puede validar con el uso de estos esquemas, que las empresas pueden emplear para asegurar la compatibilidad entre los clientes y servidores de la API. Con el sitio de Azure API Management o la API REST, debería poder crear y mantener esquemas.
Un estudio reciente realizado por el equipo de investigación de Ermetic descubrió tres vulnerabilidades en el servicio Azure API Management. En una carga de trabajo interna de Azure, estas incluían dos vulnerabilidades SSRF, que significan falsificación de solicitudes del lado del servidor, y una vulnerabilidad transversal de la ruta de carga de archivos. En la interfaz de desarrollador de API Management, las vulnerabilidades se desencadenaron mediante el uso de omisiones de formato de URL y una función de carga de archivos sin restricciones. SSRF es una vulnerabilidad que le da a un atacante la capacidad de enviar una solicitud construida desde un servidor susceptible a un servidor o servicio externo o interno seleccionado. Un atacante puede explotar esta vulnerabilidad para obtener acceso a información confidencial. Los atacantes podrían enviar archivos maliciosos a la carga de trabajo interna alojada de Azure, así como a los portales de desarrolladores autohospedados si se aprovechara la vulnerabilidad transversal de la ruta de carga de archivos.
SSRF completo en el proxy CORS de Azure API Management
Los clientes ahora pueden obtener un esquema de una URL y usarlo en su API gracias a la adición de la capacidad “Importar desde URL” en Azure API Management. Esta característica fue creada por Azure. Cuando haya terminado de especificar la URL del esquema, el proxy CORS de Azure API Management recuperará el esquema enviando una solicitud HTTP a la URL especificada para recuperarlo. A través del proceso de interceptar, modificar y agregar encabezados de CORS, el proxy de CORS permite una comunicación ininterrumpida entre dominios.
Los atacantes pueden realizar solicitudes entre el proxy CORS del servicio y el propio proxy de alojamiento utilizando las vulnerabilidades de SSRF. Esto permitiría a los atacantes acceder a los activos internos de Azure, rechazar el servicio y eludir los firewalls de aplicaciones web.
Pudieron acceder a los servicios internos de Azure usando esto para superar la redirección en los siguientes puertos:
30001 – Vista autenticada del portal de desarrolladores
30004 – API de administración de Azure
30005 – Administración de la API Kudu de Azure
30006 – Sitio de desarrollador no publicado (Unauth)
Después de ingresar Ocp-Apim-Url que apuntaba a su servidor de redirección, recibieron una visita del proxy CORS, que siguió con éxito su redirección a la siguiente ubicación: http://localhost:30005/test.
SSRF completo en el proxy de hospedaje de Azure API Management
Los usuarios tienen la capacidad de especificar el procesamiento de entrada, salida y entrada de la API mientras configuran el servicio. Al configurar la URL del servicio de backend de una API de manera dinámica, lo que deberá usar es la política “set-backend-service”. El valor del parámetro “base-url” se usa para determinar cuál será la URL de back-end cuando se aplique la política. Durante la investigación de la funcionalidad, descubrieron que el proxy de API Management, ubicado en https://apimanagement.hosting .portal.azure.net/, se usó tanto en el procesamiento entrante como saliente para establecer las reglas. Una solicitud que se realiza desde el frontend que el usuario especifica se enviará primero al proxy de procesamiento de entrada y luego se reenviará al backend que el usuario haya definido.
Abusar de la política de set-backend-service y dirigirlo al sitio deseado para un exploit SSRF, como http://localhost, es una forma en que se puede abusar de SSRF.
Ruta transversal de carga de archivos sin restricciones en el portal para desarrolladores de API Management
Además, investigaron el portal de desarrolladores de Azure para el servicio API Management y, durante su investigación, descubrieron que el servidor admitía cargas de archivos sin restricciones. El modo autorizado del portal para desarrolladores le brinda la posibilidad de enviar archivos estáticos y gráficos que pueden mostrarse en su propio portal dedicado. En pocas palabras, este hallazgo tiene repercusiones no solo para el propio Microsoft Azure, sino también para los clientes finales que han configurado el portal para desarrolladores de forma independiente. En una “publicación” del portal, los archivos se cargan en un blob especial de Azure y en el sistema de archivos del portal para desarrolladores, ambos hospedados por Azure y no están disponibles para los usuarios de Azure. A través del portal para desarrolladores, los usuarios pueden acceder a los archivos en la ruta especificada, así como en /content/x.png como ubicación predeterminada.
Se ha dado cuenta de que Azure no verifica ni el tipo de archivo ni la ubicación de los archivos cargados. Los usuarios autenticados pueden atravesar la ruta que se indica cuando se cargan los archivos, cargar archivos maliciosos en el servidor del portal del desarrollador y quizás ejecutar código en él empleando el secuestro de DLL, el intercambio de configuración de iisnode o cualquier otro vector de ataque apropiado. Los usuarios autenticados también pueden descargar archivos del servidor.
El servicio de administración de API de Azure se volvió vulnerable debido a estas tres vulnerabilidades diferentes, todas las cuales ahora han sido corregidas por MSRC.
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
