În postarea noastră anterioară despre CI/CD Pipelines, noi am văzut cum să piratezi un CI/CD scenariu care probabil a fost protejat.
Să ne reamintim ideea din postarea anterioară: am început cu niște pipeline care era vulnerabil la Indirect otrăvit Pipeline Execuție (I-PPE) și, pentru a remedia problema, am decis să împărțim pipeline în două:
- Primul 1 pipeline (Build CI), sigur pentru D-PPE și I-PPE, ar verifica codul PR, ar realiza compilarea și ar genera un artefact
- 2nd pipeline (Test CI), de asemenea, sigur pentru D-PPE și I-PPE ar verifica codul de bază (pentru a evita modificarea scriptului shell) și ar executa scripturile originale împotriva artefactului.
- Pentru a sincroniza CI-ul de test pipeline să ruleze DUPĂ CI-ul de construcție pipeline, noi am folosit execuție_flux_de_trebuire declanșator.
Am numit acesta Scenariul nr. 3.
Deși, așa cum am menționat în postarea respectivă, există și alte soluții, am decis să implementăm această „soluție” din motive pedagogice, pentru a putea analiza în profunzime vulnerabilitățile... CI/CD pipelines.
Ulterior, am văzut cum să depășim acest scenariu prin otrăvirea artefactuluiAceasta este ceea ce numim noi Intoxicație cu artefacte, adică abilitatea de a modifica (hacka) pipeline logica prin modificarea unei pipeline artefact.
Care este problema cu această abordare? Am văzut că problema apare atunci când orice utilizator „creează” un nou pipeline.
Dacă un utilizator deschide un PR care conține un nou pipeline, GitHub va executa asta pipeline (în anumite condiții, așa cum am văzut) în postare).
Utilizatorul poate apoi să creeze un nou pipeline cu același nume ca Build CI!! Da, este surprinzător, dar GitHub vă permite să creați două pipelinecu același nume!!
Când utilizatorul deschide un PR cu aceste modificări, noul" pipeline va fi executat (încărcarea unui artefact otrăvit) și CI-ul de implementare pipeline va fi executat după aceea, ceea ce va duce la suprascrierea scriptului shell „modificat” peste scriptul shell „original” situat în pipeline spațiu de lucru. Deci, această „soluție” nu evită vulnerabilitatea I-PPE (așa cum putem vedea mai jos)
Care sunt problemele? Cel puțin, există câteva probleme:
- În primul rând, Cum să fii sigur că procesul de construcție nu a fost modificat? În acest scenariu, utilizatorul rău intenționat a reușit să modifice procesul de construire intenționat folosindu-și pipeline pentru a crea un artefact otrăvit.
- În al doilea rând, Cum putem evalua proveniența unui artefact?
Aceste întrebări ne aruncă în brațele Atestări software domeniu!!
Atestări software
An certificat este o bucată de de date reprezentând dovada unui evenimentÎn lumea reală, în general, le numim pe acestea certificări.
De exemplu, când un laborator vă analizează sângele, datele despre test sunt înregistrate și certificate. Rezultatele analizelor de sânge sunt verificabil și trasabile.
Mai aproape de domeniul nostru IT, ați putea ghici care ar fi o traducere a acestui proces, de exemplu, într-un proces de compilare.
Informațiile despre mediul și instrumentele serverului de compilare, materialele (codul sursă) și produsele/artefactele (codul binar) ar face parte dintr-o astfel de atestare.
Evident, atestarea trebuie să fie generată de un atestator autorizat (autentificat și irefutabil) pentru a oferi credibilitate.
Probabil, unii dintre voi s-ar putea gândi... și care este Diferența dintre semnături și atestări?
Semnături de cod și atestări
La un nivel înalt, o semnătură este creată folosind o pereche de chei și un artefact. Perechea de chei este formată dintr-o cheie publică și o cheie privată.
Utilizatorul semnează un artefact folosind cheia privată, iar alții pot apoi verifica semnătura folosind cheia publică. Cheia privată trebuie păstrată secretă, dar cheia publică este distribuită pe scară largă.
Semnăturile pot fi folosite pentru a demonstra că deținătorul cheii private a folosit cheia privată pentru a semna artefactul.
Semnături nu dovedi
- Utilizatorului intenţia de să semneze artefactul (s-ar fi putut să fi fost păcăliți) sau
- Intenția utilizatorului de a face orice afirmație specifică despre artefact
cu Atestări, în loc să semneze direct un artefact, utilizatorii creează un fel de document acea surprinde intenția lor în spatele semnării artefactului și a oricărui revendicări specifice fiind realizată ca parte a acestei semnături.
Cadrul de atestare in-toto
Cel mai comun cadru este Cadrul de atestare integrală
- definește un standard format pentru atestări care leagă subiecții, artefactele descrise, de metadate autentificate despre artefact
- oferă un set de predicate predefinite pentru comunicarea metadatelor autentificate în cadrul și între lanțurile de aprovizionare cu software
Să intrăm în câteva detalii despre formatul atestării.
An Atestare este document semnat digital care conține Declarații.
Declarație este stratul intermediar al atestării, legând-o de o anumită Subiect și identificarea fără echivoc a tipurilor de Predicat:
- Subiect: referință criptografic sigură la artefact (de obicei printr-un hash) și
- Predicatiun set de elemente specifice creanțe O informație despre acel artefact se numește Declarație. Aceste afirmații pot fi folosite pentru a exprima (și ulterior a dovedi) orice vă puteți imagina! Ele pot reprezenta aprobarea manuală, proveniența artefactelor, rezultatele testelor automate, o pistă de audit sau mai multe!
Când această declarație este semnată criptografic, este denumită Atestare
În acest fel, de exemplu, Alice creează o Declarație despre un artefact și o semnează folosind cheia sa privată, creând o Atestare.
- Bob poate apoi verificarea semnăturii în acea atestare, permițându-i să ai încredere în afirmații interior.
Bob poate apoi folosi acele afirmații a decide dacă se permite sau nu utilizarea acestui artefact.
Ar putea atestările să ajute la rezolvarea problemei otrăvirii cu artefacte?
După această introducere în Atestări, să revenim la problema noastră. Cum ne pot ajuta atestările să rezolvăm problema noastră, adică să evităm otrăvirea cu artefacte?
Utilizatorul rău intenționat a reușit să creeze un artefact ocolind mecanismul „oficial”, adică folosindu-și pipeline pentru a genera artefactul.
Ar fi uimitor dacă am putea dovedi că artefactele descărcate au fost construite cu ajutorul codului oficial pipelineAcesta este doar un exemplu din ceea ce am putea numi „Puncte de manipulare”, dar ar putea exista multe altele.
După cum puteți vedea în imaginea de mai sus, punctele de manipulare sunt multiple. În acest fel, consumatorul pipeline (Testul CI în exemplul nostru) trebuie să evalueze integritatea procesului de construcție precum şi integritatea artefactului în sine.
În exemplul nostru, artefactul otrăvit a fost creat prin introducerea unui nou artefact (otrăvit) pipeline care modifică procesul de construire. Dar utilizatorul rău intenționat ar fi putut:
- modificați codul după ce a fost extras din SCM pentru a genera un fișier binar malițios
- înlocuiește fișierul binar corect produs de compilare cu orice alt fișier binar malițios
- compromite Registrul de Artefacte și încarcă un artefact otrăvit construit în orice alt mod
- etc
După cum puteți vedea, pot exista mai multe puncte de „manipulare”.
Ce este important aici? Evident, să protejăm toate acele puncte de „manipulare”. Dar, în cele din urmă, cel mai important este că „consumatorul” artefactului poate evalua integritatea artefactului și poate decide dacă să continue sau nu cu acesta.
Putem a evalua integritatea unui artefact în două moduri.
Una este prin evaluarea proveniență al artefactului.
Prin generarea unui Atestarea provenienței, oferim metadate utile (autentificate corespunzător și neconsumate) despre artefact. În exemplele următoare, vom folosi Sare Xygeni (Software Attestations Layer for Trust), componenta pentru generarea, înregistrarea și verificarea atestărilor software.
- name: Building ...
run: |
# mvn will compile and create target/MyApp.war
mvn clean package
- name: Generating provenance
run: |
#!/usr/bin/env bash
shopt -s expand_aliases
alias salt=$PWD/salt_pro/xygeni_salt/salt
echo " "
echo "-----------"
echo "Generating Provenance with CLI ..."
salt at slsa \
--basedir ${GITHUB_WORKSPACE}/target \
--key="${PRIVATE_KEY}" \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--key-password=${KEY_PASSWD} \
--output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \
--pipeline ${PIPELINE} --pretty-print \
--file ./MyApp.war
În codul de mai sus, puteți vedea că există un pas care construiește fișierul war și un al doilea pas care generează Atestarea proveniențeiPentru a face acest lucru, pipeline utilizează cheia privată și include și cheia publică în atestare.
În culise, Xygeni sare Comanda stochează atestarea într-un carte mare (cunoscut și sub numele de registru de atestare, record în cazul nostru, dar puteți folosi oricare altul). După ce a făcut asta, consumatorul pipeline poate include Xygeni Motor de verificare pentru a verifica proveniența artefactului și a evalua integritatea acestuia.
- name: 'Verifying the attestation'
run: |
#!/usr/bin/bash
echo " "
echo "-------"
# Calculate sha256sum for the artifact
SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ')
# Recover the attestation Id from the sha256sum
ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256)
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
echo " "
echo "-------"
echo "Verifying provenance ..."
salt verify \
--basedir ${GITHUB_WORKSPACE} \
--attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--file ./MyApp.war
Procesul de verificare evaluează:
- artefactul sha256sum este valid (adică există o atestare despre acel „subiect”) și
- atestarea este autentificată corespunzător (a fost generat folosind cheia privată adecvată)
Acest proces de verificare poate evalua apoi dacă atât artefactul, cât și atestarea sunt valide.
Dar, după cum vă amintiți, în cazul nostru, artefactul a fost generat de o persoană „rău intenționată” pipeline (adică nu originalul printr-o modificare) pipeline). Atunci trebuie să verificăm un alt aspect: faptul că artefactul a fost generat de „original” pipeline, nu oricare altul.
Pentru a face asta, includeți pur și simplu o linie pentru a verifica acea condiție, de exemplu:
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF)
echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml
Această verificare suplimentară va eșua dacă artefactul nu ar fi fost generat de „seiful” nostru. pipeline.
Dacă artefactul a fost generat de originalul nostru pipeline (cicd_top10_3_salt/.github/workflows/build.yml), comanda grep va reuși, altfel va eșua, întrerupând pipeline și anularea oricăror etape ulterioare.
„Constructorul” pipeline este doar un punct de verificare a încălcării regulilor, dar, așa cum am menționat anterior, există și alte puncte de verificare a încălcării regulilor.
De exemplu, Ce se întâmplă dacă codul sursă a fost modificat după extragerea depozitului și înainte de comanda de construire? În acest caz, codul care trebuie construit nu este același cu cel stocat în SCM.
A verifica acest punct de alterare este la fel de ușor ca și cum ai verifica hash-urile materialului la fiecare pas.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[])
SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[])
Concluzii
În concluzie, o Atestarea software-ului este o afirmație făcută despre un software, adică o declarație autentificată (metadate) despre un artefact software sau o colecție de artefacte software.
Atestările software sunt o generalizare a semnării artefactelor/codului brut. Atestarea este un document semnat (într-un format dat, de obicei bazat pe JSON) care asociază metadatele cu un artefact. Acestea reprezintă dovezi care leagă intrările (materialele) și ieșirile (artefactele produse) la fiecare etapă de construcție.
Atestările oferă o înregistrare verificabilă a pașilor parcurși pentru construirea artefactelor software finale, inclusiv materialele de intrare pentru fiecare pas și comenzile de construire executate.
În concluzie, atestările software sunt un mecanism excelent pentru a verifica multe aspecte diferite ale integrității procesului nostru de construire.
Ai terminat seria? Nu-ți face griji! Nu ezita să revii la 'Otrăvit Pipeline Execuție (EIP)„sau orice altă postare care îți stârnește din nou interesul!”
Rămâneți pe fază, vom analiza în detaliu atestările software și build security în articole ulterioare pe blog.
