¿Qué es la ejecución de tuberías envenenadas (EPP)?

El ejemplo de ataque D-PPE ilustrado en la figura 1 se desarrolla en la siguiente sucesión de pasos:

1. Un adversario inicia una nueva rama remota dentro del repositorio, alterando el archivo de configuración de la tubería con instrucciones dañinas para recuperar las credenciales de AWS almacenadas dentro de la organización de GitHub y transmitirlas a un servidor externo bajo el control del atacante.
2. El empuje de código activa una canalización que extrae el código, incluido el archivo de configuración de la canalización maliciosa, del repositorio.
3. La tubería funciona según el archivo de configuración, ahora contaminado por el atacante. Las instrucciones maliciosas ordenan cargar en memoria las credenciales de AWS, almacenadas como secretos de repositorio.
4. Siguiendo las instrucciones del atacante, la tubería lleva a cabo la tarea de transmitir las credenciales de AWS a un servidor bajo el control del atacante.
5. En posesión de las credenciales robadas, el atacante adquiere la capacidad de infiltrarse en el entorno de producción.

EPI indirecto

La PPE indirecta se produce cuando la posibilidad de D-PPE no está disponible para un adversario con acceso a un repositorio SCM:

• Si la canalización está configurada para extraer el archivo de configuración CI de una rama separada y protegida en el mismo repositorio.
• Si el archivo de configuración de CI se almacena en un repositorio separado del código fuente, sin la opción de que un usuario pueda editarlo directamente.
• Si la compilación CI se define en el propio sistema CI, en lugar de en un archivo almacenado en el código fuente.

En estos escenarios, el atacante aún puede envenenar la canalización inyectando código malicioso en archivos referenciados por el archivo de configuración de la canalización, como scripts referenciados desde dentro del archivo de configuración de la canalización, pruebas de código o herramientas automáticas como linters y escáneres de seguridad utilizados en el CI. Por ejemplo:

• La utilidad make ejecuta los comandos definidos en el archivo Makefile.
• Scripts referenciados desde dentro del archivo de configuración de la tubería, que se almacenan en el mismo repositorio que el propio código fuente (por ejemplo, python myscript.py - donde myscript.py sería manipulado por el atacante).
• Pruebas de código: Los marcos de pruebas que se ejecutan sobre el código de la aplicación dentro del proceso de compilación dependen de archivos dedicados, almacenados en el mismo repositorio que el código fuente. Los atacantes que puedan manipular el código responsable de las pruebas podrán entonces ejecutar comandos maliciosos dentro de la compilación.
• Herramientas automáticas: Los linters y los escáneres de seguridad utilizados en la IC suelen basarse en un archivo de configuración que reside en el repositorio y que normalmente carga y ejecuta código externo desde una ubicación definida dentro del archivo de configuración.

En lugar de envenenar la tubería mediante un EPP directo, el atacante que lanza un ataque EPP indirecto inyecta código malicioso en los archivos a los que hace referencia el archivo de configuración. El código malicioso se ejecuta finalmente en el nodo pipeline y ejecuta los comandos declarados en los archivos.

En este ejemplo de ataque I-PPE, la cadena de acontecimientos se desarrolla del siguiente modo:

1. Un atacante crea una pull request en el repositorio, anexando comandos maliciosos al archivo Makefile.
2. Dado que el pipeline está configurado para dispararse en cualquier PR contra el repositorio, el pipeline Jenkins se dispara, obteniendo el código del repositorio - incluyendo el Makefile malicioso.
3. La tubería se ejecuta basándose en el archivo de configuración almacenado en la rama principal. Llega a la fase de compilación y carga las credenciales de AWS en variables de entorno, tal y como se definieron en el Jenkinsfile original. A continuación, ejecuta el comando make build, que ejecuta el comando malicioso que se añadió en Makefile.
4. La función de compilación maliciosa definida en el Makefile se ejecuta, enviando las credenciales de AWS a un servidor controlado por el atacante.
5. El atacante puede entonces utilizar las credenciales robadas para acceder al entorno de producción de AWS.

EPI público

