Integració contínua i desplegament continu (CI/CD) pipelinetenen un paper fonamental en la facilitació del desenvolupament de programari racionalitzat. Tot i això, com que aquests pipelineesdevenen cada cop més crucials, la imperatiu de protegir-los de les vulnerabilitats es fa més pronunciada. Aquesta investigació en profunditat se centra en abordar un risc destacat identificat al Top-10 de l'OWASP. CI/CD Riscos de seguretat: Enverinat Pipeline Execució (EPI).
Què és enverinat? Pipeline Execució (EPI)
Segons el Top-10 de l'OWASP CI/CD Riscos de seguretat, “Intoxicats Pipeline Execució (PPE) el risc fa referència a la capacitat d'un atacant amb accés als sistemes de control de codi font, i sense accés a l'entorn de compilació, manipular el procés de compilació injectant codi/ordres malicioses a la compilació pipeline configuration, essencialment "enverinant" el pipeline i executant codi maliciós com a part del procés de compilació”
En poques paraules, enverinat Pipeline L'execució (PPE) es produeix quan l'atacant pot modificar el pipeline lògica.
Hi ha dos variants:
- EPI directe (D-PPE): En un escenari D-PPE, l'atacant modifica el fitxer de configuració de CI en un repositori al qual tenen accés, ja sigui enviant el canvi directament a una branca remota no protegida del repositori o enviant una PR amb el canvi des d'una branca o una bifurcació. Des de la CI pipeline l'execució està definida per les ordres del fitxer de configuració de CI modificat, les ordres malicioses de l'atacant finalment s'executen al node de compilació un cop la compilació pipeline s'activa.
- EPI indirecte (I-PPE): En certs casos, la possibilitat de D-PPE no està disponible per a un adversari amb accés a un SCM repositori (per exemple, si el pipeline està configurat per extreure el fitxer de configuració de CI d'una branca protegida separada al mateix repositori). En un escenari així, en lloc d'enverinar el pipeline en si mateix, un atacant injecta codi maliciós als fitxers als quals fa referència pipeline (per exemple: scripts als quals es fa referència des de dins del pipeline fitxer de configuració)
En ambdós casos, GitHub executarà el fitxer modificat pipeline sense necessitat de revisió ni aprovació prèvia.
Detecció precoç d'EPI
Com podem detectar aquest tipus de vulnerabilitat?
Vegem aquest exemple pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
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_SECRET
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.
I el contingut d'un script de shell de simulació (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
L' pipeline és força simple: el seu objectiu és proporcionar al revisor alguns consells preliminars per a la Pull Request Procés d'acceptació (PR):
- S'activarà el pull_request (és a dir, sempre que es crea una PR)
- Revisa el codi PR (és a dir, el codi contribuït)
- Farà la construcció
- Executarà proves sobre codi contribuït (per exemple, executant un script de shell)
Els passos 3 (fer la compilació) i 4 (executar la prova) fallaran si el codi no es compila o no supera les proves. Per tant, aquests passos actuen com a condició necessària, però no suficient, per acceptar la PR. Si tenen èxit, l'administrador del repositori procedirà a revisar el codi contribuït i, a partir d'això, acceptarà/rebutjarà/comentarà la PR.
Escàner Xygeni
Xígeni proporciona una CLI (la "Escàner Xygeni") que es pot integrar en un pipeline o executar-lo en una línia d'ordres. L'escàner Xygeni processarà el pipelines per comprovar si hi ha vulnerabilitats i, si es proporciona un PAT de GitHub, es connectarà a GitHub per descobrir vulnerabilitats a nivell d'organització/repositori.
Inventari de Xygeni
Quan executem Xygeni Scanner en aquest repositori, descobreix un conjunt útil d'actius (el Inventari de Xygeni). L'inventari s'omplirà amb molts tipus diferents de CI/CD béns, Com ara:
- L' SCM Sistema on s'emmagatzema el repositori
- L' SCM connectors instal·lat/utilitzat
- L' Repositori de codi si mateix
- L' SCM Organització on pertany el repositori
- L' CI/CD Pipelines i Treball
- L' CI/CD Sistema executant el pipelines
- IaC Recursos definit al repositori
- External Dependències
- etc ..
En el nostre exemple, podem filtrar l'inventari per algun tipus d'actiu específic (SCM- i actius relacionats amb CICD), de manera que podem veure que:
- SCM El sistema és GitHub Cloud
- El repositori s'emmagatzema al núvol de GitHub i pertany a una organització específica de GitHub.
- Hi ha dos pipelines impulsat per GitHub (CI/CD sistema)
- Cada pipeline conté un pas específic
Seleccionant l'anterior pipeline podem veure algunes vulnerabilitats:
- At pipeline nivell, és vulnerable a tots dos directe i EPI indirectes.
Podem veure els detalls d'aquells enverinats Pipeline Vulnerabilitats d'execució
Xygeni detecta que és vulnerable al D-PPE perquè s'activa en un Pull Request esdeveniment i no hi ha controls de seguretat addicionals, de manera que qualsevol usuari del repositori pot modificar el pipeline i aquestes modificacions s'executaran sense cap revisió ni aprovació.
En el mateix sentit, Xygeni també detecta que és vulnerable a l'EPI intraperitoneal a causa de la crida a l'script de shell des del pipelineQualsevol usuari del repositori pot modificar l'script de shell i aquestes modificacions s'executaran sense cap revisió ni aprovació.
Do you want to know more?
Explotació de l'EPI
Per explotar l'EPI, considerem un escenari on hi ha dos tipus d'usuaris de repositori:
- An usuari intern (un desenvolupador intern que treballa en aquest repositori), amb permisos d'escriptura al repositori
- An usuari extern (un desenvolupador externalitzat que treballa en aquest repositori però amb permisos de lectura al repositori), és a dir, no té permís per bifurcar el repositori i està obligat a treballar en una bifurcació.
Imaginem que tots dos són atacants maliciosos (o suplantats per un actor maliciós). El repositori conté algun secret i tots dos volen... robar el secret del repositori i enviar-lo a un servidor controlat per un hacker. Per fer-ho, aprofitaran l'enverinat Pipeline Vulnerabilitats d'execució de pipeline.
En ambdós casos (usuari extern i intern), obren un Pull Request amb les mateixes modificacions:
- L' pipeline i l'script de shell es modifica a llegeix el secret del medi ambient i enviar-lo a un servidor controlat per un hacker
Les modificacions poden ser les següents:
Tots dos usuaris crearan un Pull Request amb les modificacionsEn crear la relació personal, El GitHub executarà ambdues modificacions (sense necessitat de revisió o aprovació prèvia), donant com a resultat el següent:
El mateix per a usuaris d'escriptura i lectura, En ambdós casos s'executen D-PPE i I-PPE, amb la diferència que L'usuari amb permisos de lectura no pot accedir als secrets. (!!!!)
Aquesta raó és perquè, En el cas d'una PR provinent d'una bifurcació, GitHub no permet l'accés als secrets del repositori. Tot i que l'usuari que llegeix no pot llegir els secrets, encara pot executar qualsevol altre programa. Un exemple d'atac típic és la creació de PRs que descarreguen un miner de criptomonedes, de manera que l'executor de GitHub executarà el miner de criptomonedes quan executi un programa enverinat. pipeline.
Aquest no és un entorn segur, és clar!! Què podria fer l'administrador del repositori per evitar-ho?
Després d'una mica de cerca a Google, l'administrador del repositori decideix modificar el pipeline ser activat en un sol·licitud_d'extracció_objectiu esdeveniment. Per què? Perquè pipelines activat a pull_request_target no permet l'execució pipeline modificacions, és a dir, malgrat qualsevol modificació de l'usuari, l'"original" pipeline s'executarà.
Seguint el nostre exemple, l'atac serà el mateix que abans. Què passarà després d'això? pipeline modificació?
Com s'esperava, No s'executa el D-PPE però, com que l'I-PPE encara hi és, L'usuari amb permisos de lectura ara pot accedir al secret del repositori!!!
Quin és el motiu pel qual l'usuari amb dret de lectura ara té accés als secrets? Tot i que pipeline no es pot modificar, encara és possible modificar l'script de shell. Quan un pipeline s'activa a pull_request_target, s'executarà en mode privilegiat so també serà l'script de shell, cosa que fa que l'script de shell tingui accés als secrets del repositori!!
Mesures préventives
GitHub proporciona algunes mesures per protegir-se contra PR malicioses.
Normes de protecció de sucursals
Amb GitHub podeu definir regles de protecció de branques sobre branques seleccionades.
Per a les branques protegides, podeu especificar una política que requereix una pull request abans de la fusió (així com condicions addicionals com ara un nombre requerit d'aprovacions, revisions dels propietaris del codi, etc.)
Un parell de condicions que mereixen una consideració especial són:
- "Permet que els actors especificats evitin els requisits pull requests".
- "No permeteu que s'eliminin els paràmetres anteriors"
Tot i que la majoria de les condicions afegeixen rigor a la política, aquestes la relaxen i això podria comportar una porta oberta a activitats malicioses, per exemple, en cas que actors "privilegiats" robin credencials.
Restringeix els permisos de GITHUB_TOKEN (privilegi mínim)
Restringeix els permisos del token de GitHub només als necessaris; d'aquesta manera, fins i tot en cas que els atacants aconsegueixin comprometre la teva seguretat. pipeline, no podran fer gaire cosa.
Evita la interpolació de cadenes utilitzant pipeline variables d'entorn
Sempre que utilitzeu algunes variables d'entrada al vostre pipeline, tingueu en compte que s'han de considerar per defecte com a dades "no fiables" (el seu contingut està controlat per l'usuari final). Vegeu Accions i fluxos de treball no fiables segurs i Aprèn les accions de Github.
Sempre hauríeu d'utilitzar variables d'entorn per inserir variables d'entrada dins dels scripts en comptes d'utilitzar la interpolació de cadenes.
Execucions de flux de treball i requisits d'aprovació
per públic repositoris, GitHub permet especificar com treballar amb relacions públiques "externes".
La configuració de l'organització del GitHub ("Org >> Configuració >> Accions >> General") permet especificar com gestionar les PR externes:
Per defecte, GitHub requerirà l'aprovació de relacions públiques per als col·laboradors per primera vegada, cosa que complicarà els atacs de sol·licituds malicioses. Tot i així, l'atacant podria guanyar-se la confiança dels mantenidors del projecte, per exemple, contribuint amb alguna informació innocent. pull request abans del veritable atac.
En aquest sentit, el La tercera opció (requerir l'aprovació de tots els col·laboradors externs) afegeix un nivell de control més alt.
per privat repositoris, GitHub també proporciona un control útil tant a nivell d'organització com de repositori.
"Executa fluxos de treball des de Pull Requests" (no marcat per defecte) permet als usuaris executar fluxos de treball des de PR de fork (utilitzant un GITHUB_TOKEN amb permisos de només lectura i sense accés als secrets). Seleccionant aquesta opció juntament amb l'última ("Requereix aprovació per als fluxos de treball de PR de fork"), podeu arribar a una política similar als repositoris privats (com es mostra més amunt).
Com hem vist en l'exploit PPE d'un usuari de lectura, permetent executar fluxos de treball des d'una forquilla pull requests és insegur!!
Les opcions restants (“Enviar tokens d'escriptura a fluxos de treball des de la bifurcació pull requests"I"Enviar secrets i variables a fluxos de treball des de pull requests") reduir el nivell de seguretat aplicat a les PR de forquilla.
Podeu definir aquesta política de forquilla a nivell d'organització o a nivell de repositori. Si la política està desactivada a nivell d'organització, no es pot habilitar a nivell de repositori. Però, si la política està habilitada a nivell d'organització, es pot deshabilitar a nivell de repositori.
Resum
Esperem que hàgiu vist les implicacions de tenir alguns pipeline vulnerable a enverinat Pipeline Execució. És massa fàcil de commit un vulnerable pipeline, i és difícil escriure'n una de segura.
Per tant, és molt valuós utilitzar l'escàner Xygeni per conèixer aquestes vulnerabilitats.
No pots resoldre una vulnerabilitat si no saps de la seva existència!!
Però… encara hi ha una pregunta pendent… Com evitar l'EPI-I?
Aquest serà el tema de la nostra propera publicació 🙂 … Enverinat indirectament Pipeline Execució (I-PPE) !!
