Continue integratie en continue implementatie (CI/CD) pipelines spelen een cruciale rol bij het faciliteren van gestroomlijnde softwareontwikkeling. Toch, zoals deze pipelines steeds belangrijker worden, wordt de noodzaak om ze te beschermen tegen kwetsbaarheden steeds duidelijker. Dit diepgaande onderzoek richt zich op het aanpakken van een prominent risico dat is geïdentificeerd in de OWASP Top-10 CI/CD Veiligheidsrisico's: vergiftigd Pipeline Uitvoering (PPE).
Wat is vergiftigd Pipeline Uitvoering (PPE)
Volgens OWASP Top-10 CI/CD Veiligheidsrisico's,vergiftigde Pipeline Uitvoering (PPE) risico verwijst naar het vermogen van een aanvaller met toegang tot broncontrolesystemen – en zonder toegang tot de gebouwde omgeving – om het bouwproces te manipuleren door kwaadaardige code/opdrachten in de bouw te injecteren pipeline configuratie, eigenlijk het 'vergiftigen' van de pipeline en het uitvoeren van kwaadaardige code als onderdeel van het bouwproces”
In een paar woorden: Vergiftigd Pipeline Uitvoering (PPE) wordt geproduceerd wanneer de aanvaller kan het pipeline logica.
Er zijn er twee varianten:
- Directe PBM (D-PPE): In een D-PPE-scenario, de aanvaller wijzigt het CI-configuratiebestand in een repository waartoe ze toegang hebben, door de wijziging rechtstreeks naar een onbeschermde externe branch op de repo te pushen, of door een PR in te dienen met de wijziging van een branch of een fork. Sinds de CI pipeline uitvoering wordt gedefinieerd door de opdrachten in het gewijzigde CI-configuratiebestand; de kwaadaardige opdrachten van de aanvaller worden uiteindelijk uitgevoerd in het build-knooppunt zodra de build is voltooid pipeline wordt geactiveerd.
- Indirecte PBM (I-PPE): In bepaalde gevallen is de mogelijkheid van D-PPE niet beschikbaar voor een tegenstander met toegang tot een SCM repository (bijvoorbeeld als de pipeline is geconfigureerd om het CI-configuratiebestand uit een afzonderlijke, beveiligde vertakking in dezelfde repository op te halen). In een dergelijk scenario, in plaats van de pipeline zelf injecteert een aanvaller kwaadaardige code in bestanden waarnaar wordt verwezen door de pipeline (bijvoorbeeld: scripts waarnaar wordt verwezen vanuit de pipeline configuratiebestand)
In beide gevallen, GitHub zal het gewijzigde pipeline zonder dat een eerdere beoordeling of goedkeuring nodig is.
Vroegtijdige detectie van PBM’s
Hoe kunnen we dit soort kwetsbaarheden detecteren?
Laten we dit voorbeeld eens bekijken 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. En de inhoud van een dummy shell-script (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0De pipeline is vrij eenvoudig: het doel is om de recensent enkele voorlopige hints te geven voor de Pull Request (PR) acceptatieproces:
- Het wordt geactiveerd pull_request (dat wil zeggen wanneer er een PR wordt aangemaakt)
- Het checkt de PR-code uit (dwz de bijgedragen code)
- Het zal de constructie maken
- Het zal tests uitvoeren op de bijgedragen code (bijvoorbeeld door een shellscript uit te voeren)
Stappen #3 (de build maken) en #4 (test uitvoeren) zullen mislukken als de code niet compileert of de tests niet doorstaat. Deze stappen fungeren dus als een noodzakelijke, maar niet voldoende voorwaarde om de PR te accepteren. Indien succesvol, zal de repo-beheerder doorgaan met het beoordelen van de bijgedragen code en op basis daarvan zal hij/zij de PR accepteren/afwijzen/commentaar geven.
Xygeni-scanner
Xygeni biedt een CLI (de “Xygeni-scanner”) die kunnen worden ingebed in een pipeline of voer het uit op een opdrachtregel. De Xygeni Scanner verwerkt de pipelines om te controleren op kwetsbaarheden en, als er een GitHub PAT wordt geleverd, zal deze verbinding maken met GitHub om kwetsbaarheden op organisatie-/repo-niveau te ontdekken.
Xygeni-inventaris
Wanneer we Xygeni Scanner op deze repository uitvoeren, ontdekt het een nuttige reeks assets (de Xygeni-inventaris). De inventaris zal worden gevuld met veel verschillende soorten CI/CD activaZoals:
- De SCM Systeem waar de repository is opgeslagen
- De SCM Plugins geïnstalleerd/gebruikt
- De Code opslagplaats zelf
- De SCM Organisatie waartoe de repository behoort
- De CI/CD Pipelines en banen
- De CI/CD Systeem het runnen van de pipelines
- IaC Informatiebronnen gedefinieerd in de repository
- Extern afhankelijkheden
- enz..
In ons voorbeeld kunnen we de inventaris filteren op een specifiek activatype (SCM- en CICD-gerelateerde activa), dus we kunnen zien dat:
- SCM systeem is GitHub Cloud
- Repo wordt opgeslagen in GitHub Cloud en behoort toe aan een specifieke GitHub-organisatie
- Er zijn er twee pipelinewordt aangestuurd door GitHub (CI/CD systeem)
- Elke pipeline bevat één specifieke stap
Door het bovenstaande te selecteren pipeline we kunnen enkele kwetsbaarheden zien:
- At pipeline niveau is het kwetsbaar voor beide Direct en Indirecte PBM.
We kunnen de details zien van degenen die vergiftigd zijn Pipeline Kwetsbaarheden bij uitvoering
Xygeni detecteert dat dit het geval is kwetsbaar voor D-PPE omdat het wordt geactiveerd op een Pull Request gebeurtenis en er zijn geen extra beveiligingscontroles, dus elke repo-gebruiker kan de pipeline en deze wijzigingen zullen worden uitgevoerd zonder enige beoordeling of goedkeuring.
In dezelfde zin detecteert Xygeni ook dat dit het geval is kwetsbaar voor I-PPE vanwege de aanroep van het shellscript vanuit de pipeline: elke repo-gebruiker kan het shellscript wijzigen en deze wijzigingen zullen worden uitgevoerd zonder enige beoordeling of goedkeuring.
Wil je meer weten?
Exploitatie van PBM
Laten we, om de PPE te exploiteren, een scenario overwegen waarin deze wel aanwezig zijn twee soorten repo-gebruikers:
- An interne gebruiker (een interne ontwikkelaar die aan die repository werkt), met schrijfrechten voor de repository
- An externe gebruiker (een uitbestede ontwikkelaar die aan die repository werkt maar met leesrechten voor de repo), dwz hij mag de repo niet vertakken en wordt gedwongen om op een fork te werken.
Laten we ons voorstellen dat beide kwaadwillende aanvallers zijn (of worden nagebootst door een kwaadwillende actor). De repo bevat een geheim en beide willen om het repositorygeheim te stelen en stuur het naar een door een hacker bestuurde server. Om dit te doen, zullen ze profiteren van de Poisoned Pipeline Kwetsbaarheden bij de uitvoering van de pipeline.
In beide gevallen (externe en interne gebruiker) openen ze een Pull Request met dezelfde wijzigingen:
- De pipeline en het shellscript worden gewijzigd naar lees het geheim uit de omgeving en stuur het naar een door een hacker bestuurde server
Wijzigingen kunnen als volgt zijn:
Beide gebruikers zullen een Pull Request met de wijzigingen. Bij het aanmaken van de PR, GitHub zal beide wijzigingen uitvoeren (zonder voorafgaande beoordeling of goedkeuring), resulterend in het volgende:
Hetzelfde voor schrijf- en leesgebruikers, in beide gevallen worden D-PPE en I-PPE uitgevoerd, met het verschil dat de gelezen gebruiker heeft geen toegang tot de geheimen. (!!!!)
Deze reden is omdat, in het geval dat een PR afkomstig is van een fork, staat GitHub geen toegang toe tot de repo-geheimen. Hoewel de leesgebruiker de geheimen niet kan lezen, kan hij/zij nog steeds elk ander programma uitvoeren. Een typisch voorbeeld van een aanval is het maken van PR's die een cryptominer downloaden, zodat de GitHub-runner de cryptominer zal uitvoeren bij het uitvoeren van een vergiftigde pipeline.
Dit is natuurlijk geen veilige omgeving!! Wat kan de repo-beheerder doen om dit te voorkomen?
Na wat googlen besluit de repositorybeheerder om de pipeline worden geactiveerd op een pull_request_target evenement. Waarom? Omdat pipelineProgramma's die worden geactiveerd op pull_request_target staan uitvoering niet toe pipeline wijzigingen, dwz ondanks eventuele wijzigingen door de gebruiker blijft het “originele” pipeline zal worden uitgevoerd.
Als we ons voorbeeld volgen, zal de aanval hetzelfde zijn als voorheen. Wat zal er hierna gebeuren pipeline wijziging?
Zoals verwacht, D-PPE wordt niet uitgevoerd maar omdat I-PPE er nog steeds is, de gelezen gebruiker heeft nu toegang tot het repositorygeheim!!!
Wat is de reden dat de gelezen gebruiker nu toegang heeft tot geheimen? Hoewel de pipeline kan niet worden gewijzigd, het is nog steeds mogelijk om het shellscript te wijzigen. Wanneer een pipeline wordt geactiveerd op pull_request_target, zal het worden uitgevoerd in de bevoorrechte modus so het zal ook het shellscript zijn, waardoor het shellscript toegang heeft tot repositorygeheimen!!
Preventieve maatregelen
GitHub biedt enkele maatregelen om te beschermen tegen kwaadwillige PR's.
Regels voor branchebescherming
Met GitHub kunt u Branch Protection Rules definiëren voor geselecteerde branches.
Voor uw beschermde branches kunt u een beleid specificeren dat heeft nodig pull request voor het samenvoegen (evenals aanvullende voorwaarden zoals een vereist aantal goedkeuringen, beoordelingen van code-eigenaren, etc.)
Een aantal voorwaarden die bijzondere aandacht verdienen zijn:
- "Geef gespecificeerde actoren de mogelijkheid om de vereiste te omzeilen pull requests'.
- "Sta niet toe dat de bovenstaande instellingen worden omzeild"
Hoewel de meeste voorwaarden het beleid strenger maken, versoepelen deze voorwaarden het beleid en dat kan een open deur met zich meebrengen voor kwaadwillige activiteiten, bijvoorbeeld in het geval dat inloggegevens worden gestolen door ‘bevoorrechte’ actoren.
Beperk GITHUB_TOKEN-rechten (minste rechten)
Beperk de GitHub-tokenmachtigingen alleen tot de vereiste machtigingen; op deze manier, zelfs als de aanvallers erin slagen uw computer in gevaar te brengen pipeline, zullen ze niet veel kunnen doen.
Vermijd tekenreeksinterpolatie door gebruik te maken van pipeline env-variabelen
Wanneer u invoervariabelen in uw pipelineHoud er rekening mee dat ze standaard als “niet-vertrouwde” gegevens moeten worden beschouwd (hun inhoud wordt beheerd door de eindgebruiker). Zien Niet-vertrouwde acties en workflows veilig en Leer Github-acties.
U moet altijd omgevingsvariabelen gebruiken om invoervariabelen in scripts in te voegen, in plaats van tekenreeksinterpolatie te gebruiken.
Workflowruns en goedkeuringsvereisten
Bij publiek repos, GitHub maakt het mogelijk om te specificeren hoe te werken met “externe” PR’s.
GitHub-organisatie-instellingen (“Org >> Instellingen >> Acties >> Algemeen”) laten specificeren hoe externe PR's moeten worden beheerd:
Standaard vereist GitHub PR-goedkeuring voor 1e-keer-bijdragers, waardoor kwaadaardige verzoekaanvallen ingewikkelder worden. Toch kan de aanvaller het vertrouwen van de projectbeheerders winnen door bijvoorbeeld wat onschuldige bijdragen te leveren. pull request vóór de echte aanval.
In deze zin is de De derde optie (goedkeuring vereisen van alle externe medewerkers) voegt een hoger niveau van controle toe.
Bij privaat repos biedt GitHub ook nuttige controle, zowel op organisatie- als repo-niveau.
"Workflows uitvoeren vanuit Pull Requests” (standaard niet aangevinkt) stelt gebruikers in staat workflows uit te voeren vanaf fork-PR’s (met behulp van een GITHUB_TOKEN met alleen-lezen-rechten en zonder toegang tot geheimen). Door deze optie samen met de laatste optie te selecteren (“Goedkeuring vereisen voor vork-PR-workflows”), kunt u een beleid hanteren dat vergelijkbaar is met dat van privéopslagplaatsen (zoals hierboven weergegeven).
Zoals we hebben gezien in de PPE-exploit van een gelezen gebruiker: het mogelijk maken om workflows uit te voeren vanaf een fork pull requests is onveilig!!
De resterende opties (“Schrijftokens naar workflows verzenden vanaf een fork pull requests"En"Stuur geheimen en variabelen naar workflows van voor pull requests") het beveiligingsniveau verlagen toegepast op vork-PR's.
U kunt dit forkbeleid op organisatieniveau of op opslagplaatsniveau definiëren. Als het beleid is uitgeschakeld op organisatieniveau, kan het niet worden ingeschakeld op opslagplaatsniveau. Maar als het beleid op organisatieniveau is ingeschakeld, kan het op opslagplaatsniveau worden uitgeschakeld.
Samenvatting
We hopen dat je de gevolgen ervan hebt gezien pipeline kwetsbaar voor vergiftigd Pipeline Executie. Het is te gemakkelijk om commit een kwetsbaar pipeline, en het is moeilijk om een veilige te schrijven.
Het is dus zeer waardevol om de Xygeni Scanner te gebruiken om op de hoogte te zijn van dergelijke kwetsbaarheden.
Je kunt een kwetsbaarheid niet oplossen tenzij je je bewust bent van het bestaan ervan !!
Maar... Er is nog een openstaande vraag... Hoe de I-PPE vermijden?
Dit zal het onderwerp zijn van ons volgende bericht 🙂 … Indirect vergiftigd Pipeline Uitvoering (I-PPE) !!
