Un error de configuración crítico en Amazon Web Services (AWS) Compilación de código podría haber permitido la adquisición total de los repositorios de GitHub del proveedor de servicios en la nube, incluido su SDK de JavaScript de AWS, poniendo en riesgo todos los entornos de AWS.
La vulnerabilidad tiene un nombre en código Violación de código de la empresa de seguridad en la nube Wiz. AWS solucionó el problema en septiembre de 2025 tras una divulgación responsable el 25 de agosto de 2025.
«Al aprovechar CodeBreach, los atacantes podrían haber inyectado código malicioso para poner en peligro toda la plataforma, lo que podría afectar no solo a las innumerables aplicaciones que dependen del SDK, sino también a la propia consola, lo que pondría en peligro todas las cuentas de AWS», afirman los investigadores Yuval Avrahami y Nir Ohfeld dijo en un informe compartido con The Hacker News.
La falla, señaló Wiz, es el resultado de una debilidad en los procesos de integración continua (CI) que podría haber permitido a atacantes no autenticados violar el entorno de construcción, filtrar credenciales privilegiadas, como los tokens de administración de GitHub, y luego usarlas para introducir cambios maliciosos en el repositorio comprometido, creando una vía para los ataques a la cadena de suministro.
Dicho de otra manera, el problema socava filtros de webhook introducido por AWS para garantizar que solo ciertos eventos activen una compilación de CI. Por ejemplo, AWS CodeBuild se puede configurar de manera que una compilación solo se active cuando los cambios de código se confirmen en una rama específica o cuando el ID de una cuenta de GitHub o GitHub Enterprise Server (también conocido como ACTOR_ID o actor ID) coincida con el patrón de expresión regular. Estos filtros sirven para protegerse contra las solicitudes de cambios que no sean de confianza.
El error de configuración afectó a los siguientes repositorios GitHub de código abierto administrados por AWS, que están configurados para ejecutar compilaciones a partir de solicitudes de cambios:
- aws-sdk-js-v3
- aws-lc
- proveedor de criptomonedas amazon-corretto
- awslabs/registro de datos abiertos
Los cuatro proyectos, que implementaron un filtro ACTOR_ID, tenían un «defecto fatal», ya que no podían incluir dos caracteres para garantizar (a saber, los anclajes start ^ y end $) necesarios para obtener una coincidencia exacta de expresiones regulares (expresiones regulares). En cambio, el patrón de expresiones regulares permitía que cualquier ID de usuario de GitHub que fuera una supercadena de un ID aprobado (por ejemplo, 755743) eludiera el filtro y activara la compilación.
Como GitHub asigna los ID de usuario numéricos de forma secuencial, Wiz dijo que podía predecir que los nuevos ID de usuario (actualmente de 9 dígitos) «eclipsarían» el ID de seis dígitos de un mantenedor de confianza aproximadamente cada cinco días. Esta información, junto con el uso de Aplicaciones GitHub para automatizar la creación de aplicaciones (que, a su vez, crea un usuario de bot correspondiente), hizo posible generar un ID de destino (por ejemplo, 226755743) al activar cientos de registros de nuevos usuarios de bots.
Con el ID de actor, un atacante ahora puede activar una compilación y obtener las credenciales de GitHub del proyecto CodeBuild aws-sdk-js-v3, un token de acceso personal (PAT) que pertenece al usuario aws-sdk-js-automation, que tiene todos los privilegios de administrador sobre el repositorio.
El atacante puede utilizar este acceso elevado como arma para enviar código directamente a la sucursal principal, aprobar solicitudes de extracción y filtrar los secretos del repositorio, lo que eventualmente sentaría las bases para los ataques a la cadena de suministro.
«Las expresiones regulares configuradas en los repositorios anteriores para los filtros de webhooks de AWS CodeBuild destinados a limitar los ID de actores confiables eran insuficientes, lo que permitía que un ID de actor adquirido de manera predecible obtuviera permisos administrativos para los repositorios afectados», AWS dijo en un aviso publicado hoy.
«Podemos confirmar que se trataba de errores de configuración específicos del proyecto en los filtros de ID de actores de webhook de estos repositorios y no de un problema del propio servicio de CodeBuild».
Amazon también dijo que solucionó los problemas identificados, además de implementar mitigaciones adicionales, como rotaciones de credenciales y medidas para proteger los procesos de compilación que contienen tokens de GitHub o cualquier otra credencial en la memoria. Además, hizo hincapié en que no había encontrado pruebas de que CodeBreach hubiera sido explotado de forma espontánea.
Para mitigar estos riesgos, es esencial que las contribuciones no confiables no generen canalizaciones privilegiadas de CI/CD al permitir la nueva Aprobación de comentarios de Pull Request construir puerta, usar Ejecutores alojados en Codebuild para administrar los activadores de compilación a través de los flujos de trabajo de GitHub, garantizar que los patrones de expresiones regulares en los filtros de webhooks estén anclados, generar una PAT única para cada proyecto de CodeBuild, limitar los permisos de la PAT al mínimo requerido y considerar la posibilidad de usar una cuenta de GitHub dedicada y sin privilegios para la integración de CodeBuild.
«Esta vulnerabilidad es un ejemplo clásico de por qué los adversarios atacan los entornos de CI/CD: una falla sutil que se pasa por alto y que puede aprovecharse para lograr un impacto masivo», señalaron los investigadores de Wiz. «Esta combinación de complejidad, datos poco fiables y credenciales privilegiadas crea la solución perfecta para las infracciones de alto impacto que no requieren acceso previo».
No es la primera vez que la seguridad de los oleoductos de CI/CD es objeto de escrutinio. El año pasado, una investigación de Sysdig detallada qué tan inseguros son los flujos de trabajo de GitHub Actions asociados con la activador pull_request_target podría aprovecharse para filtrar el GITHUB_TOKEN privilegiado y obtener acceso no autorizado a docenas de proyectos de código abierto mediante una sola solicitud de extracción desde una bifurcación.
Un similar de dos partes análisis de Orca Security descubrió que pull_request_target era inseguro en proyectos de Google, Microsoft, NVIDIA y otras empresas de la lista Fortune 500, lo que podría haber permitido a los atacantes ejecutar código arbitrario, filtrar secretos confidenciales e introducir código malicioso o dependencias en sucursales de confianza. El fenómeno se ha denominado pull_request_nightmare.
«Al abusar de los flujos de trabajo mal configurados que se activan mediante pull_request_target, los adversarios podrían pasar de ser una solicitud de extracción bifurcada que no es de confianza a la ejecución remota de código (RCE) en ejecutores alojados en GitHub o incluso autohospedados», señaló el investigador de seguridad Roi Nisimi.
«Los flujos de trabajo de GitHub Actions que usan pull_request_target nunca deben revisar código que no sea de confianza sin una validación adecuada. Una vez que lo hagan, corren el riesgo de quedar totalmente comprometidos».
Post generado automáticamente, fuente oficial de la información: THEHACKERNEWS