Una mala configuración crítica en CodeBuild de Amazon Web Services (AWS) podría resultar en una adquisición completa del propio repositorio GitHub de un proveedor de servicios en la nube que contiene el SDK de JavaScript de AWS, lo que podría poner en riesgo todos los entornos de AWS.
La vulnerabilidad recibió el nombre en código «CodeBreach» de la empresa de seguridad en la nube Wiz. AWS solucionó este problema en septiembre de 2025 luego de una divulgación responsable el 25 de agosto de 2025.
«Al explotar CodeBreach, un atacante podría inyectar código malicioso y comenzar un compromiso en toda la plataforma, impactando potencialmente no sólo las innumerables aplicaciones que dependen del SDK, sino también la propia consola, amenazando todas las cuentas de AWS», dijeron los investigadores Yuval Avrahami y Nir Ohfeld en un informe compartido con The Hacker News.
Wiz señaló que esta falla es el resultado de una vulnerabilidad en el proceso de integración continua (CI). Esta vulnerabilidad podría permitir que un atacante no autenticado comprometa el entorno de compilación, divulgue credenciales privilegiadas, como un token de administrador de GitHub, y las utilice para enviar cambios maliciosos a un repositorio comprometido, creando potencialmente un vector de ataque a la cadena de suministro.
En otras palabras, este problema debilita el filtro de webhook introducido por AWS para garantizar que solo ciertos eventos desencadenen compilaciones de CI. Por ejemplo, puede configurar AWS CodeBuild para activar una compilación solo cuando los cambios de código se confirman en una rama específica, o cuando su ID de cuenta de GitHub o GitHub Enterprise Server (también conocido como ACTOR_ID o ID de actor) coincide con un patrón de expresión regular. Estos filtros funcionan para proteger contra solicitudes de extracción que no son de confianza.
Esta mala configuración afectó a los siguientes repositorios de GitHub de código abierto administrados por AWS que están configurados para ejecutar compilaciones con solicitudes de extracción.
aws-sdk-js-v3 aws-lc amazon-corretto-crypto-provider awslabs/open-data-registry
Los cuatro proyectos que implementaron el filtro ACTOR_ID sufrieron un «defecto fatal» en el que no pudieron incluir de manera confiable los dos caracteres necesarios para generar una coincidencia exacta de expresión regular (regex): el ancla inicial ^ y el ancla $ final. En cambio, el patrón de expresión regular ahora permite que los ID de usuario de GitHub que son supercadenas de ID autorizados (por ejemplo, 755743) omitan el filtro y activen una compilación.
Debido a que GitHub asigna ID de usuario numéricos de forma secuencial, Wiz dijo que una nueva ID de usuario (actualmente de nueve dígitos) «blanqueará» la ID de seis dígitos de un mantenedor confiable aproximadamente cada cinco días. Combinando esta información con el uso de GitHub Apps para automatizar la creación de aplicaciones (que crea los usuarios de bot correspondientes), pudimos activar cientos de nuevos registros de usuarios de bot y generar ID de destino (por ejemplo, 226755743).
Un atacante con un ID de actor puede desencadenar una compilación y obtener credenciales de GitHub para un proyecto CodeBuild de aws-sdk-js-v3, un token de acceso personal (PAT) que pertenece al usuario de aws-sdk-js-automation con derechos administrativos completos sobre el repositorio.
Armados con este acceso elevado, los atacantes pueden enviar código directamente a la rama principal, aprobar solicitudes de extracción, comprometer los secretos del repositorio y, en última instancia, configurar ataques a la cadena de suministro.
«La expresión regular configurada en el repositorio anterior para el filtro de webhook de AWS CodeBuild destinado a limitar los ID de actores confiables fue insuficiente, lo que permitió que los ID de actores recuperados como se esperaba obtuvieran privilegios administrativos en los repositorios afectados», dijo AWS en un aviso publicado hoy.
«Hemos confirmado que se trata de configuraciones erróneas específicas del proyecto en los filtros de ID de actor de webhook para estos repositorios y no un problema con el servicio CodeBuild en sí».
Amazon también dijo que implementó medidas de mitigación adicionales, incluida la rotación de credenciales y pasos para proteger los procesos de compilación que incluyen tokens de GitHub y otras credenciales en la memoria, además de solucionar los problemas identificados. La compañía también enfatizó que no había encontrado evidencia de que CodeBreach estuviera siendo explotado en la naturaleza.
Para mitigar dichos riesgos, habilite la nueva puerta de compilación de aprobación de comentarios de solicitudes de extracción para evitar que las publicaciones que no son de confianza activen canales de CI/CD privilegiados, use ejecutores alojados en CodeBuild para administrar los activadores de compilación a través de los flujos de trabajo de GitHub, asegúrese de que los patrones de expresión regular en los filtros de webhook estén anclados, genere una PAT única para cada proyecto de CodeBuild y PAT. Es importante limitar los permisos de GitHub al mínimo necesario y considerar el uso de un GitHub dedicado y sin privilegios. cuenta. Para la integración de CodeBuild.
«Esta vulnerabilidad es un ejemplo de libro de texto de por qué los atacantes apuntan a entornos CI/CD. Es una falla sutil y fácil de pasar por alto, pero cuando se explota, puede tener un gran impacto», señalaron los investigadores de Wiz. «Esta combinación de complejidad, datos no confiables y credenciales privilegiadas crea una tormenta perfecta para violaciones de alto impacto que no requieren acceso previo».
Esta no es la primera vez que la seguridad de los canales de CI/CD está en el centro de atención. El año pasado, una investigación realizada por Sysdig detalló cómo un flujo de trabajo inseguro de GitHub Actions asociado con el disparador pull_request_target podría explotarse para filtrar GITHUB_TOKEN privilegiados y obtener acceso no autorizado a docenas de proyectos de código abierto utilizando una sola solicitud de extracción desde una bifurcación.
Un análisis similar de dos partes realizado por Orca Security encontró que los proyectos de Google, Microsoft, NVIDIA y otras compañías Fortune 500 tenían pull_request_targets inseguros que podrían permitir a los atacantes ejecutar código arbitrario, filtrar información confidencial o enviar código malicioso o dependencias a sucursales confiables. Este fenómeno se llama pull_request_nightmare.
«Al explotar un flujo de trabajo mal configurado activado por pull_request_target, un atacante podría pasar de una solicitud de extracción bifurcada que no es de confianza a una ejecución remota de código (RCE) en un ejecutor alojado en GitHub o incluso en un ejecutor autohospedado», dijo el investigador de seguridad Roi Nisimi.
«Los flujos de trabajo de GitHub Actions que usan pull_request_target no deben verificar código que no sea de confianza sin la validación adecuada; al hacerlo, se corre el riesgo de comprometerse por completo».
Source link