El EPP público es un tipo de ataque EPP ejecutado por atacantes anónimos en Internet. Los repositorios públicos suelen permitir que cualquier usuario contribuya, normalmente creando pull requests. Si la tubería CI de un repositorio público ejecuta código no revisado sugerido por usuarios anónimos, es susceptible de sufrir un ataque PPE público. El EPP público también puede exponer activos internos, como secretos de proyectos privados, en los casos en los que la tubería del repositorio público vulnerable se ejecute en la misma instancia de IC que las privadas.

Importancia de la ejecución segura de canalizaciones en CI/CD

La ejecución de código malicioso no revisado en el CI a través de un ataque PPE exitoso proporciona a los atacantes el mismo nivel de acceso y capacidad que el trabajo de compilación:

• Acceso a secretos disponibles para el trabajo CI, como secretos inyectados como variables de entorno o secretos adicionales almacenados en el CI. Al ser responsables de construir código e implementar artefactos, los sistemas CI/CD suelen contener docenas de credenciales y tokens de alto valor, como a un proveedor en la nube, a registros de artefactos y al propio SCM.
• Acceso a activos externos sobre los que el nodo de trabajo tiene permisos, como archivos almacenados en el sistema de archivos del nodo, o credenciales a un entorno de nube accesible a través del host subyacente.
• Capacidad para enviar código y artefactos más adelante en el pipeline, bajo la apariencia de código legítimo construido por el proceso de construcción.
• Capacidad para acceder a hosts y activos adicionales en la red/entorno del nodo de trabajo.

Pero las organizaciones pueden salvaguardar sus productos de software y su infraestructura con una ejecución de canalización segura que garantice que todo el código compilado, probado e implementado es legítimo y no ha sido manipulado.

Riesgos asociados a la ejecución de tuberías envenenadas

Las implicaciones de la PPE pueden ser graves, desde el acceso no autorizado a los datos, la integridad comprometida del software, las interrupciones del sistema, hasta la violación de datos o incluso la toma total del sistema. Estos riesgos suponen amenazas significativas tanto para la empresa como para sus clientes, lo que subraya la gravedad de los EPI.

En la operación de compromiso de la cadena de suministro de ocho pasos que se ve en la figura 3, el atacante obtiene acceso a la tubería de IC y envenena los componentes de la aplicación SaaS. A través del componente envenenado, el atacante construye una funcionalidad de puerta trasera en la aplicación y envía los plugins envenenados a los clientes descendentes. Como es probable que las organizaciones posteriores perciban el paquete envenenado como legítimo, lo incorporan a su infraestructura en la nube o in situ.

A partir de una tubería de IC envenenada, el atacante logra un daño colateral exponencial, habiendo creado un acceso de puerta trasera a innumerables organizaciones. Este fue el caso del ataque SolarWinds.

LEA MÁS: Anatomía de un ataque a un canal de CI/CD

Prevención de la ejecución de tuberías envenenadas

Prevenir y mitigar el vector de ataque PPE implica múltiples medidas que abarcan tanto los sistemas SCM como los CI:

• Asegúrese de que los pipelines que ejecutan código no revisado se ejecutan en nodos aislados frente a los expuestos a secretos y entornos sensibles.
• Evalúe la necesidad de activar canalizaciones en repositorios públicos de contribuidores externos. Cuando sea posible, absténgase de ejecutar canalizaciones que se originen en bifurcaciones y considere la posibilidad de añadir controles como exigir la aprobación manual para la ejecución de canalizaciones.
• Para las canalizaciones sensibles, por ejemplo las que están expuestas a secretos, asegúrese de que cada rama que esté configurada para activar una canalización en el sistema CI tenga una regla de protección de rama correlativa en el SCM.
• Para evitar la manipulación del archivo de configuración CI para ejecutar código malicioso en la canalización, cada archivo de configuración CI debe ser revisado antes de que se ejecute la canalización. Alternativamente, el archivo de configuración CI puede gestionarse en una rama remota, separada de la rama que contiene el código que se está construyendo en el pipeline. La sucursal remota debe configurarse como protegida.
• Elimine los permisos concedidos en el repositorio SCM a los usuarios que no los necesiten.
• Cada canalización sólo debe tener acceso a las credenciales que necesita para cumplir su propósito. Las credenciales deben tener los privilegios mínimos requeridos.

Preguntas frecuentes sobre la ejecución de tuberías envenenadas