Escáner continuo de exposición para conexiones de API en Azure
Audita de forma continua las conexiones de API de Azure Logic Apps en busca de tokens con privilegios excesivos y rutas de ataque entre tenants conocidas, antes de que alguien más las encuentre.
Un brief listo para pegar en Claude Code, Cursor o cualquier agente de programación (en inglés).
A favor
- Quién paga
- Responsables de seguridad cloud y gestores de AppSec en empresas con mucha carga de Azure (más de 500 empleados) que usan Logic Apps y Power Platform; 1.000–3.000 $/mes del presupuesto de postura de seguridad cloud.
- Lo que dijo la gente · 4
- El artículo muestra cinco rutas distintas de compromiso entre tenants a través de API Connections que dan acceso a Key Vaults, bases de datos SQL, Jira y Salesforce de las víctimas, y el autor supone que los tokens de conexión casi nunca tienen un alcance mínimo. Del artículo ↗
- Microsoft corrigió mal el error notificado y, después, una corrección posterior volvió a romper la anterior, dejando el sistema vulnerable de nuevo. Leer el comentario ↗
- Azure parece liderar a sus competidores en fugas entre tenants, y aun así las empresas siguen adoptándolo. Leer el comentario ↗
- Los fallos son path traversal e IDOR básicos que probablemente existen desde el lanzamiento de la funcionalidad. Leer el comentario ↗
Parafraseado del debate. Sigue los enlaces para ver los comentarios originales.
- Competidores y hueco
Las herramientas CSPM marcan configuraciones erróneas genéricas, pero ninguna modela en profundidad la superficie de ataque de Logic Apps y API Connections: endpoints proxy tipo DynamicInvoke, sobrescrituras de host.api.RuntimeUrl, acceso implícito en conexiones V1 frente a V2 y alcance de privilegios de token por conector. Defender for Cloud es el proveedor que sigue publicando correcciones defectuosas justo en esta superficie.
- Por qué ahora
- Se publicaron cinco exploits funcionales entre tenants sobre un mismo subsistema de conectores en una sola serie, las correcciones han regresado repetidamente, y los comentaristas esperan que el descubrimiento impulsado por LLM multiplique esta clase de hallazgos; los defensores necesitan pruebas continuas, no pentests puntuales.
- Foso · 6/10
- Una biblioteca de reglas y grafos de ataque actualizada continuamente para cientos de tipos de conectores de Azure y endpoints no documentados, construida a partir de investigación original; los arneses de reproducción y la telemetría de tenants se acumulan con el tiempo y son difíciles de replicar rápidamente para los CSPM genéricos.
En contra
- Equipo rojo
- Está demostrado que los CSPM pasan por alto esta superficie de ataque concreta de Logic Apps y API Connections, la investigación prueba que es explotable en la práctica, y las empresas con mucha carga de Azure ya pagan presupuestos de nivel Wiz por herramientas de postura.
- Qué la haría fracasar
- Microsoft rediseña en algún momento las API Connections de forma correcta (obligando a identidades administradas y V2 en todas partes) y la superficie de ataque específica desaparece más rápido de lo que se convierte la base de clientes.
Empezar
- Primeros tres pasos
- Construir un auditor de Azure de solo lectura que enumere las API Connections de un tenant y marque conexiones V1, tokens OAuth no gestionados con alcances amplios hacia el backend y endpoints dinámicos accesibles.
- Reproducir comprobaciones seguras y no destructivas de las clases de ataque publicadas (path traversal mediante DynamicInvoke, sobrescritura de RuntimeUrl) sobre las conexiones propias del cliente.
- Lanzar un panel con alertas que vuelva a ejecutar las comprobaciones tras cambios de configuración y después de que Microsoft despliegue correcciones, con guía de remediación para acotar el token de cada conector.
- Debate original
- Azure's Weakest Link – Five Full Cross-Tenant Compromises ↗ 329 puntos60 comentariosDe la historiaArtículo enlazado
Traducido del inglés. Leer el original