Veneno en el corazón de Amazon: hallan una vulnerabilidad que permitía inyectar código y, sin ser detectada, infectar al 66% de los entornos en la nube a nivel mundia

Veneno en el corazón de Amazon: hallan una vulnerabilidad que permitía inyectar código y, sin ser detectada, infectar al 66% de los entornos en la nube a nivel mundia

¿Cómo hacerse con el control total de repositorios de AWS simplemente escogiendo un identificador atractivo en GitHub?

image

Investigadores de la empresa Wiz descubrieron una vulnerabilidad crítica en la infraestructura de AWS, que en un escenario adverso podría haber llevado a la compromisión de todo el ecosistema de Amazon Web Services, incluida la consola de administración y las cuentas de clientes en todo el mundo.

Se trata de un fallo en el sistema AWS CodeBuild, servicio que construye y verifica automáticamente el código para numerosos proyectos de Amazon. Según los especialistas, debido a un error en la configuración un atacante podría obtener acceso administrativo a repositorios clave de AWS en GitHub, incluidos aquellos de los que depende directamente el funcionamiento de la consola de AWS.

Según la estimación de Wiz, la vulnerabilidad fue tan grave que permitía a atacantes no autorizados inyectar código malicioso en las bibliotecas oficiales de AWS. Esto abría el camino directo a un ataque a gran escala a través de la cadena de suministro, con un impacto potencial en millones de entornos en la nube.

Los investigadores bautizaron el hallazgo como CodeBreach. La explotación del fallo permitía la filtración de credenciales privilegiadas y, al obtenerlas, el atacante pasaba a ser, de hecho, administrador del repositorio. En ese estado se podían aplicar cambios directamente en la rama principal del código, aprobar cualquier pull request y acceder a los secretos almacenados en el repositorio.

Especialmente peligroso fue el hecho de que el repositorio aws-sdk-js-v3, el SDK de JavaScript de Amazon, estuviera en riesgo. Esta biblioteca sustenta la consola de AWS y es ampliamente utilizada por desarrolladores externos. Según Wiz, el SDK de JavaScript se emplea en aproximadamente el 66% de los entornos en la nube, y su compromiso podría haber provocado una reacción en cadena de infecciones.

La raíz del problema resultó sorprendentemente sencilla. Wiz estudió el mecanismo mediante el cual AWS determina qué usuarios de GitHub se consideran mantenedores confiables de proyectos. En CodeBuild se empleaba un filtro que verificaba los identificadores de usuario de GitHub mediante una expresión regular.

El error consistía en que el sistema no exigía una coincidencia exacta del ID. Si un mantenedor confiable tenía, por ejemplo, el identificador "12345", un usuario con ID "0123456" también pasaba la comprobación porque la cadena contenía la secuencia de caracteres buscada.

GitHub asigna identificadores numéricos de forma secuencial, y las cuentas antiguas tienen IDs más cortos. Los investigadores se aprovecharon de esto y crearon cientos de cuentas de prueba hasta que una de ellas obtuvo un ID que satisfacía el filtro defectuoso. A partir de entonces, los investigadores externos se convirtieron de facto en colaboradores confiables del proyecto.

Bajo este pretexto enviaron un pull request agregando una dependencia de un paquete NPM externo que estaba configurado para robar credenciales de GitHub. Poco después lograron obtener un token de acceso con permisos administrativos totales sobre el repositorio aws-sdk-js-v3. El token obtenido pertenecía a una cuenta automatizada con privilegios de administrador. Esto significaba control total del repositorio y la posibilidad de inyectar código malicioso sin ser detectado.

El SDK de JavaScript se actualiza semanalmente y se publica automáticamente primero en GitHub y luego en NPM. Un atacante podría haber introducido código malicioso justo antes del lanzamiento, tras lo cual la versión comprometida se habría propagado a miles de proyectos. Esquemas de ataque similares se han usado antes. Hace apenas un mes, atacantes comprometieron usuarios de la extensión Amazon Q para VS Code, lo que demostró cuán realista es este escenario.

La empresa ahora afirma que la vulnerabilidad fue corregida y que todos los riesgos relacionados han sido mitigados.

AWS subrayó que los investigadores de Wiz se limitaron a demostrar el problema sin causar daño y que comunicaron el hallazgo de forma rápida al equipo de seguridad. En respuesta, la compañía rotó credenciales, reforzó la protección de los procesos de compilación y verificó todos sus repositorios públicos en GitHub.

Según AWS, no se encontraron indicios de que la vulnerabilidad hubiera sido explotada por atacantes reales.

Como señalan en Wiz, sistemas de este tipo crean condiciones ideales para ataques con una barrera de entrada mínima y consecuencias máximas. Y aunque en este caso no hubo filtraciones ni compromisos de clientes, la situación es una señal de alarma para toda la industria.