Confused Deputy en Azure Backup y AKS expone a las organizaciones sin CVE

Un investigador en seguridad afirma que Microsoft solucionó de forma silenciosa una vulnerabilidad crítica en Azure Backup para AKS después de rechazar su informe y bloquear la emisión de un CVE, dejando a las organizaciones sin una forma clara de medir su exposición. Según el investigador, la falla permitía escalar privilegios desde el rol de baja confianza "Backup Contributor" hasta permisos de cluster-admin en Kubernetes, explotando la forma en que Azure configura relaciones de Trusted Access para backups.

La técnica descrita encaja en lo que la comunidad conoce como un ataque de tipo Confused Deputy, donde la interacción entre Azure RBAC y Kubernetes RBAC rompe las barreras de autorización esperadas y permite que una identidad con permisos limitados active la elevación. El propio informe técnico del investigador explica cómo activar el soporte de backup en un clúster objetivo forzaba a Azure a crear enlaces de confianza con privilegios de administrador en Kubernetes, operaciones que podían usarse para extraer secretos o restaurar cargas maliciosas en el clúster; ver la explicación original aquí: olearysec.com.

La cronología que facilita el caso muestra tensiones habituales en procesos de divulgación responsable: el descubrimiento y envío inicial se produjo en marzo, Microsoft Security Response Center (MSRC) rechazó la calificación como vulnerabilidad alegando que el ataque requería acceso administrativo previo, y la discusión escaló a CERT/CC, que validó la falla y le asignó un identificador (VU#284781). Posteriormente Microsoft pidió a MITRE que no se le asigne un CVE, y la aplicación de las reglas de jerarquía de CNAs dejó en manos de Microsoft la facultad final para emitir o no el CVE; las reglas CNA están disponibles en: cve.org. El episodio fue reportado públicamente por medios especializados que cubren la disputa y la aparente corrección: BleepingComputer.

Lo más inquietante para defensores es que, tras la divulgación, el investigador observó cambios operativos que impidieron reproducir el exploit original: ahora se requieren pasos manuales para configurar Trusted Access y aparecen comprobaciones de permisos adicionales en las identidades gestionadas por el vault y por el cluster, algo que sugiere una corrección aplicada del lado del proveedor sin un aviso formal. Microsoft afirma que no se hicieron "cambios de producto" porque el comportamiento anterior, según su evaluación, era esperado; el investigador y CERT/CC discrepan de esa interpretación.

Este caso tiene varias implicaciones prácticas y de gobierno de seguridad. Sin un CVE ni un advisory público, los equipos de seguridad no pueden cuantificar el número de recursos expuestos, la ventana temporal del riesgo ni priorizar remediaciones en función de un inventario afectado. Además, las correcciones silenciosas dificultan la validación independiente de mitigaciones y reducen la trazabilidad legal y operativa en entornos regulados. La disputa también revela fricciones en la triage de reportes, incluida la mención, controvertida, de contenidos "generados por IA" como factor que distrae del análisis técnico.

Para equipos de seguridad que gestionen AKS y Azure Backup, recomiendo actuar inmediatamente: audite y liste todas las asignaciones del rol Backup Contributor en todos los vaults y suscripciones, confirme si alguna identidad gestionada (MSI) tiene permisos inesperados sobre clústeres o grupos de recursos de snapshots, y verifique la configuración de Trusted Access en los clústeres AKS. Active y revise logs de control de accesos, alertas de cambios en bindings de RBAC y operaciones de habilitación de backups, y considere rotar secretos/credenciales que podrían haberse visto comprometidas. Implemente políticas de menor privilegio y restricciones administrativas sobre quién puede habilitar backups y gestionar identidades del vault, y use Azure Policy y Azure Monitor para automatizar detección y bloqueo de cambios no autorizados.

Además, documente y registre cualquier interacción con el proveedor: solicite confirmación escrita de los cambios aplicados, plazos y scope de mitigación, y exija un advisory técnico o un CVE que permita rastrear la exposición en herramientas de gestión de vulnerabilidades. Si gestiona ambientes con requisitos de cumplimiento, incluya esta revisión en la siguiente auditoría de control de acceso y en los procesos de gestión de riesgos.

El episodio subraya una necesidad más amplia: los programas de divulgación y las jerarquías de CNAs deben equilibrar la protección del ecosistema y la transparencia hacia los clientes. Mientras no exista un mecanismo que alinee incentivos para notificar las correcciones y emitir CVEs de forma imparcial cuando corresponda, organizaciones y defensores seguirán enfrentando una ventana de visibilidad insuficiente que complica la mitigación efectiva de riesgos en la nube.