Investigadores de ciberseguridad han descubierto múltiples fallas críticas en las ofertas de Amazon Web Services (AWS) que, si se explotan con éxito, podrían tener graves consecuencias.
«El impacto de estas vulnerabilidades varía entre la ejecución remota de código (RCE), la toma de control de usuario de servicio completo (que podría proporcionar un poderoso acceso administrativo), la manipulación de módulos de IA, la exposición de datos confidenciales, la exfiltración de datos y la denegación de servicio», dijo la firma de seguridad en la nube Aqua en un informe detallado compartido con The Hacker News.
Tras la divulgación responsable en febrero de 2024, Amazon abordó las deficiencias durante varios meses, de marzo a junio. Los hallazgos fueron presentado en Black Hat USA 2024.
El problema central, denominado Bucket Monopoly, es un vector de ataque conocido como Shadow Resource, que, en este caso, se refiere a la creación automática de un bucket de AWS S3 cuando se utilizan servicios como CloudFormation, Glue, EMR, SageMaker, ServiceCatalog y CodeStar.
El nombre del depósito S3 creado de esta manera es único y sigue una convención de nombres predefinida («cf-templates-{Hash}-{Region}»). Un atacante podría aprovechar este comportamiento para configurar depósitos en regiones de AWS no utilizadas y esperar a que un cliente legítimo de AWS utilice uno de los servicios susceptibles para obtener acceso encubierto al contenido del depósito S3.
En función de los permisos otorgados al bucket S3 controlado por el adversario, el enfoque podría usarse para escalar y activar una condición de DoS, o ejecutar código, manipular o robar datos e incluso obtener control total sobre la cuenta de la víctima sin el conocimiento del usuario.
Para maximizar sus posibilidades de éxito, los atacantes pueden usar Bucket Monopoly para crear buckets no reclamados con anticipación en todas las regiones disponibles y almacenar código malicioso en ellos. Cuando la organización atacada habilita uno de los servicios vulnerables en una nueva región por primera vez, el código malicioso se ejecutará sin saberlo, lo que puede resultar en la creación de un usuario administrador que puede otorgar el control a los atacantes.
 |
| Descripción general de la vulnerabilidad de CloudFormation |
Sin embargo, es importante tener en cuenta que el atacante tendrá que esperar a que la víctima implemente una nueva pila de CloudFormation en una nueva región por primera vez para lanzar el ataque con éxito. La modificación del archivo de plantilla de CloudFormation en el depósito S3 para crear un usuario administrador no autorizado también depende de si la cuenta de la víctima tiene permiso para administrar roles de IAM.
 |
| Descripción general de la vulnerabilidad de Glue |
 |
| Descripción general de la vulnerabilidad de CodeStar |
Aqua dijo que encontró otros cinco servicios de AWS que dependen de una metodología de denominación similar para los buckets S3 ({Prefijo de servicio}-{ID de cuenta de AWS}-{Región}), lo que los expone a ataques de Shadow Resource y, en última instancia, permite que un actor de amenazas escale privilegios y realice acciones maliciosas, que incluyen DoS, divulgación de información, manipulación de datos y ejecución de código arbitrario.
- AWS Glue: aws-glue-assets-{ID de cuenta}-{Región}
- AWS Elastic MapReduce (EMR): aws-emr-studio -{ID de cuenta}-{Región}
- AWS SageMaker: sagemaker-{Región}-{ID de cuenta}
- AWS CodeStar: aws-codestar-{Región}-{ID de cuenta}
- Catálogo de servicios de AWS: cf-templates-{Hash}-{Región}
La empresa también señaló que las identificaciones de las cuentas de AWS deben considerarse secretas, al contrario de lo que dice Amazon. Estados en su documentación, ya que podrían utilizarse para realizar ataques similares.
«Este vector de ataque no solo afecta a los servicios de AWS, sino también a muchos proyectos de código abierto que utilizan las organizaciones para implementar recursos en sus entornos de AWS», afirmó Aqua. «Muchos proyectos de código abierto crean contenedores S3 automáticamente como parte de su funcionalidad o instruyen a sus usuarios para que implementen contenedores S3».
«En lugar de utilizar identificadores predecibles o estáticos en el nombre del depósito, es recomendable generar un hash único o un identificador aleatorio para cada región y cuenta, incorporando este valor en el nombre del depósito de S3. Este enfoque ayuda a protegerse contra los atacantes que reclaman su depósito de forma prematura».