Vulnerabilidad de AWS: Los usuarios corren el riesgo de ataques de toma de control de cuentas

Según informes recientesinvestigadores de ciberseguridad han descubierto recientemente una vulnerabilidad de AWS en el Kit de Desarrollo de la Nube (CDK). Esta vulnerabilidad, si se explota, podría dar lugar a ataques de toma de control de cuentas en determinados escenarios. En este artículo, nos sumergiremos en los detalles de un posible exploit, el descubrimiento inicial y más. Comencemos.

Vulnerabilidad de AWS: Descubrimiento inicial y detalles

El CDK de Amazon Web Services (AWS) es un marco de desarrollo de software de código abierto que se utiliza para definir recursos de aplicaciones mediante lenguajes de programación a través de CloudFormation. Los lenguajes de programación que se utilizan incluyen:  

• Python.
• TypeScript.
• JavaScript.

Antes de entrar en más detalles, vale la pena señalar que el problema fue identificado por Aqua, una empresa de seguridad en la nube, sobre la base de sus hallazgos anteriores. Dichos hallazgos detallaban los recursos en la sombra en AWS. Además, también arrojaron luz sobre cómo las convenciones de nomenclatura predefinidas para los cubos de AWS Simple Storage Service (S3) pueden convertirse en armas. 

La prevalencia de un escenario de este tipo permitiría a los actores de amenazas orquestar ataques del tipo Bucket Monopoly y, de tener éxito, dichos ataques ayudarían a obtener acceso a información sensible. En cuanto a la vulnerabilidad de AWS en el CDK, es importante saber que tales entornos pueden crearse mediante bootstrapping.

Durante el proceso de arranque, se aprovisionan varios recursos de AWS al entorno. Estos recursos incluyen:  

• Un bucket AWS S3.
• Repositorio de Amazon Elastic Container Registry (Amazon ECR).
• Funciones de AWS Identity and Access Management (IAM).

Riesgo de seguridad en la asignación de nombres a cubos S3 

Para comprender plenamente la vulnerabilidad de AWSlas personas deben saber que algunos de los roles IAM creados como parte del proceso de bootstrapping conceden diferentes tipos de permisos. Estos permisos incluyen la carga y eliminación de activos asociados a los buckets S3. Además, también pueden incluir el despliegue de pila de permisos con acceso administrativo.

Los expertos en ciberseguridad han afirmado que el patrón de nomenclatura de los roles IAM que crea AWS CDK sigue la misma estructura:

"cdk-{Qualifier}-{Description}-{Account-ID}-{Region}"

Los detalles de cada campo dentro de esta estructura se mencionan a continuación:  

Además, el bucket de S3 que se crea durante el proceso de bootstrapping sigue el patrón de nomenclatura:

"cdk-{Cualificador}-activos-{Identificador de cuenta}-{Región}".

Más información sobre esta vulnerabilidad de AWSAqua declaró que:

"Dado que muchos usuarios ejecutan el comando cdk bootstrap sin personalizar el calificador, el patrón de nomenclatura del bucket de S3 del bucket de staging se vuelve predecible. Esto se debe a que el valor predeterminado para el calificador del nombre del bucket se establece en 'hnb659fds', lo que facilita la anticipación del nombre del bucket."

Cabe mencionar que varias instancias descubiertas en GitHub utilizaban el calificador predeterminado. Lo que esto significa para los actores de amenazas es que adivinar el nombre de un bucket es tan sencillo como determinar el ID de la cuenta de AWS y la región en la que está desplegado el CDK. 

Este vulnerabilidad de AWS permite a los actores de amenazas orquestar S3 Bucket Name Squatting. Esta técnica, también conocida como Bucket Sniping, asegura que los hackers están a punto de explotar con éxito la vulnerabilidad de AWS ya que les permite reclamar el bucket CDK de otro usuario.

Consecuencias de la vulnerabilidad de AWS Exploit

En cuanto a las consecuencias de un posible exploit, esta vulnerabilidad de AWS allana el camino para una denegación de servicio (DoS) parcial. Esto ocurre cuando un usuario intenta arrancar el CDK con el mismo ID de cuenta y región.

La intensidad de las consecuencias de la vulnerabilidad de AWS aumenta cuando el CDK comprometido tiene permiso para leer y escribir datos desde y hacia el bucket de S3 controlado por el atacante.

Tales privilegios permitirían a un actor de amenazas manipular las plantillas de CloudFormation. Esto implicaría que los hackers pueden llevar a cabo acciones maliciosas dentro de la cuenta comprometida. Al comentar sobre las plantillas CloudFormation, los expertos han declarado que:  

