Las vulnerabilidades en Azure API Management resaltan los riesgos de la falsificación de solicitudes del lado del servidor en el desarrollo de API
Microsoft recientemente ha parcheado tres vulnerabilidades en su servicio Azure API Management, dos de los cuales permitieron ataques de falsificación de solicitud del lado del servidor (SSRF) que podrían haber dado acceso a los piratas informáticos a los recursos internos de Azure. Los exploits de prueba de concepto sirven para resaltar los errores comunes que los desarrolladores pueden cometer al intentar implementar restricciones basadas en listas negras en sus propias API y servicios.
Las API web se han convertido en una parte integral del desarrollo de aplicaciones modernas, especialmente en la nube. Permiten que los servicios se comuniquen e intercambien datos, permiten que los clientes que no son navegadores, como aplicaciones móviles y dispositivos IoT, accedan de forma segura a los datos y realicen operaciones en nombre de los usuarios, y permiten que las organizaciones abstraigan los backends de servidores heredados y los conecten rápidamente a aplicaciones y conexiones modernas. servicios. Las API están estandarizadas y son fáciles de usar, en lugar de depender de protocolos heredados y personalizados que no están diseñados para la web.
A medida que las organizaciones han puesto en producción las API a un ritmo acelerado en los últimos años, la cantidad de ataques contra ellas ha aumentado a medida que los atacantes se dan cuenta cada vez más de que las API inseguras podrían proporcionar una puerta trasera a las bases de datos y la infraestructura interna. Según el proveedor de red de entrega de contenido global Akamai, los ataques dirigidos a API y aplicaciones web aumentaron 2,5 veces en 2022 en comparación con 2021. Uno de los vectores de ataque emergentes en los últimos dos años ha sido SSRF. Los errores ProxyLogon, ProxyNotShell y OWASSRF en los servidores de Microsoft Exchange son ejemplos notables que se han aprovechado mucho.
En los últimos dos años, Akamai ha visto un aumento constante tanto en los intentos de ataque como en el tráfico autorizado de análisis de vulnerabilidades en busca de vulnerabilidades SSRF en software que no sea Microsoft Exchange”, dijo Akamai en un informe reciente. “Además, vimos un promedio de 14 millones de intentos de SSRF por día para sondear las API y las aplicaciones web de nuestros clientes de App & API Protector, lo que indica la creciente prevalencia de este vector. Vale la pena señalar este crecimiento y el impacto potencial de la explotación de SSRF en las organizaciones».
SSRF sobre proxies de Azure API Management
Azure API Management de Microsoft es un servicio que permite a las empresas implementar y monitorear servicios alojados en Azure o en sus redes privadas como API. Es un servicio de desarrollador de API que consta de una puerta de enlace API, un plano de gestión y un portal para desarrolladores.
En un ataque SSRF, el atacante debe encontrar una manera de usar la funcionalidad de la aplicación como proxy para acceder a los recursos internos usando la posición privilegiada del servidor y accediendo a la red interna. En otras palabras, si una aplicación o API permite a los usuarios proporcionar una URL y luego rastrea esa URL y devuelve la respuesta, es posible un ataque SSRF a menos que se tomen medidas de seguridad adicionales.
Azure API Management tiene esa característica. Permite a los usuarios especificar un esquema para la estructura de los datos JSON o XML que se espera que se intercambien a través de la API que proporcionan. Sin embargo, Según investigadores de la empresa de seguridad Ermetic, también se puede indicar al servicio que determine automáticamente el esquema realizando una solicitud a una URL proporcionada por el usuario, una función conocida como «importar desde URL». «Una vez que proporciona la URL del esquema, el proxy CORS de Azure API Management recupera el esquema de la URL especificada enviándole una solicitud HTTP», dijeron los investigadores en su informe.
El intercambio de recursos de origen cruzado (CORS) es un mecanismo basado en encabezados HTTP que permite que un servidor web presente navegadores con otros orígenes (servidores) desde los cuales se permite cargar recursos como scripts. En este caso, el proxy de CORS intercepta las solicitudes y modifica los encabezados de CORS para garantizar que se permitan las solicitudes entre dominios entre portal.azure.com y otros servidores.
Después de encontrar esta función, los investigadores de Ermetic pensaron en proporcionar http://localhost o http://127.0.1.1 (la dirección de bucle invertido) como una URL remota para obtener un esquema para ver si el proxy CORS llegaría internamente al servidor mismo, por lo tanto logrando la SSRF. Esto resultó en un error HTTP 403 (Prohibido), lo que indica que había una lista negra en su lugar.
Luego, los investigadores registraron un dominio llamado localhost.me y luego editaron sus registros DNS para apuntar a 127.0.1.1. Entonces, cuando el proxy CORS intentó acceder a http://localhost.me, primero resolvió el DNS e intentó acceder a la dirección IP devuelta, que apunta a sí mismo, sin pasar por la lista negra. Eso funciono. La respuesta que devolvió el proxy CORS fue el error HTTP 404 (página no encontrada), lo que significa que el servidor dejó de rechazar la solicitud pero no tenía ninguna página para servir.
Los investigadores también descubrieron que podían agregar encabezados personalizados a sus solicitudes y hacer que el proxy CORS los reenvíe al servidor de destino, lo que abre la puerta a ataques aún más complejos. Luego intentaron acceder al servidor interno a través de otros números de puerto, no el predeterminado 80, para ver si otros servicios podían ejecutarse en puertos personalizados y descubrieron que estaban tratando de usar números de puerto que contenían «300». B. 300, 3000 o 30000, obtuvieron el error 403 Prohibido nuevamente.
«Comprendimos que si un Regex [regular expression] existe específicamente para estos puertos, algunos servicios importantes deben estar escuchando en estos puertos», dijeron los investigadores.
Una expresión regular es una regla de búsqueda y coincidencia que se puede usar para crear listas negras. Por ejemplo, la regla podría coincidir con cualquier URL que contenga el término «localhost» y un número de puerto 300 en la solicitud. Los investigadores concluyeron que se debe aplicar una expresión regular existente a un valor llamado «Ocp-Apim-Url» en los encabezados de solicitud, que define la URL a la que llega el proxy CORS. Entonces usaron una URL a un dominio que controlaban, que luego redirigió el proxy a http://localhost:30001, por ejemplo.
Esto funcionó y nuevamente pasó por alto la lista negra, lo que permitió a los investigadores descubrir y acceder a servicios internos en diferentes números de puerto: 30001 – Vista del portal de desarrollador autenticado, 30004 – API de administración de Azure, 30005 – Administración de API de Kudu de Azure, 30006 – Página de desarrollador no publicada (sin autenticar) . kudú es el motor que admite algunas funciones de administración de Azure App Service, un servicio para hospedar e implementar aplicaciones web en Azure.
Las vulnerabilidades de SSRF revelan vulnerabilidades de listas negras como defensa
Esta vulnerabilidad SSRF a través del proxy CORS es similar al encontrado por investigadores de Orca Security en el mismo servicio en noviembre. Ermetic informó sus hallazgos a Microsoft en diciembre, pensando que podría tratarse de la misma vulnerabilidad. Sin embargo, su exploit pasó por alto las correcciones que Microsoft hizo después de que Orca informara el error original y lo convirtió en una vulnerabilidad separada. Esto subraya las dificultades de confiar en técnicas de listas negras como regex como mecanismo de defensa para este tipo de características, ya que siempre hay múltiples formas de sortearlas.
Los investigadores de Ermetic no terminaron su análisis allí y encontraron un segundo SSRF, esta vez en Azure API Management Hosting Proxy, otro proxy que se usa para configurar dinámicamente la URL del servicio de back-end para una API cuando se crea.
«Cuando se envía una solicitud desde la interfaz especificada por el usuario, la solicitud se envía al proxy de procesamiento entrante y luego al backend especificado», dijeron los investigadores. Al hacerlo, el proxy realiza cambios en la solicitud en función de las políticas definidas por el usuario para el procesamiento de entrada y salida.
Los investigadores descubrieron que un usuario podía configurar la política de servicio de backend establecida para apuntar a http://localhost en lugar de la URL de su servicio de backend de API real, engañando así al proxy para que use la API -Frontend para reenviar las solicitudes recibidas a sí mismo.
«Debido a que teníamos el control de las políticas de procesamiento entrante y frontend, podíamos enviar el SSRF con un verbo/método HTTP y encabezados personalizados de nuestra elección», dijeron. «Pudimos acceder a un puerto HTTP interno 80 para un POC [proof-of-concept].»
Para ambas vulnerabilidades, los investigadores detuvieron su investigación para evitar dañar los servicios internos y la infraestructura o arriesgar el acceso a datos confidenciales a través de la investigación SSRF, que normalmente requeriría autenticación.
Vulnerabilidad de cruce de rutas en el portal para desarrolladores de API Management
Finalmente, los investigadores también pudieron encontrar una función de carga de archivos sin restricciones en el Portal para desarrolladores de API Management que resultó en una saturación de la ruta. Esto tenía el potencial de afectar a todos los portales de desarrolladores de gestión de API autohospedados implementados por los usuarios finales, así como en su propia infraestructura.
«Descubrimos que Azure no valida el tipo de archivo y la ruta de los archivos cargados», dijeron los investigadores. «Los usuarios autenticados pueden atravesar la ruta especificada al cargar los archivos, cargar archivos maliciosos en el servidor del portal de desarrolladores y potencialmente ejecutar código en ellos mediante el secuestro de DLL, el intercambio de configuración de iisnode o cualquier otro vector de ataque relevante».
Derechos de autor © 2023 IDG Communications, Inc.
Hemos recibido este contenido de ciberseguridad de: CSO Online
Podrás encontrar la noticia original en el siguiente enlace: https://www.csoonline.com/article/3695849/azure-api-management-flaws-highlight-server-side-request-forgery-risks-in-api-development.html#tk.rss_news
