Integración continua y despliegue continuo (CI/CD) pipelineLos s desempeñan un papel fundamental a la hora de facilitar el desarrollo de software optimizado. Sin embargo, como estos pipelineA medida que las vulnerabilidades se vuelven cada vez más cruciales, la necesidad de protegerlas de ellas se acentúa. Esta investigación exhaustiva se centra en abordar un riesgo importante identificado en el Top-10 de Seguridad de OWASP. CI/CD Riesgos: Envenenamiento Pipeline Ejecución (PPE).
que esta envenenado Pipeline Ejecución (PPE)
Según OWASP Top-10 Seguridad en CI/CD Riesgos, “Envenenado Pipeline Ejecución (PPE) el riesgo se refiere a la capacidad de un atacante con acceso a los sistemas de control de fuente (y sin acceso al entorno de compilación) manipular el proceso de compilación inyectando códigos/comandos maliciosos en la compilación pipeline configuración, esencialmente 'envenenando' el pipeline y ejecutar código malicioso como parte del proceso de construcción”.
En pocas palabras, envenenado. Pipeline La ejecución (PPE) se produce cuando El atacante puede modificar el pipeline lógica.
Hay dos variantes:
- EPI directo (D-PPE): En un escenario D-PPE, el atacante modifica el archivo de configuración de CI en un repositorio al que tienen acceso, ya sea enviando el cambio directamente a una rama remota desprotegida en el repositorio o enviando un PR con el cambio desde una rama o una bifurcación. Desde el CI pipeline La ejecución está definida por los comandos en el archivo de configuración de CI modificado, los comandos maliciosos del atacante finalmente se ejecutan en el nodo de compilación una vez que la compilación pipeline se activa
- EPI indirectos (I-PPE): En ciertos casos, la posibilidad de EPP D no está disponible para un adversario con acceso a un SCM repositorio (por ejemplo, si el pipeline está configurado para extraer el archivo de configuración de CI de una rama protegida separada en el mismo repositorio). En tal escenario, en lugar de envenenar la pipeline En sí mismo, un atacante inyecta código malicioso en archivos a los que hace referencia el pipeline (por ejemplo: scripts a los que se hace referencia desde dentro del pipeline archivo de configuración)
En ambos casos, GitHub ejecutará el modificado pipeline sin necesidad de revisión o aprobación previa.
Detección temprana de EPI
¿Cómo podemos detectar este tipo de vulnerabilidad?
Veamos este ejemplo pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_Secreto: ${{ Secretos.MY_Secreto }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_Secreto
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed. Y el contenido de un script de shell ficticio (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0El proceso de pipeline es bastante simple: su objetivo es proporcionar al revisor algunas sugerencias preliminares para el Pull Request (PR) proceso de aceptación:
- Se activará el solicitud de extracción (es decir, cada vez que se crea un PR)
- Extrae el código PR (es decir, el código aportado)
- Hará la construcción
- Ejecutará pruebas en el código aportado (por ejemplo, ejecutando un script de shell)
Los pasos 3 (realizar la compilación) y 4 (ejecutar la prueba) fallarán si el código no se compila o no pasa las pruebas. Por lo tanto, estos pasos actúan como una condición necesaria, pero no suficiente, para aceptar el RP. Si tiene éxito, el administrador del repositorio procederá a revisar el código aportado y, en base a eso, aceptará/rechazará/comentará el PR.
Escáner Xygeni
xygeni proporciona una CLI (el “Escáner Xygeni”) que se puede incrustar en un pipeline o ejecutar en una línea de comandos. El escáner Xygeni procesará la pipelines para buscar vulnerabilidades y, si se proporciona una PAT de GitHub, se conectará a GitHub para descubrir vulnerabilidades en el nivel de organización/repo.
Inventario Xygeni
Cuando ejecutamos Xygeni Scanner en este repositorio, descubre un conjunto útil de activos (el Inventario Xygeni). El inventario se completará con muchos tipos diferentes de CI/CD activos, tales como:
- El proceso de SCM System donde se almacena el repositorio
- El proceso de SCM Plugins instalado/usado
- El proceso de Repositorio de código sí mismo
- El proceso de SCM Organización a donde pertenece el repositorio
- El proceso de CI/CD Pipelines y trabajos
- El proceso de CI/CD System corriendo el pipelines
- IaC Recursos definido en el repositorio
- Externo Dependencias
- etc ..
En nuestro ejemplo, podemos filtrar el inventario por algún tipo de activo específico (SCM- y activos relacionados con el CICD), por lo que podemos ver que:
- SCM El sistema es GitHub Cloud
- El repositorio se almacena en GitHub Cloud y pertenece a una organización de GitHub específica.
- Hay dos pipelines impulsado por GitHub (CI/CD sistema)
- Cada plan pipeline contiene un paso específico
Seleccionando lo anterior pipeline podemos ver algunas vulnerabilidades:
- At pipeline nivel, es vulnerable a ambos Directo y EPI indirectos.
Podemos ver los detalles de aquellos envenenados. Pipeline Vulnerabilidades de ejecución
Xygeni detecta que es vulnerable al D-PPE porque se activa en un Pull Request evento y no hay controles de seguridad adicionales, por lo que cualquier usuario del repositorio puede modificarlo. pipeline y esas modificaciones se ejecutarán sin ninguna revisión o aprobación.
En el mismo sentido, Xygeni también detecta que es vulnerable al I-PPE debido a la llamada al script de shell desde el pipeline: cualquier usuario del repositorio puede modificar el script de shell y esas modificaciones se ejecutarán sin ninguna revisión ni aprobación.
Quieres saber mas?
Explotación de EPI
Para explotar el PPE consideremos un escenario donde hay dos tipos de usuarios de repositorios:
- An Usuario Interno (un desarrollador interno que trabaja en ese repositorio), con permisos de escritura en el repositorio
- An usuario externo (un desarrollador subcontratado que trabaja en ese repositorio pero con permisos de lectura en el repositorio), es decir, no se le permite bifurcar el repositorio y se le obliga a trabajar en una bifurcación.
Imaginemos que ambos son atacantes maliciosos (o se han hecho pasar por un actor malicioso). El repositorio contiene algún secreto y ambos quieren... robar el repositorio Secreto y enviarlo a un servidor controlado por piratas informáticos. Para ello se aprovecharán de los Envenenados. Pipeline Vulnerabilidades de ejecución del pipeline.
En ambos casos (usuario externo e interno), abren una Pull Request con las mismas modificaciones:
- El proceso de pipeline y el script de shell se modifican a lee el Secreto del medio ambiente y enviarlo a un servidor controlado por piratas informáticos
Las modificaciones podrían ser las siguientes:
Ambos usuarios crearán una Pull Request con las modificaciones. Tras la creación del PR, GitHub ejecutará ambas modificaciones. (sin necesidad de revisión o aprobación previa), dando como resultado lo siguiente:
Lo mismo para usuarios de escritura y lectura, en ambos casos se ejecutan D-PPE e I-PPE, con la diferencia de que El usuario de lectura no puede acceder a los Secretos. (!!!!)
Esta razón es porque, en el caso de un PR proveniente de un fork, GitHub no permite el acceso al repositorio Secretos. Aunque el usuario de lectura no puede leer los Secretos, puede ejecutar cualquier otro programa. Un ejemplo típico de ataque es la creación de solicitudes de acceso (PR) que descargan un minero de criptomonedas, de modo que el ejecutor de GitHub ejecutará el minero de criptomonedas al ejecutar un programa envenenado. pipeline.
¡¡Este no es un ambiente seguro, por supuesto!! ¿Qué podría hacer el administrador del repositorio para evitarlo?
Después de buscar en Google, el administrador del repositorio decide modificar el pipeline ser activado en un pull_request_target evento. ¿Por qué? Porque pipelineLos mensajes activados en pull_request_target no permiten la ejecución pipeline modificaciones, es decir, a pesar de cualquier modificación del usuario, el "original" pipeline será ejecutado.
Siguiendo nuestro ejemplo, el ataque será el mismo que antes. ¿Qué pasará después de esto? pipeline ¿modificación?
Como se esperaba, D-PPE no se ejecuta pero, debido a que el I-PPE todavía está allí, ¡El usuario de lectura ahora puede acceder al repositorio Secreto!
¿Cuál es la razón por la que el usuario de lectura ahora tiene acceso a Secretos? Aunque... pipeline no se puede modificar, aún es posible modificar el script de shell. Cuando un pipeline se activa en pull_request_target, se ejecutará en modo privilegiado so también será el script de shell, lo que da como resultado que el script de shell tenga acceso al repositorio Secretos!!
Medidas preventivas
GitHub proporciona algunas medidas para protegerse contra relaciones públicas maliciosas.
Reglas de protección de sucursales
Con GitHub puedes definir reglas de protección de sucursales en sucursales seleccionadas.
Para sus sucursales protegidas, puede especificar una política que requiere de un pull request Antes de fusionarse (así como condiciones adicionales, como una cantidad requerida de aprobaciones, revisiones de los propietarios del código, etc.)
Un par de condiciones que merecen una consideración especial son:
- "Permitir que actores específicos omitan los requisitos pull requests.
- "No permita omitir la configuración anterior"
Si bien la mayoría de las condiciones añaden rigor a la política, éstas la relajan y eso podría implicar una puerta abierta a actividades maliciosas, por ejemplo, en el caso de que actores “privilegiados” roben credenciales.
Restringir permisos GITHUB_TOKEN (mínimo privilegio)
Restrinja los permisos del token de GitHub solo a los requeridos; De esta manera, incluso en caso de que los atacantes logren comprometer su pipeline, no podrán hacer mucho.
Evite la interpolación de cadenas utilizando pipeline variables ambientales
Siempre que utilice algunas variables de entrada en su pipeline, tenga en cuenta que deben considerarse por defecto como datos "no confiables" (su contenido está controlado por el usuario final). Ver Acciones y flujos de trabajo no confiables seguros y Aprenda las acciones de Github.
Siempre debes usar variables de entorno para insertar variables de entrada dentro de los scripts en lugar de usar la interpolación de cadenas.
Ejecuciones de flujo de trabajo y requisitos de aprobación
Para público repositorios, GitHub permite especificar cómo trabajar con relaciones públicas “externas”.
La configuración de la organización de GitHub (“Organización >> Configuración >> Acciones >> General”) permite especificar cómo administrar las relaciones públicas externas:
De forma predeterminada, GitHub requerirá la aprobación de PR para quienes contribuyen por primera vez, lo que hace que los ataques de solicitudes maliciosas sean más complicados. Aun así, el atacante podría ganarse la confianza de los encargados del mantenimiento del proyecto, por ejemplo, si contribuye con algún material inocente. pull request Antes del verdadero ataque.
En este sentido, el La tercera opción (requerir aprobación para todos los colaboradores externos) agrega un mayor nivel de control.
Para de inversores privados repositorios, GitHub también proporciona un control útil tanto a nivel de organización como de repositorio.
"Ejecutar flujos de trabajo desde Pull Requests" (no marcada por defecto) permite a los usuarios ejecutar flujos de trabajo desde solicitudes de bifurcación (usando un GITHUB_TOKEN con permisos de solo lectura y sin acceso a Secretos). Al seleccionar esta opción junto con la anterior ("Requerir aprobación para flujos de trabajo de relaciones públicas de bifurcación”), puede alcanzar una política similar a los repositorios privados (como se muestra arriba).
Como hemos visto en el exploit PPE de un usuario leído, Permitir la ejecución de flujos de trabajo desde fork pull requests ¡¡¡no es seguro!!!
Las opciones restantes (“Enviar tokens de escritura a flujos de trabajo desde fork pull requests" y "Enviar secretos y variables a flujos de trabajo desde pull requests") disminuir el nivel de seguridad aplicado a las relaciones públicas de bifurcación.
Puede definir esta política de bifurcación a nivel de organización o a nivel de repositorio. Si la política está deshabilitada a nivel de organización, no se puede habilitar a nivel de repositorio. Pero, si la política está habilitada a nivel de organización, se puede deshabilitar a nivel de repositorio.
Resumen
Esperamos que hayas visto las implicaciones de tener algunos pipeline vulnerable al envenenamiento Pipeline Ejecución. Es demasiado fácil commit un vulnerable pipeline, y es difícil escribir uno seguro.
Por lo tanto, es muy valioso utilizar el escáner Xygeni para estar al tanto de dichas vulnerabilidades.
¡¡No puedes resolver una vuln a menos que seas consciente de su existencia!!
Pero… Todavía queda una cuestión pendiente… ¿Cómo evitar el I-PPE?
Este será el tema de nuestro próximo post 🙂… Envenenado indirecto Pipeline Ejecución (I-PPE) !!