"El rol deploy del servicio CloudFormation, que es el rol CloudFormationExecutionRole en CDK, tiene privilegios administrativos dentro de la cuenta por defecto. Esto significa que cualquier plantilla de CloudFormation escrita en el bucket S3 del atacante por el CDK de la víctima se desplegaría posteriormente con privilegios administrativos en la cuenta de la víctima. Esto permitiría al atacante crear recursos privilegiados".

Cadena de ataques contra la vulnerabilidad de toma de control de cuentas de AWS 

En cuanto a la cadena de ataque de esta vulnerabilidad de AWS el actor de la amenaza necesitaría crear un bucket con un nombre que coincida con el ya existente. Para ello, tendría que iniciar el proceso de arranque del CDK y posteriormente eliminar el bucket de S3. Este sería el activo utilizado para iniciar la vulnerabilidad de AWS exploit.

La creación de un bucket duplicado haría que el CDK confiara en él, asegurando que los actores de amenazas pudieran tener plantillas de CloudFormation escritas en él. Pero, hay ciertos requisitos previos que un hacker debe cumplir para que esto tenga éxito. Estos incluyen:  

• • Reclamar el cubo con el nombre predecible y permitir el acceso público

• Creación de una función Lambda para inyectar un rol de administrador malicioso o una puerta trasera en un archivo de plantilla de CloudFormation determinado.

Una vez cumplidas todas estas condiciones, la vulnerabilidad de AWS puede tomar el control completo de la cuenta objetivo. Sin embargo, para que esto ocurra, el usuario debe desplegar el CDK utilizando "cdk deploy". Al hacerlo, se enviaría la plantilla al bucket duplicado que creó el hacker durante la fase inicial del ataque.

Además, también inyectaría un rol admin utilizado para adquirir el control. Vale la pena señalar que el rol de administrador se inyectaría utilizando la función Lambda del atacante. Dicha función backdoorizaría el archivo de plantilla CloudFormation escrito pero el CKD de la víctima al bucket S3 comprometido. 

Una vez completada esta cadena de eventos, la cuenta de la víctima leerá y desplegará recursos del bucket del atacante, lo que permitirá al hacker crear un nuevo rol de administrador. Los expertos en ciberseguridad han explicado esta metodología de ataque: 

"Pudimos crear un rol de administrador en una cuenta de destino si alguien elimina el cubo S3 de staging de CDK que se creó durante el proceso de bootstrap y luego intenta usar CDK nuevamente. Sin embargo, debemos tener en cuenta la probabilidad de que alguien elimine el cubo S3 de CDK después de que haya sido bootstrapped."

Protocolos de seguridad Mitigación de riesgos 

Dadas las posibles secuelas de esta vulnerabilidad de AWS explotada, aprender sobre medidas de seguridad que se pueden adoptar para mitigar el riesgo es esencial. Estos protocolos de seguridad incluyen:

• Actualización a la versión CDK CDK versión v2.149.0 ya que viene con medidas de seguridad mejoradas que dictan que sólo los buckets S3 dentro de la cuenta del usuario son de confianza. Esto evita que el CDK envíe datos a un bucket que no pertenezca a la cuenta del usuario. 
• Utilizar un calificador personalizado en lugar del predeterminado "hnb659fds" personalizando los recursos de arranque como se menciona en la documentación actualizada de AWS.

Vale la pena mencionar que los usuarios que arrancaron con una versión anterior todavía pueden estar en riesgo de ser presa de la vulnerabilidad de AWS de AWS. Para mitigar el riesgo, estos usuarios deben actualizar a la versión v2.149.0 o posterior y volver a ejecutar el comando "cdk bootstrap . Como alternativa dichos usuarios también pueden aplicar una política IAM similar al parche de AWS.

Conclusión 

Este vulnerabilidad de AWS pone de relieve la importancia de mantener configuraciones seguras y versiones de software actualizadas. Siguiendo los protocolos recomendados, como la actualización a la versión CDK v2.149.0 y la personalización de la configuración predeterminada, los usuarios pueden reducir significativamente el riesgo de ataques de toma de control de cuentas y proteger los recursos sensibles de AWS. Esta vulnerabilidad y los posibles escenarios de ataque dictan ahora el uso de medidas proactivas de ciberseguridad que pueden ayudar a mitigar el riesgo y mejorar la postura de seguridad.

Las fuentes de este artículo incluyen artículos en The Hacker News y Aqua.