Una mala configuración crítica en CodeBuild de Amazon Web Services (AWS) podría haber permitido la adquisición total de los propios repositorios GitHub del proveedor de servicios en la nube, incluido su SDK de JavaScript de AWS, poniendo en riesgo cualquier entorno de AWS.
La vulnerabilidad ha sido nombrada en código. Violación de código de la empresa de seguridad en la nube Wiz. AWS resolvió el problema en septiembre de 2025 después de una divulgación responsable el 25 de agosto de 2025.
“Al explotar CodeBreach, los atacantes podrían haber inyectado código malicioso para desencadenar un compromiso en toda la plataforma, afectando potencialmente no sólo a las innumerables aplicaciones que dependen del SDK, sino también a la propia consola, amenazando cada cuenta de AWS”, dijeron los investigadores Yuval Avrahami y Nir Ohfeld en un informe compartido con The Hacker News.
La falla, dijo Wiz, es el resultado de una vulnerabilidad en los canales de integración continua (CI) que podría haber permitido a atacantes no autenticados ingresar al entorno de construcción, exponer credenciales privilegiadas como tokens de administrador de GitHub y luego usarlas para impulsar cambios maliciosos en el repositorio comprometido, creando una vía para ataques a la cadena de suministro.
En otras palabras, el problema socava los filtros de webhook introducidos por AWS para garantizar que solo ciertos eventos desencadenen una compilación de CI. Por ejemplo, AWS CodeBuild se puede configurar para activar una compilación solo cuando los cambios de código se confirman en una rama específica o cuando un ID de cuenta de GitHub o GitHub Enterprise Server (también conocido como ACTOR_ID o ID de actor) coincide con el patrón de expresión regular. Estos filtros sirven para proteger contra solicitudes de extracción no confiables.
La configuración incorrecta afectó a los siguientes repositorios de GitHub de código abierto administrados por AWS que están configurados para ejecutar compilaciones en solicitudes de extracción:
- aws-sdk-js-v3
- aws-lc
- Proveedor de cifrado Amazon Corretto
- awslabs/registro-de-datos-abiertos
Los cuatro proyectos que implementaron un filtro ACTOR_ID sufrieron un “error fatal” porque no incluían dos caracteres garantizados, es decir, los anclajes inicial ^ y final $, que eran necesarios para una coincidencia exacta de expresión regular (regex). 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) omitiera el filtro y activara la compilación.
Debido a que GitHub asigna ID de usuario numéricos uno a la vez, Wiz dijo que era capaz de predecir que los nuevos ID de usuario (actualmente de 9 dígitos) “eclipsarían” el ID de seis dígitos de un mantenedor confiable aproximadamente cada cinco días. Estos hallazgos, junto con el uso de GitHub Apps para automatizar la creación de aplicaciones (que a su vez crea un usuario de bot correspondiente), permitieron la generación de una identificación de destino (por ejemplo, 226755743) al activar cientos de nuevos registros de usuarios de bot.
Armado con el ID del actor, un atacante ahora puede desencadenar una compilación y obtener las credenciales de GitHub del proyecto CodeBuild aws-sdk-js-v3, un token de acceso personal (PAT) propiedad del usuario de aws-sdk-js-automation que tiene todos los derechos administrativos sobre el repositorio.
El atacante puede utilizar este acceso extendido como arma para enviar código directamente a la rama maestra, aprobar solicitudes de extracción y filtrar secretos del repositorio, lo que en última instancia prepara el escenario para ataques a la cadena de suministro.
“Las expresiones regulares configuradas de los repositorios anteriores para los filtros de webhook de AWS CodeBuild destinados a limitar las ID de actores confiables fueron insuficientes y permitieron que una ID de actor adquirida de manera predecible obtuviera permisos administrativos en los repositorios afectados”, dijo AWS en un aviso publicado hoy.
“Podemos confirmar que se trataba de configuraciones erróneas específicas del proyecto en los filtros de ID de actor de webhook para estos repositorios y no un problema en el servicio CodeBuild en sí”.
Amazon también dijo que abordó los problemas identificados e implementó mitigaciones adicionales, tales como: B. Rotaciones de credenciales y pasos para asegurar procesos de compilación que contienen tokens de GitHub u otras credenciales almacenadas. También enfatizó que no había encontrado evidencia de que CodeBreach hubiera sido explotado en la naturaleza.
Para mitigar dichos riesgos, es importante garantizar que las contribuciones que no son de confianza no activen canales de CI/CD privilegiados habilitando la nueva puerta de compilación Pull Request Comment Approval, usando ejecutores alojados en CodeBuild para administrar los activadores de compilación en los flujos de trabajo de GitHub, garantizando que los patrones de expresiones regulares estén anclados en filtros de webhook, generando una PAT única para cada proyecto de CodeBuild, manteniendo los permisos de PAT en el mínimo requerido y considerando el uso de una cuenta de GitHub dedicada sin privilegios para CodeBuild. integración.
“Esta vulnerabilidad es un excelente ejemplo de por qué los atacantes apuntan a entornos CI/CD: una falla sutil y fácil de pasar por alto que puede explotarse con un impacto masivo”, señalaron los investigadores de Wiz. “Esta combinación de complejidad, datos no confiables y credenciales privilegiadas crea una tormenta perfecta para violaciones de seguridad importantes que no requieren acceso previo”.
Esta no es la primera vez que la seguridad del oleoducto CI/CD es objeto de escrutinio. El año pasado, una investigación de Sysdig detalló cómo los flujos de trabajo inseguros de GitHub Actions vinculados al disparador pull_request_target podrían explotarse para exponer el GITHUB_TOKEN privilegiado y obtener acceso no autorizado a docenas de proyectos de código abierto utilizando una única solicitud de extracción desde una bifurcación.
Un análisis similar de dos partes realizado por Orca Security encontró pull_request_target inseguro en proyectos de Google, Microsoft, NVIDIA y otras compañías Fortune 500, lo que podría haber permitido a los atacantes ejecutar código arbitrario, filtrar secretos confidenciales y enviar código malicioso o dependencias a sucursales confiables. El fenómeno se llamó pull_request_nightmare.
“Al abusar de los flujos de trabajo mal configurados activados a través de pull_request_target, los atacantes podrían pasar de 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 verificar código que no sea de confianza sin la validación adecuada. Una vez que lo hacen, corren el riesgo de quedar totalmente comprometidos”.
About The Author
