Es una historia acquainted: una función diseñada para la comodidad se utiliza para eludir las medidas de seguridad. En esta presentación de Black Hat United states of america 2021, un par de investigadores muestran cómo encontraron tres formas distintas de pasar de una cuenta a otra en AWS. Aunque las correcciones para esas vulnerabilidades se publicaron rápidamente, los agujeros revelan que los servicios en la nube no ofrecen el nivel de aislamiento esperado. La solución a largo plazo puede significar cambiar la forma en que el sector de la ciberseguridad maneja los CVE.
Para las dos primeras infracciones de aislamiento, el CTO de Wiz.io, Ami Luttwak, y la jefa de investigación, Shir Tamari, modificaron los prefijos de ruta en AWS CloudTrail y Config para permitir que un usuario escriba en el depósito S3 de otro usuario. El tercer método utilizó la línea de comandos de AWS para descargar archivos de la cuenta de otro usuario a través del repositorio sin servidor.
El envío de registros de varios depósitos S3 a uno está destinado a la comodidad de un administrador que ejecuta varias instancias, dijeron Luttwak y Tamari en su presentación, «Rompiendo el aislamiento: vulnerabilidades de AWS entre cuentas».
«Aprendí de este comportamiento que CloudTrail puede escribir en recursos que son propiedad y están administrados en otras cuentas». Tamari agregó. «Y para mí, un investigador de seguridad, hay una preocupación».
Clientes notificados, entonces, ¿qué pasó?
Si bien Amazon no tenía el poder de arreglar las configuraciones para los clientes por sí mismo, porque las correcciones implicaban configurar la cuenta de origen que desea, que solo el usuario puede decidir, se comunicó con todos los clientes afectados para explicarles el problema potencial y cómo solucionarlo. Sin embargo, cuando Wiz.io volvió después de cinco meses, descubrió que el 90% de las cuentas no habían aplicado las correcciones.
Luttwak señaló que el equipo de seguridad que AWS envió mensajes a menudo no recibió las advertencias debido a la gran cantidad de cuentas que ejecutan.
«¿Cómo sabes que esta es una solución importante que hacer?» preguntó. «Y cuanto más lo pensábamos, más entendíamos, este es un gran, gran problema».
En este momento, el sistema de CVE permite a las organizaciones verificar las últimas vulnerabilidades, completo con un sistema numérico de clasificación de la gravedad y enlaces a las correcciones de los proveedores. Eso funciona bastante bien en la mayoría de las áreas de TI. Sin embargo, es posible que a las vulnerabilidades de la nube no se les asignen números CVE.
«Esto se debe a que los servicios en la nube, tal como los entendemos actualmente, no están controlados por el cliente». escribió El director de TI de Cloud Stability Alliance, Kurt Seifried, y el analista de investigación, Victor Chin. «Como resultado, a las vulnerabilidades en los servicios en la nube generalmente no se les asignan ID de CVE».
La excepción de Amazon
Las CVE se esfuerzan por señalar que las vulnerabilidades de los servicios en la nube pueden recibir una ID de CVE, siempre que el propietario del application sea la autoridad de numeración de CVE (CNA) que los informa. Regla 7.4.4 dice que la CNA «puede» asignar un número CVE si posee el producto o servicio, incluso si no está controlado por el cliente y la solución requiere que los clientes tomen medidas.
Pero aquí está el wicket pegajoso: Regla 7.4.5 establece que «los CNA NO DEBEN asignar una ID de CVE a una vulnerabilidad si los productos o servicios afectados no son propiedad del CNA y no están controlados por el cliente».
En resumen, la verdadera razón por la que estas vulnerabilidades de AWS no se emitieron CVE es que Amazon no es un socio de CNA. Microsoft puede emitir CVE para sus propios productos y servicios, al igual que Google. Si la solución adecuada es cambiar las reglas para permitir que cualquier CNA asigne ID a las vulnerabilidades cuyas soluciones están fuera del alcance de los clientes o registrar a Amazon como un CNA depende de su perspectiva. En junio de 2022, Wiz.io tomó el asunto en sus propias manos al establecer una base de datos comunitaria de vulnerabilidades en la nube para llenar el vacío.
Como dijo Luttwak, «Hay cientos de servicios en AWS, y muchos de ellos obtienen cada vez más capacidades de cuentas cruzadas, porque las cuentas cruzadas son la principal estrategia precise para las organizaciones que usan AWS. Por lo tanto, la superficie de ataque está creciendo».
