In unserem vorherigen Beitrag über CI/CD Pipelines, wir sahen wie man einen hackt CI/CD Szenario, das vermutlich wurde geschützt.
Erinnern wir uns an unseren Punkt im vorherigen Beitrag: Wir begannen mit einigen pipeline das war anfällig für Indirekt vergiftet Pipeline Ausführung (I-PPE) und um das Problem zu beheben, haben wir beschlossen, die pipeline in zwei:
- Die 1st pipeline (Build CI), sicher für D-PPE und I-PPE, würde den PR-Code auschecken, den Build erstellen und ein Artefakt generieren
- Der 2nd pipeline (Test CI), auch sicher für D-PPE und I-PPE, würde den Basiscode auschecken (um Shell-Skriptänderungen zu vermeiden) und die Originalskripte für das Artefakt ausführen.
- So synchronisieren Sie das Test-CI pipeline zur Ausführung NACH dem Build CI pipeline, wir verwendeten workflow_run auslösen.
Wir haben dies Szenario Nr. 3 genannt.
Obwohl es, wie wir in diesem Beitrag erwähnt haben, andere Lösungen gibt, haben wir uns aus pädagogischen Gründen für diese „Lösung“ entschieden, damit wir tief in die Schwachstellen von CI/CD pipelines.
Anschließend haben wir gesehen, wie man dieses Szenario hacken kann, indem man Vergiftung des Artefakts. Wir nennen es Artefaktvergiftung, d. h. die Fähigkeit, die pipeline Logik durch Änderung einer pipeline Artefakt.
Was ist das Problem bei diesem Ansatz? Wir haben gesehen, dass das Problem entsteht, wenn ein Benutzer ein neues pipeline.
Wenn ein Benutzer einen PR öffnet, der eine neue pipeline, GitHub wird das ausführen pipeline (unter bestimmten Bedingungen, wie wir gesehen haben in der Post).
Der Benutzer kann dann eine neue pipeline mit dem gleichen Namen wie Build CI !! Ja, es ist überraschend, aber GitHub ermöglicht es Ihnen, zwei zu erstellen pipelines mit dem gleichen Namen!!
Wenn der Benutzer einen PR mit diesen Änderungen öffnet, das neue" pipeline wird ausgeführt (Hochladen eines vergifteten Artefakts) und das Deploy CI pipeline wird danach ausgeführt, was dazu führt, dass das „modifizierte“ Shell-Skript das „ursprüngliche“ Shell-Skript überschreibt, das sich im pipeline Arbeitsbereich. Diese „Lösung“ vermeidet also nicht die I-PPE-Schwachstelle (wie wir unten sehen können).
Was sind die Probleme? Zumindest gibt es ein paar Probleme:
- Erstens Wie kann sichergestellt werden, dass der Build-Prozess nicht manipuliert wurde? In diesem Szenario konnte der böswillige Benutzer den beabsichtigten Build-Prozess ändern, indem er seine pipeline um ein vergiftetes Artefakt zu erschaffen.
- Zweitens Wie können wir die Herkunft eines Artefakts feststellen?
Diese Fragen werfen uns in die Arme der Softwarebescheinigungen Domain!!
Softwarebescheinigungen
An Bescheinigung ist ein Stück von frustrierten Darstellen Nachweis einer VeranstaltungIn der realen Welt nennen wir diese Zertifizierungen.
Wenn ein Labor beispielsweise Ihr Blut untersucht, werden die Daten über den Test aufgezeichnet und zertifiziert. Die Ergebnisse des Bluttests sind überprüfbare und rückverfolgbar.
Wenn wir uns näher mit unserem IT-Bereich befassen, können Sie sich vorstellen, wie sich dieser Prozess beispielsweise auf einen Kompilierungsprozess übertragen ließe.
Informationen über die Umgebung und Tools des Kompilierungsservers, die Materialien (den Quellcode) und die Produkte/Artefakte (den Binärcode) wären Teil einer solchen Bescheinigung.
Um Glaubwürdigkeit zu gewährleisten, muss die Bescheinigung selbstverständlich von einem autorisierten Bescheiniger erstellt werden (authentifiziert und nicht abstreitbar).
Einige von Ihnen werden sich jetzt fragen: Was ist das Unterschied zwischen Unterschriften und Beglaubigungen?
Code-Signaturen und Bescheinigungen
Auf hohem Niveau, Stempel, Unterschrift wird mithilfe eines Schlüsselpaars und eines Artefakts erstellt. Das Schlüsselpaar besteht aus einem öffentlichen und einem privaten Schlüssel.
Der Benutzer signiert ein Artefakt mit dem privaten Schlüssel und andere können die Signatur dann mit dem öffentlichen Schlüssel überprüfen. Der private Schlüssel muss geheim gehalten werden, der öffentliche Schlüssel wird jedoch weit verbreitet.
Signaturen können verwendet werden um zu beweisen, dass der Inhaber des privaten Schlüssels den privaten Schlüssel zum Signieren des Artefakts verwendet hat.
Unterschriften nicht beweisen
- Die des Benutzers Absicht das Artefakt zu unterzeichnen (sie könnten hereingelegt worden sein) oder
- Die Absicht des Benutzers, spezifische Behauptung über das Artefakt
Mit Bescheinigungen, anstatt ein Artefakt direkt zu signieren, erstellen Benutzer eine Art Dokument zur Abwicklung, Integrierung, Speicherung und erfasst ihre Absicht hinter der Unterzeichnung des Artefakts und spezifische Ansprüche als Teil dieser Signatur vorgenommen werden.
In-toto-Bestätigungsrahmen
Das am häufigsten verwendete Framework ist das In-toto-Bestätigungsrahmen
- definiert eine standard Format für Bescheinigungen die Subjekte, die beschriebenen Artefakte, an authentifizierte Metadaten über das Artefakt binden
- bietet eine Reihe von vordefinierte Prädikate zur Kommunikation authentifizierter Metadaten innerhalb und über Software-Lieferketten hinweg
Lassen Sie uns etwas näher auf das Bescheinigungsformat eingehen.
An Bescheinigung ist eine digital signiertes Dokument das enthält Aussagen.
Die Erklärung ist die mittlere Schicht der Bescheinigung und bindet sie an eine bestimmte Betreff und eindeutige Identifizierung der Typen der Prädikat:
- Betreff: zu kryptografisch sicherer Verweis auf das Artefakt (normalerweise über einen Hash) und
- Prädikate: eine Reihe spezifischer aus aller Welt zu diesem Artefakt wird als Aussage bezeichnet. Diese Aussagen können verwendet werden, um alles auszudrücken (und später zu beweisen), was Sie sich vorstellen können! Sie können manuelle Genehmigungen, die Herkunft des Artefakts, automatisierte Testergebnisse, einen Prüfpfad oder mehr darstellen!
Wenn diese Erklärung kryptografisch signiert ist, dann wird sie als Bescheinigung
Auf diese Weise erstellt Alice beispielsweise eine Erklärung zu einem Artefakt und signiert diese mit ihrem privaten Schlüssel, wodurch eine Bescheinigung erstellt wird.
- Bob kann dann Überprüfen Sie die Signatur in dieser Bescheinigung, die ihm erlaubt den Behauptungen zu vertrauen innen.
Bob kann diese Ansprüche dann verwenden zu entscheiden ob die Verwendung dieses Artefakts erlaubt sein soll oder nicht.
Könnten Bescheinigungen helfen, das Problem der Artefaktvergiftung zu lösen?
Kehren wir nach dieser Einführung in Bescheinigungen zu unserem Problem zurück. Wie können uns Atteste dabei helfen, unser Problem zu lösen, also eine Artefaktvergiftung zu vermeiden?
Der böswillige Benutzer konnte ein Artefakt erstellen, indem er den „offiziellen“ Mechanismus umging, d. h. indem er seine pipeline um das Artefakt zu erzeugen.
Es wäre großartig, wenn wir beweisen könnten, dass die heruntergeladenen Artefakte mit den offiziellen pipelines. Dies ist nur ein Beispiel für das, was wir als „Manipulationspunkte“ bezeichnen könnten, aber es könnte noch viele andere geben.
Wie Sie im obigen Bild sehen können, gibt es viele Manipulationspunkte. Auf diese Weise kann der Verbraucher pipeline (Test CI in unserem Beispiel) muss die Integrität des Build-Prozesses sowie Integrität des Artefakts selbst.
In unserem Beispiel wurde das vergiftete Artefakt durch die Einführung eines neuen (vergifteten) pipeline das den Build-Prozess manipuliert. Der böswillige Benutzer hätte jedoch Folgendes tun können:
- den Code nach dem Auschecken aus dem SCM um eine bösartige Binärdatei zu generieren
- Ersetzen Sie die richtige Binärdatei, die durch die Kompilierung erstellt wurde, durch eine beliebige andere bösartige Binärdatei.
- das Artefaktregister kompromittieren und ein auf andere Weise erstelltes vergiftetes Artefakt hochladen
- usw.
Wie Sie sehen, kann es mehrere Manipulationspunkte geben.
Was ist hier wichtig? Natürlich, um all diese „Manipulationspunkte“ zu schützen. Aber am Ende ist das Wichtigste dass der „Verbraucher“ des Artefakts die Integrität des Artefakts beurteilen und entscheiden kann, ob er damit weitermacht oder nicht.
Wir können die Integrität eines Artefakts beurteilen In zwei Wegen.
Eine Möglichkeit ist die Bewertung der Herkunft des Artefakts.
Durch die Generierung einer Herkunftsnachweis, wir stellen nützliche Metadaten (ordnungsgemäß authentifiziert und nicht abstreitbar) über das Artefakt bereit. In den folgenden Beispielen verwenden wir Xygeni SALZ (Software Attestations Layer for Trust), die Komponente zum Generieren, Registrieren und Überprüfen von Software-Attestierungen.
- 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
Im obigen Code können Sie sehen, dass es einen Schritt gibt, der die War-Datei erstellt, und einen zweiten Schritt, der die Herkunftsnachweis. Um dies zu tun, pipeline verwendet den privaten Schlüssel und schließt auch den öffentlichen Schlüssel in die Bescheinigung ein.
Hinter den Kulissen, Xygeni's Salz Befehl speichert die Bescheinigung in einem Hauptbuch (auch bekannt als Bescheinigungsregister, Rekord in unserem Fall, aber Sie können jede andere verwenden). Das hat der Verbraucher pipeline kann Xygenis Verifizierungs-Engine um die Herkunft des Artefakts zu überprüfen und die Integrität des Artefakts zu beurteilen.
- 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
Im Rahmen des Überprüfungsprozesses wird Folgendes beurteilt:
- Die Artefakt sha256sum ist gültig (d. h. es gibt eine Bescheinigung über dieses „Thema“) und
- Die Die Beglaubigung ist ordnungsgemäß authentifiziert (es wurde unter Verwendung des entsprechenden privaten Schlüssels generiert)
Durch diesen Überprüfungsprozess kann dann festgestellt werden, ob sowohl das Artefakt als auch die Bescheinigung gültig sind.
Aber wie Sie sich erinnern, wurde das Artefakt in unserem Fall von einem „böswilligen“ pipeline (also nicht das Original durch eine modifizierte pipeline). Dann müssen wir einen weiteren Aspekt prüfen: das Artefakt wurde vom „Original“ erzeugt pipeline, kein anderes.
Fügen Sie dazu einfach eine einfache Zeile ein, um die Bedingung zu überprüfen, zum Beispiel:
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
Diese zusätzliche Prüfung schlägt fehl, wenn das Artefakt nicht von unserem „Safe“ generiert wurde. pipeline.
Wenn das Artefakt von unserem ursprünglichen pipeline (cicd_top10_3_salt/.github/workflows/build.yml), der grep-Befehl wird erfolgreich sein, andernfalls wird er fehlschlagen und die pipeline und alle weiteren Schritte abzubrechen.
Der Bauarbeiter" pipeline ist nur einer der zu prüfenden Manipulationspunkte, aber wie bereits erwähnt, gibt es noch einige andere Manipulationspunkte, die wir prüfen sollten.
Zum Beispiel, Was passiert, wenn der Quellcode nach dem Auschecken des Repository und vor dem Build-Befehl manipuliert wurde? In diesem Fall ist der zu erstellende Code nicht derselbe wie der im SCM.
Die Überprüfung dieser Manipulationsstelle ist ganz einfach: Man prüft einfach bei jedem Schritt die Hashes des Materials.
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[])
Schlussfolgerungen
Zusammenfassend lässt sich sagen, Softwarebescheinigung ist eine Behauptung über ein Stück Software, d. h. eine authentifizierte Aussage (Metadaten) über ein Softwareartefakt oder eine Sammlung von Softwareartefakten.
Softwarebescheinigungen sind eine Verallgemeinerung der Rohartefakt-/Codesignatur. Die Bescheinigung ist ein signiertes Dokument (in einem bestimmten Format, normalerweise basierend auf JSON), das Metadaten mit einem Artefakt verknüpft. Sie stellen Beweise dar, die Eingaben (Materialien) und Ausgaben (erstellte Artefakte) bei jedem Build-Schritt verknüpfen.
Bescheinigungen liefern eine überprüfbare Aufzeichnung der zum Erstellen der endgültigen Softwareartefakte durchgeführten Schritte, einschließlich der Eingabematerialien für jeden Schritt und der ausgeführten Build-Befehle.
Zusammenfassend lässt sich sagen, dass Software-Attestation ein großartiger Mechanismus zur Überprüfung vieler verschiedener Integritätsaspekte unseres Build-Prozesses sind.
Die Serie beendet? Keine Sorge! Springen Sie einfach zurück zu 'Vergiftet Pipeline Ausführung (PSA)' oder jeden anderen Beitrag, der Ihr Interesse erneut weckt!
Bleiben Sie dran, wir werden tiefer in Software-Bescheinigungen eintauchen und build security in weiteren Blogbeiträgen.
