Los investigadores de ciberseguridad han descubierto varias fallas críticas en las ofertas de Amazon Web Services (AWS) que, si se explotan con éxito, podrían tener consecuencias graves.
“El impacto de estas vulnerabilidades va desde la ejecución remota de código (RCE), la toma completa del usuario (que puede proporcionar un potente acceso administrativo), la manipulación de módulos de IA, la exposición de datos sensibles, la exfiltración de datos y la denegación de servicio”, dijo la empresa de seguridad en la nube Aqua. en un informe detallado compartido con The Hacker News.
Después de una divulgación responsable en febrero de 2024, Amazon abordó las deficiencias durante varios meses, de marzo a junio. Las conclusiones fueron presentado en Black Hat EE. UU. 2024.
En el centro del problema, denominado Bucket Monopoly, se encuentra un vector de ataque llamado Shadow Resource, que en este caso se refiere a la creación automática de un depósito 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 nomenclatura predefinida (“cf-templates-{Hash}-{Región}”). 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 confidenciales para obtener acceso encubierto al contenido del depósito S3.
Dependiendo de los permisos otorgados al depósito S3 controlado por el adversario, el enfoque podría usarse para desencadenar una condición DoS o ejecutar código, manipular o robar datos e incluso obtener el control total de la cuenta de la víctima sin el conocimiento del usuario.
Para maximizar sus posibilidades de éxito, los atacantes pueden utilizar el principio Bucket Monopoly para crear depósitos no reclamados en todas las regiones disponibles con antelación y almacenar código malicioso en ellos. Cuando la organización objetivo activa por primera vez uno de los servicios vulnerables en una nueva región, el código malicioso se ejecuta sin su conocimiento, lo que puede resultar en la creación de un usuario administrador que puede otorgar 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 hasta 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 edición del archivo de plantilla de CloudFormation en el depósito de S3 para crear un usuario administrador no autorizado también depende de si la cuenta de la víctima tiene permiso para administrar funciones de IAM.
 |
| Descripción general de la vulnerabilidad del pegamento |
 |
| Descripción general de la vulnerabilidad de CodeStar |
Aqua dijo que encontró otros cinco servicios de AWS que se basan en una metodología de nomenclatura similar para los depósitos de S3: {Prefijo de servicio}-{ID de cuenta de AWS}-{Región}, exponiéndolos así a ataques de recursos fantasmas y, en última instancia, permitiendo que un actor de amenazas se eleve. privilegios y realizar 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 compañía también señaló que las credenciales de la cuenta de AWS deben considerarse secretas, a diferencia de Amazon. Estados en su documentación, ya que podrían usarse para realizar ataques similares.
“Este vector de ataque afecta no sólo a los servicios de AWS, sino también a muchos proyectos de código abierto que las organizaciones utilizan para implementar recursos en sus entornos de AWS”, dijo Aqua. “Muchos proyectos de código abierto crean automáticamente depósitos de S3 como parte de su funcionalidad o requieren que sus usuarios implementen depósitos de S3. »
“En lugar de utilizar identificadores predecibles o estáticos en el nombre del depósito, se recomienda 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 proteger contra los atacantes que reclaman su depósito prematuramente. »