An eisem fréiere Post iwwer CI/CD Pipelines, mir hunn gesinn wéi een e Hacker mécht CI/CD Szenario datt vermutlech geschützt gouf.
Loosst eis un eise Punkt am virege Post erënneren: mir hunn ugefaange mat e puer pipeline dat war vulnérabel fir Indirekt Vergëftung Pipeline Ausféierung (I-PPE) an, fir dat ze behiewen, hu mir decidéiert, d' pipeline an zwee:
- Déi 1. pipeline (Build CI), sécher fir D-PPE an I-PPE, géif de PR-Code kontrolléieren, de Build maachen an en Artefakt generéieren
- De 2ten pipeline (Test CI), och sécher fir D-PPE an I-PPE géifen de Basiscode iwwerpréiwen (fir Ännerunge vum Shell-Skript ze vermeiden) an déi originell Scripte géint den Artefakt ausféieren.
- Fir den Test-CI ze synchroniséieren pipeline fir NO dem Build CI auszeféieren pipeline, mir benotzt workflow_run ausléisen.
Mir hunn dëst Szenario #3 genannt.
Obwuel, wéi mir an deem Beitrag erwähnt hunn, et aner Léisunge gëtt, hu mir decidéiert dës "Léisung" aus pädagogesche Grënn ëmzesetzen, fir datt mir déif an d'Schwachstelle vun ... kënne goen. CI/CD pipelines.
Duerno hu mir gesinn, wéi een dëst Szenario hacke kann, andeems Vergëftung vum ArtefaktDëst ass wat mir nennen Artefaktvergëftung, also d'Méiglechkeet, den pipeline Logik duerch Modifikatioun vun engem pipeline Artefakt.
Wat ass de Problem mat dëser Approche? Mir hunn gesinn, datt de Problem entsteet, wann e 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 gesinn hunn an der Post).
De Benotzer kann dann en neien erstellen pipeline mam selwechten Numm wéi Build CI !! Jo, et ass iwwerraschend, awer GitHub erlaabt Iech zwou ze kreéieren pipelines mam selwechten Numm!!
Wann de Benotzer eng PR mat dësen Ännerungen opmécht, déi „nei“ pipeline gëtt higeriicht (e vergëft Artefakt eroplueden) an den Deploy CI pipeline gëtt duerno ausgeféiert, wouduerch dat "modifizéiert" Shellskript dat "ursprénglecht" Shellskript iwwerschreift, dat sech an der pipeline Aarbechtsberäich. Dës "Léisung" vermeit also net d'I-PPE Schwachstelle (wéi mir hei ënnendrënner gesinn)
Wat sinn d'Problemer? Op d'mannst ginn et e puer Froen:
- Éischten, Wéi kann een sécher sinn, datt de Bauprozess net manipuléiert gouf? An dësem Szenario konnt de béiswëllege Benotzer de geplangte Buildprozess mat Hëllef vu sengem ... änneren. pipeline fir en vergëften Artefakt ze kreéieren.
- Zweetens, Wéi kënne mir d'Provenienz vun engem Artefakt evaluéieren?
Dës Froen werfen eis an d'Äerm vun den Software-Attestatiounen Domain!!
Software-Attestatiounen
An attestatioun ass e Stéck vun Donnéeën representéiert Beweis vun engem EvenementAn der realer Welt nennen mir dës normalerweis Zertifikatiounen.
Zum Beispill, wann e Laboratoire Äert Blutt test, ginn d'Donnéeën iwwer den Test opgeholl a zertifizéiert. D'Resultater vum Bluttest sinn iwwerpréifbar an verfollegbar.
Méi no bei eisem IT-Beräich, kéint Dir roden, wat eng Iwwersetzung vun dësem Prozess an zum Beispill e Kompilatiounsprozess wier.
Informatiounen iwwer d'Kompilatiounsserverëmfeld an d'Tools, d'Materialien (de Quellcode) an d'Produkter/Artefakten (de binäre Code) wieren Deel vun enger sou enger Attestatioun.
Natierlech muss d'Bestätegung vun engem autoriséierten Attestateur (authentifizéiert an net widderluechtbar) generéiert ginn, fir Glaawürdegkeet ze garantéieren.
Wahrscheinlech denken e puer vun iech ... a wat ass dat? Ënnerscheed tëscht Ënnerschrëften an Attestatiounen?
Code Ënnerschrëften an Attestatiounen
Op engem héijen Niveau, a Ënnerschrëft gëtt mat Hëllef vun engem Schlësselpaar an engem Artefakt erstallt. D'Schlësselpaar besteet aus engem ëffentleche Schlëssel an engem private Schlëssel.
De Benotzer ënnerschreift en Artefakt mam private Schlëssel, an anerer kënnen dann d'Ënnerschrëft mam ëffentleche Schlëssel verifizéieren. De private Schlëssel muss geheim gehale ginn, awer de ëffentleche Schlëssel gëtt wäit verbreet.
Signaturen kënne benotzt ginn fir ze beweisen, datt de Besëtzer vum private Schlëssel de private Schlëssel benotzt huet fir den Artefakt z'ënnerschreiwen.
Signaturen net beweisen
- Dem Benotzer säin Intentioun fir den Artefakt z'ënnerschreiwen (si kéinte bedrunn gi sinn), oder
- D'Intentioun vum Benotzer, iergendeng Saach ze maachen spezifesch Fuerderung iwwer den Artefakt
mat Attestatiounen, anstatt en Artefakt direkt z'ënnerschreiwen, kreéieren d'Benotzer eng Zort Dokument datt fängt hir Absicht an hannert der Ënnerschrëft vum Artefakt an all spezifesch Fuerderungen als Deel vun dëser Ënnerschrëft gemaach gëtt.
In-toto-Attestatiounsrahmen
Dee meescht übleche Kader ass de In-toto-Attestatiounsrahmen
- definéiert eng standard Format fir Zertifizéierungen déi Sujeten, d'Artefakten, déi beschriwwe ginn, un authentifizéiert Metadaten iwwer den Artefakt bannen
- liwwert e Set vun virdefinéiert Prädikater fir d'Kommunikatioun vun authentifizéierte Metadaten duerch a bannent Software-Liwwerketten
Loosst eis e bësse méi am Detail op de Format vun der Zertifizéierung agoen.
An Attestatioun ass e digital ënnerschriwwen Dokument dat enthält Aussoen.
d' Ausso ass déi mëttler Schicht vun der Bescheinigung, déi se un eng spezifesch verbënnt Sujet an eendeiteg d'Aarte vun der Prädikat:
- Sujetop kryptographesch sécher Referenz op den Artefakt (normalerweis iwwer en Hash), an
- Prädikater: eng Rei vu spezifesche behaapt iwwer dësen Artefakt gëtt als Ausso bezeechent. Dës Fuerderunge kënne benotzt ginn fir alles auszedrécken (a spéider ze beweisen), wat Dir Iech virstelle kënnt! Si kënnen eng manuell Genehmegung, d'Provenienz vum Artefakt, automatiséiert Testergebnisse, en Audit Trail oder méi duerstellen!
Wann dës Erklärung kryptographesch ënnerschriwwe gëtt, gëtt se dann als en Attestatioun
Op dës Manéier erstellt d'Alice zum Beispill eng Ausso iwwer en Artefakt a ënnerschreift se mat hirem private Schlëssel, wouduerch eng Attestation entsteet.
- De Bob kann dann d'Ënnerschrëft verifizéieren an där Bescheinigung, déi him erlaabt de Fuerderungen ze vertrauen bannen.
De Bob kann dës Fuerderungen dann benotzen ze entscheeden ob d'Benotzung vun dësem Artefakt erlaabt ass oder net.
Kënnen Attestatiounen hëllefen, Artefaktvergëftung ze léisen?
No dëser Aféierung an d'Attestations, loosst eis zeréck op eist Problem goen. Wéi kënnen eis Attestatiounen hëllefen, eist Problem ze léisen, also fir Artefaktvergëftung ze vermeiden?
De béiswëllege Benotzer konnt en Artefakt erstellen, andeems hien den "offiziellen" Mechanismus ëmgaangen huet, also andeems hien seng/hir ... benotzt huet. pipeline fir den Artefakt ze generéieren.
Et wier erstaunlech, wa mir kéinte beweisen, datt d'Artefakte, déi erofgeluede ginn, mat den offiziellen gebaut goufen. pipelines. Dëst ass nëmmen ee Beispill vun deem, wat mir "Manipulatiounspunkten" kéinte nennen, awer et kéinte vill aner ginn.
Wéi Dir op der Foto uewen gesitt, sinn d'Manipulatiounspunkten villfälteg. Op dës Manéier kann de Konsument pipeline (Test CI an eisem Beispill) muss evaluéieren d'Integritéit vum Bauprozess Wéi och de d'Integritéit vum Artefakt selwer.
An eisem Beispill gouf den vergëften Artefakt duerch d'Aféierung vun engem neien (vergëften) erstallt. pipeline dat de Bauprozess manipuléiert. Mee de béiswëllege Benotzer hätt fäeg gewiescht:
- den Code änneren nodeems en aus dem Checkout erausgeholl gouf SCM fir e béiswëllege Binär ze generéieren
- Ersetzt déi richteg Binärdatei, déi vun der Kompilatioun produzéiert gëtt, duerch all aner béiswëlleg Binärdatei
- d'Artefaktregister kompromittéieren an en vergëften Artefakt eroplueden, deen op iergendeng aner Manéier gebaut gouf
- etc.
Wéi Dir gesitt, kann et verschidde "Manipulatiouns"-Punkten ginn.
Wat ass hei wichteg? Natierlech fir all déi "Manipulatiounspunkten" ze schützen. Mee schlussendlech ass dat Wichtegst datt de "Konsument" vum Artefakt d'Integritéit vum Artefakt beurteele kann, an entscheede kann, ob e domat weidergoe soll oder net.
Mir kënnen d'Integritéit vun engem Artefakt bewäerten op zwee Weeër.
Eent ass andeems een d'Bewäertung vun wieren vum Artefakt.
Duerch d'Generéiere vun engem Provenanzbescheinigung, liwwere mir nëtzlech Metadaten (korrekt authentifizéiert an net-repudiéiert) iwwer den Artefakt. An de folgende Beispiller wäerte mir benotzen Xygeni SALT (Software Attestations Layer for Trust), d'Komponent fir d'Generéieren, d'Registréierung an d'Verifizéierung vu Softwareattestatiounen.
Am uewe genannten Code kënnt Dir gesinn, datt et e Schrëtt gëtt, deen d'War-Datei erstellt, an en zweete Schrëtt, deen d'generéiert ProvenanzbescheinigungFir et ze maachen, den pipeline benotzt de private Schlëssel a schléisst och de ëffentleche Schlëssel an der Attestatioun an.
Hannert de Kulissen, Xygeni's Salz De Kommando späichert d'Attestatioun an engem Ledger (och bekannt als en Attestatiounsregister, Rekord an eisem Fall, awer Dir kënnt all aner benotzen). Dat gemaach, de Konsument pipeline kann Xygeni enthalen Verifizéierungsmotor fir d'Provenienz vum Artefakt ze verifizéieren an d'Integritéit vum Artefakt ze bewäerten.
De Verifizéierungsprozess bewäert:
- d' Den Artefakt sha256sum ass gëlteg (d.h. et gëtt eng Bescheinigung iwwer dëst "Thema"), an
- d' d'Zertifizéierung ass richteg authentifizéiert (et gouf mat Hëllef vum passenden private Schlëssel generéiert)
Dëse Verifizéierungsprozess kann dann evaluéieren, ob souwuel den Artefakt wéi och d'Attestatioun gëlteg sinn.
Mee, wéi Dir Iech erënnert, gouf den Artefakt an eisem Fall vun engem "béiswëllegen" generéiert. pipeline (d.h. net den Original duerch eng modifizéiert pipeline). Dann musse mir weidergoen an en aneren Aspekt kontrolléieren: datt Den Artefakt gouf vum "Original" generéiert pipeline, keen aneren.
Fir dat ze maachen, füügt einfach eng einfach Zeil derbäi fir dës Konditioun ze kontrolléieren, zum Beispill:
Dës zousätzlech Kontroll klappt net, wann den Artefakt net vun eisem "Safe" generéiert gi wier. pipeline.
Wann den Artefakt vun eisem Original generéiert gouf pipeline (cicd_top10_3_salt/.github/workflows/build.yml), da funktionéiert de grep-Kommando erfollegräich, soss klappt en net, wouduerch de pipeline an all weider Schrëtt ofbriechen.
De "Bauer" pipeline ass just ee Manipulatiounspunkt fir ze kontrolléieren, awer, wéi virdru scho gesot, ginn et nach aner Manipulatiounspunkten, déi mir sollten iwwerpréiwen.
Zum Beispill, Wat geschitt wann de Quellcode nom Auschecken vum Repo a virum Build-Kommando manipuléiert gouf? An dësem Fall ass de Code, deen erstallt soll ginn, net dee selwechte wéi dee gespäichert ass. SCM.
Dëse Manipulatiounspunkt ze kontrolléieren ass sou einfach, datt een d'Hashes vum Material bei all Schrëtt kontrolléiert.
Conclusiounen
Zesummegefaasst, a Software-Attestatioun ass eng Ausso iwwer e Stéck Software, also eng authentifizéiert Ausso (Metadaten) iwwer en Softwareartefakt oder eng Sammlung vu Softwareartefakten.
Software-Attestatiounen sinn eng Generaliséierung vu rauem Artefakt/Codesignéierung. D'Attestatioun ass en ënnerschriwwenen Dokument (an engem bestëmmte Format, typescherweis baséiert op JSON), dat Metadaten mat engem Artefakt associéiert. Si representéieren Beweiser, déi Inputen (Materialien) an Outputen (produzéiert Artefakten) bei all Build-Schrëtt verbannen.
D'Attestatioune liwweren eng verifizéierbar Opzeechnung vun de Schrëtt, déi fir de Bau vun den endgültege Softwareartefakte gemaach goufen, inklusiv Inputmaterialien fir all Schrëtt an d'Ausféierung vun de Buildbefeeler.
Schlussendlech sinn Software-Attestatiounen e super Mechanismus fir vill verschidden Integritéitsaspekter vun eisem Bauprozess ze kontrolléieren.
D'Serie fäerdeg? Keng Angscht! Dir kënnt gären zeréck op 'Gëft gemaach Pipeline Ausféierung (PPE)' oder all aner Post, deen Äert Interessi erëm weckt!
Bleift drun, mir wäerten eis méi genau mat Software-Attestatiounen beschäftegen an build security a weidere Blogposts.
