**Microsoft niega la existencia de una vulnerabilidad en Azure Backup para AKS tras implementar una corrección sin CVE**

—

### 1. Introducción

En las últimas semanas ha surgido una controversia en la comunidad de ciberseguridad tras las declaraciones de un investigador independiente, quien afirma haber descubierto una vulnerabilidad de seguridad en el servicio Azure Backup para Azure Kubernetes Service (AKS). Según el investigador, Microsoft habría corregido el fallo de manera silenciosa, sin reconocer oficialmente la vulnerabilidad, emitir un CVE ni notificar a los clientes. Microsoft, por su parte, sostiene que el comportamiento observado era el esperado y que no se realizaron cambios en el producto, generando un intenso debate sobre la transparencia y la gestión responsable de vulnerabilidades en servicios cloud críticos.

—

### 2. Contexto del Incidente

El incidente gira en torno a Azure Backup para AKS, un servicio clave para la protección y recuperación de datos en entornos Kubernetes gestionados por Azure. El investigador reportó a Microsoft una supuesta vulnerabilidad que podía permitir a usuarios no autorizados obtener acceso indebido a backups sensibles de clústeres AKS, comprometiendo así la confidencialidad e integridad de datos empresariales críticos.

Tras la presentación del informe, Microsoft respondió que el funcionamiento reportado era conforme al diseño del servicio y rechazó la clasificación del hallazgo como vulnerabilidad. Sin embargo, poco después, el investigador detectó modificaciones en el comportamiento del servicio que, a su juicio, mitigaban el riesgo identificado, aunque sin anuncio público ni asignación de CVE.

—

### 3. Detalles Técnicos

#### a. Descripción de la vulnerabilidad alegada

El investigador detalló que, bajo ciertas condiciones de configuración, un usuario con permisos limitados en Azure podía acceder a snapshots de backup de clústeres AKS fuera de su ámbito autorizado. El ataque dependía de abusar de la gestión de roles en Azure (Azure RBAC) y de la arquitectura de almacenamiento en Azure Blob, donde los snapshots de backup se almacenan por defecto.

#### b. Vectores de ataque y TTPs

El vector de ataque principal implicaba la enumeración de recursos de almacenamiento y la manipulación de políticas de acceso, explotando posibles excesos de privilegios (over-privileged roles) y configuraciones por defecto poco restrictivas. Las técnicas asociadas corresponden a los siguientes TTPs del framework MITRE ATT&CK:

– **TA0006: Credential Access**
– **T1078: Valid Accounts**
– **T1087: Account Discovery**
– **T1552: Unsecured Credentials**

#### c. Indicadores de Compromiso (IoC)

No se han publicado IoC específicos, pero la actividad sospechosa incluiría accesos anómalos a blobs de backup, cambios inesperados en las políticas RBAC y logs de auditoría indicando acceso a snapshots por identidades no autorizadas.

#### d. Versiones afectadas

El investigador no pudo precisar versiones exactas debido a la naturaleza SaaS del servicio, aunque señala que el comportamiento fue observado en implementaciones de Azure Backup para AKS en el primer trimestre de 2024.

#### e. Herramientas y exploits

No se han divulgado exploits públicos, pero el ataque podría reproducirse mediante scripts de Azure CLI y herramientas de pentesting para cloud, como Pacu o ScoutSuite.

—

### 4. Impacto y Riesgos

El riesgo principal reside en la posible exfiltración de datos sensibles almacenados en backups de AKS. Este escenario puede desembocar en compromisos de datos personales protegidos bajo el RGPD, exposición de secretos de aplicaciones o credenciales, y potenciales ataques de escalada lateral en entornos de producción. Organizaciones sujetas a la directiva NIS2 podrían incurrir en sanciones si no garantizan la resiliencia y seguridad de sus servicios gestionados en la nube.

Aunque la magnitud real de la afectación no se ha cuantificado, la naturaleza compartida y multi-inquilino de los servicios cloud aumenta el alcance potencial a miles de clústeres AKS y terabytes de datos empresariales.

—

### 5. Medidas de Mitigación y Recomendaciones

– **Revisión de roles y permisos**: Auditar y restringir los roles RBAC de Azure, minimizando el acceso a recursos de backup únicamente a cuentas estrictamente necesarias.
– **Monitorización de logs**: Implementar monitorización continua y alertas en logs de acceso a blobs y snapshots de backup.
– **Segregación de recursos**: Utilizar cuentas de almacenamiento dedicadas y redes privadas para los backups críticos.
– **Pruebas de seguridad periódicas**: Realizar pentests en entornos AKS y servicios asociados, empleando frameworks como Kubernetes CIS Benchmark y herramientas de análisis de configuración cloud.
– **Gestión de incidentes**: Actualizar los planes de respuesta ante incidentes incluyendo escenarios de fuga de backups en la nube.

—

### 6. Opinión de Expertos

Especialistas en seguridad cloud subrayan la necesidad de transparencia en la gestión de vulnerabilidades en proveedores hiperescalares. “Corregir un fallo sin notificar formalmente ni emitir un CVE va en contra de las mejores prácticas de disclosure responsable y deja a los equipos de seguridad sin información crítica para evaluar su exposición”, señala un CISO de una multinacional financiera. Otros expertos advierten que la opacidad puede minar la confianza de los clientes y dificultar el cumplimiento normativo en mercados regulados.

—

### 7. Implicaciones para Empresas y Usuarios

La gestión de este incidente evidencia los retos a los que se enfrentan las organizaciones que dependen de la nube pública para operaciones críticas. La ausencia de comunicación proactiva por parte de los proveedores puede dejar a empresas y equipos SOC en una situación de indefensión ante riesgos desconocidos, con consecuencias legales y reputacionales significativas. Además, la falta de CVE impide la automatización en la gestión de vulnerabilidades y la integración con sistemas SIEM y GRC.

—

### 8. Conclusiones

Este caso pone de manifiesto la importancia de la transparencia y la comunicación clara en la gestión de vulnerabilidades cloud. Aunque Microsoft sostiene que no existió vulnerabilidad, la percepción de una “corrección silenciosa” y la ausencia de CVE resaltan la necesidad de procesos más rigurosos y abiertos, alineados con las expectativas de los profesionales de seguridad y las exigencias regulatorias actuales. Las organizaciones deben reforzar sus controles internos y exigir mayor visibilidad y compromiso a sus proveedores cloud para proteger sus activos críticos.

(Fuente: www.bleepingcomputer.com)