Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) pipelines sind die Grundlage jeder Softwareorganisation, die Software auf „moderne“ Weise erstellt. Automatisierung bietet große Vorteile, aber die meisten Entwickler übersehen die damit verbundene Verantwortung.
Entwickler:in / Unternehmen: Ja, wir nehmen CI/CD Sicherheitdienst ernst und haben eine starke Kontrolle über Code-Betreuer, überprüfen commits vor Fusionen; Arbeitsplätze und pipelines werden von leitenden Mitarbeitern gepflegt, sie kümmern sich darum, dass keine Geheimnisse in die pipelines. Und das Tool wurde von Personal installiert, das sich auskennt. Was kann da schiefgehen?
Lieber Entwickler, CI/CD Systeme sind komplex. Ihre große Angriffsfläche lockt böswillige Akteure an. Seien Sie vorsichtig und nicht übermütig.
Die Standardkonfiguration wird manchmal beibehalten und wird zum besten Freund von Hackern. Kritische Fehler können vorhanden sein in CI/CD pipeline Quellen, in der Konfiguration des Systems oder um den Prozess und Kontext der pipeline und wie es ausgelöst wird.
In diesem Beitrag versetzen wir uns in die Lage der Bösewichter. Stellen Sie sich vor, wir lesen die Überlegungen von M3M3N70 (Memento Mori?) und Sumpfwut irgendwo im Dark Web, wahrscheinlich in einer nicht-westlichen Sprache, aber übersehen Sie nie, dass das Böse weltweit verbreitet ist.
In der guten alten Zeit war es so einfach…
M3M3N70: Zurück in die guten alten Zeiten, als unser Geschäft noch sooo einfach war … Zero-Day-Explosionen waren ein Kinderspiel, Apps waren völlig offen und wiesen Schwachstellen auf, die leicht auszunutzen waren, und wir konnten uns im Handumdrehen seitwärts bewegen.
Sumpfwut: Verdammt noch mal! Da draußen gibt es noch einige Dummköpfe, aber die Dinge haben sich geändert. Die Großen haben viel Zweifel an diesem AppSec-Scheiß.
M3M3N70: Ja. Aber die neuen Narren sind die Entwickler. Für uns war es einfacher, die Tools dieser Leute zu nutzen. Insbesondere die CI ist eine Goldgrube! Cloud-Zugriffstoken, SCM Anmeldeinformationen, Passwörter für Produktionsdatenbanken, private SSH-Schlüssel, Anmeldeinformationen anderer CI-Benutzer … Der Sprung von den langweiligen Entwicklungssachen zum Wesentlichen war ziemlich trivial.
Automatisierung für die Erstellung, das Testen und die Bereitstellung von Software mit einem CI/CD Das Tool erfordert häufig die schrittweise Weitergabe von Geheimnissen an Befehle. Und oft werden diese weitergegeben, mit berüchtigten Folgen.
Pipelines brauchen Geheimnisse, die manchmal durchsickern
M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.
Vielleicht war es die gute alte Zeit, in der Git-Historie eine .env Datei (der Entwickler hat vergessen, sie hinzuzufügen .gitignore):
AWS_ACCESS_KEY_ID=AKIA...AWS_SECRET_ACCESS_KEY=wJalrXUtn...AWS_REGION=us-east-1APP_FOLDER=...S3BUCKET=...
welches in einem GitHub-Workflow verwendet wurde .github/deploy.yaml das ungefähr Folgendes enthielt:
jobs:
build:
name: Automated build and deployment into AWS
runs-on: ubuntu-22.04
steps:
# Load environment from .env file
- id: dotenv
uses: falti/dotenv-action@v1.0.2
- name: Configure AWS Credentials
uses:
with:
args: --acl public-read --follow-symlinks --delete
aws-access-key-id: $
aws-secret-access-key: $
aws-region: $
# ... build steps skipped ...
- name: Upload compiled code for deployment
working-directory: $/packaged_app
run: aws s3 cp my-app.zip s3://$
- name: Deploy the app
run: aws deploy create-deployment ...
M3M3N70: wow! Diese AWS-Schlüssel haben funktioniert! Wir haben zuerst eine harmlose Änderung in der App getestet und dann den Trick hinzugefügt, da die Jungs nichts davon zu merken schienen. Bingo! Was für eine Kampagne …
Der Angreifer nutzte einfach die AWS-Schlüssel, um eine modifizierte Anwendung mit Malware hochzuladen und führte dann den Bereitstellungsbefehl mit diesen Anmeldeinformationen aus. Die durchgesickerten Geheimnisse sowie die in der pipeline„Was für eine Kampagne!“ bedeutet wahrscheinlich, dass Memento bei dem armen Opfer großes Unheil angerichtet hat.
Was Memento uns hier sagt, ist, dass Sie, sobald ein geheimes Leck aufgetreten ist, wie bei AWS-Zugriffsschlüsseln im Beispiel, das Geheimnis widerrufen müssen (die oben genannten Schlüssel rotieren). sofortEs gibt immer eine Belichtungsfenster zwischen den undichten commit und die geheime Ungültigkeitserklärung; Das Umschreiben des Git-Verlaufs ist schwierig (selbst der härteste autoritäre Staat hat versucht, die Geschichte umzuschreiben, jedoch ohne Erfolg) und wahrscheinlich wirkungslos (unsere Freunde haben vielleicht vor dem Archiv mit dem geheimen Leck geklont commit). Rotieren Sie die Schlüssel sofort und beten Sie, während Sie während des Expositionsfensters die Aktivitätsprotokolle für das Zielkonto lesen!
Wahrscheinlich sollten Organisationen Verbot der Verwendung von Langzeitgeheimnissen in CI/CD pipelinesund ersetzen Sie sie durch temporäre Anmeldeinformationen. Im vorherigen Beispiel mit AWS-Schlüsseln in GitHub-Aktionen ist es sicherer, einen OpenID Connect (OIDC)-Anbieter um kurzlebige Anmeldeinformationen zu erhalten, die für Aktionen erforderlich sind.
Sumpfwut: Sie hatten so viel Glück! Das Durchsickern von Skripten mit fest codierten Schlüsseln war früher gängige Praxis, sogar bei öffentlich zugänglichen S3-Buckets. Sie mussten nur die Objekte im Bucket durchsuchen und ein wenig greppen, um interessante Dinge zu finden.
Manchmal war der für die Bereitstellung verwendete Bereich (in diesem Beispiel ein AWS S3-Bucket) aufgrund eines Konfigurationsfehlers (der unentdeckt blieb) für den Lesezugriff durch Außenstehende geöffnet. Was Sumpfwut verwendet wurde so etwas wie das hier:
aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
aws s3 cp s3://<bucket_name>/FNAME - | \
grep '<regex_pattern>'"
Der Bucket wurde wahrscheinlich in einer Bereitstellungsvorlage erstellt, die automatisch auf Sicherheitslücken überprüft werden könnte.
Die Standardkonfiguration des Tools war für uns ein Spielzeug
Um konkrete Beispiele zu geben, sprechen wir über Jenkins, eines der beliebtesten CI-Tools.
Sumpfwut: Erinnern Sie sich an das Kontrollkästchen „Sicherheit aktivieren“ in Jenkins und wie viele Organisationen es aus Bequemlichkeitsgründen nicht aktiviert haben? Und diese „Jeder kann alles tun” Berechtigungskombinationen als Standard? Und diese lästigen Jenkins-Plugins, wie das GitHub OAuth-Plugin? Der Typ, der es konfiguriert hat, hat sowohl „Allen authentifizierten Benutzern Leseberechtigungen erteilen“ als auch „Berechtigungen für GitHub-Repository verwenden“ ausgewählt und uns so Zugriff auf alle seine Projekte gewährt.
(Entschuldigung, Jenkins, dass ich dich als Beispiel anführe 😉
Halten Sie sich an Sicherheitsprinzipien (oder sogar an solche, die Sie nicht kennen). Eines davon ist die Standardmäßig sicher Prinzip: Kontrollen sollten standardmäßig auf die sichersten Einstellungen eingestellt sein. Sicherheit sollte integriert sein in CI/CD Werkzeuge und pipelines von Grund auf neu konzipiert und nicht erst nachträglich hinzugefügt. Benutzerfreundlichkeit und Komfort stehen jedoch häufig im Widerspruch zur Sicherheit.
Im Fall von Jenkins ist die integrierte Authentifizierung zu fehleranfällig: Verwenden Sie niemals die integrierten Authentifizierungsmechanismen in Jenkins. Entscheiden Sie sich besser für einen Mechanismus von Drittanbietern (SAML, LDAP, Google …) mit einem Plugin für eine rollenbasierte Autorisierungsstrategie („RBAC“). Und seien Sie äußerst vorsichtig mit dem admin -Konto.
Achten Sie darauf, wie Job und pipeline Dateien in Jenkins behandelt werden. Das gleiche mit Konfiguration-als-Code-Plugin und seine Konfigurationsdateien, die für die Jenkins-Konfiguration gelten.
Umstellung von selbstgehosteten CI/CD Systeme auf Cloud-basierte SaaS-Systeme eliminiert einige potenzielle Risiken, die eine laterale Bewegung innerhalb des Organisationsnetzwerks ermöglichen, fügt aber andere hinzu, wie die Notwendigkeit, externe Verbindungen zwischen bestehenden internen Systemen und den externalisierten CI/CD Werkzeug.
Organisationen solltencise Sorgfalt bei der Härtung der CI/CD System, beginnend mit den restriktivsten Einstellungen und schrittweise mit den minimal erforderlichen Berechtigungen für die pipeline Schritte.
Konfigurieren der Sicherheit in CI/CD Tools können eine komplexe Aufgabe sein. Viele verfügen über Plugins oder Erweiterungen, die die meisten Schwachstellen aufweisen und aktualisiert werden müssen.
Sicherheitsscanner für Fehlkonfigurationen solcher komplexen Tools oder Benchmarks können hilfreich sein.
Einfügen von Code in pipeline Befehle für Spaß und Profit
M3M3N70: Haben Sie schon einmal Untrusted Code Checkouts verwendet, bei denen Aktionen und Skripte anfällig für Befehlsinjektion sind?
Dieser Abschnitt zeigt, dass die pipeline selbst könnte Codefehler aufweisen, die es böswilligen Akteuren ermöglichen, willkürliche Codeausführung in das pipeline ohne Änderung der pipeline Quelle selbst. Zum Beispiel mit einem PR
Ein erstes Beispiel für eine unglücklicher GitHub-Workflow:
# INSECURE. Provided as an example only.
on:
pull_request_target #1
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: $ #2
- uses: actions/setup-node@v1
- run: |
npm install #3
npm build
# ... more steps ...
Kombination pull_request_target Workflow-Trigger mit einem expliziten Checkout eines nicht vertrauenswürdigen PR ist eine gefährliche Praxis, die zu einer Kompromittierung des Repository führen kann. Im Beispiel die unglückliche Kombination aus:
pull_request_targetEreignis, das standardmäßig Schreibberechtigung für das Ziel-Repository und die Ziel-Repository-Geheimnisse hat, auch von externen Forks, und im Kontext des Ziel-Repositorys des PR ausgeführt wird,- Checken Sie den PR-Code aus dem Quell-, nicht vertrauenswürdigen Repo,
- ein Skript auslösen, das PR-gesteuerte Inhalte bearbeitet, wie im Fall von
npm installund - keine Bedingung für die Auslösung verwenden
pull_request_targetDas Ereignis wird nur ausgeführt, wenn dem PR die Bezeichnung „Dieser PR wurde überprüft“ zugewiesen ist (externe Benutzer können dem PR keine Bezeichnungen zuweisen).
Ein zweites Beispiel ist nicht vertrauenswürdiger Input (aus einem Problem, Kommentar oder pull request) als Quelle für Argumente, die an einen pipeline Befehl über Ausdrücke. Dies ist die pipeline Version der OS-Befehlsinjektionsschwachstelle.
- name: Check title
run: |
title="$"
if [[ ! $title =~ ^.*:\ .*$ ]]; then
echo "Bad issue title"
exit 1
fi
Der Run-Vorgang generiert ein temporäres Shell-Skript basierend auf der Vorlage mit $ ersetzt, wodurch es anfällig für Shell-Befehlsinjektion wird. Ein Angreifer mit einem gefälschten GitHub-Konto könnte ein Problem mit einem Titel verursachen a"; bad_code_goes_here;#, und bumm!
Sumpfwut: Oh, diese Typen haben die Tür für eine Befehlsinjektion geöffnet, indem sie einfach ein Problem eröffnet haben …
Es gab Schwachstellen bei der Codeausführung in GitHub-Aktionen, wie Gajira-Kommentar, jetzt behoben. Bitte lesen Sie „Nicht vertrauenswürdige Eingaben in GitHub-Workflows“ für weitere Informationen.
Die Moral der Geschichte: Testen und erstellen Sie niemals PRs aus nicht vertrauenswürdigen Quellen, ohne den PR vorher zu überprüfen. „Nicht vertrauenswürdig“ könnte hier, sofern keine drakonische Herkunftsauthentifizierung vorliegt, jedes potenziell entführte Entwicklerkonto bedeuten.
Hier kommt es zu einer unbeabsichtigten Verbreitung von Malware!
Kontinuierliche Bereitstellung ist der Höhepunkt der Automatisierung, aber dieser Höhepunkt könnte durch das Fehlen geeigneter Genehmigungskontrollen auf der pipeline Durchfluss.
Die Risiken einer vollständig automatisierten Bereitstellung aus der Quelle commit zu Produktionssystemen besteht die Möglichkeit, dass Schadcode in Produktionsumgebungen eingesetzt wird, ohne erkannt zu werden, und dass Fehler im Einsatzprozess zu Störungen oder Ausfällen führen können.
Um diese Risiken zu minimieren, wird Organisationen häufig empfohlen, einen „harten Bruch“ in ihrem Bereitstellungsprozess einzuführen, was erfordert menschliche Zustimmung bevor Releases in Endumgebungen bereitgestellt werden.
Sie schließen die Türen
Sumpfwut: Diese fröhlichen Standardpasswörter in CI/CD Werkzeuge werden abgewischt. Zugriff auf die
/var/lib/jenkins/secrets/initialAdminPasswordist jetzt ein toter Weg. Viele Tools bieten jetzt die 2FA an, die durch Covid populär geworden ist, und selbst der faulste Code-Affe da draußen verwendet sie!M3M3N70: Wir bekämpfen 2FA, aber es ist nicht so einfach. Es ist schwer, diese Typen zu fangen, „Scatter Swine“ hat mit Twilio. Mit WebAuthn-Schlüsseln ist es viel schwieriger. Zumindest können wir versuchen, Cookies stehlen, um MFA zu umgehen, muss aber in die Entwicklerbox einbrechen.
Die Multi-Faktor-Authentifizierung ist ein guter Schritt in die richtige Richtung, um das Risiko von Lecks bei Authentifizierungsgeheimnissen zu begrenzen. Die meisten modernen DevOps-Tools unterstützen MFA. Und Authentifizierungsschlüssel unter WebAuthn / U2F (siehe FIDO2-Projekt) sind bei richtiger Verwaltung möglicherweise die beste Option für MFA in DevOps.
Sumpfwut: Die DevOps-Leute wachen auf. Sie haben das verdammte „Least Privilege“-Prinzip im Blut. Und sie sind keine Code-Affen mehr. Wir werden jetzt von Prüfern auf frischer Tat ertappt.
In der Tat pipelines sind jetzt etwas robuster als noch vor ein paar Jahren, da schwache Aktionen und Skripte entfernt wurden und zusätzliche Sicherheitstests durchgeführt wurden, die sogar unsere im Verborgenen versteckten Dropper erkannten commits und Pakete, die wir entführt haben.
Frage an den Leser: Ist der Prozess, Software aus Quellen zu erstellen und in die Produktion zu bringen, ein riskantes Geschäft? Können Sie sich DevOps in der Phase vorstellen, gute alte Zeiten für die Bösen?
Endgültige Empfehlungen
Womit soll ich anfangen? CI/CD pipelineS?
Die erste Empfehlung ist einfach: Sorgfältig Überprüfen pipelines (sie sind kritischem Ressourcen) für Sicherheitsprobleme. Überprüfungen sind kostspielig, aber notwendig und sollten ordnungsgemäß durchgeführt werden. Prüfer sollten wissen, worauf sie achten müssen. Jeder Schritt muss auf Fehler überprüft werden.
Vielleicht könnte eine Kombination aus Expertengutachtern und automatisierten Schadcode-Scannern hilfreich sein.
Die zweite Empfehlung besteht darin, schulen Sie Entwickler, die schreiben pipelines und pflegen Sie sie auf Sicherheit. Dinge, die man beachten muss:
- Erfahren Sie, wie Sie die Authentifizierung bei internen und Cloud-Diensten richtig handhaben und dabei den Aufwand beim Umgang mit langfristigen Anmeldeinformationen vermeiden.
- So begrenzen Sie pipelines auf die genauen Ressourcen, auf die es Zugriff benötigt. Das Prinzip der geringsten Privilegien kommt wieder zum Tragen.
- So schreiben Sie die Schritte zum Erstellen pipelines reproduzierbar, wie Versionsfixierung und Vermeidung von Befehlsinjektionsschwachstellen.
- Wie man Bereitstellungen aus der Sicherheitsperspektive genehmigt (es gibt andere!): welche Sicherheit standards sollten abgeglichen werden und wie entsprechende Checks/Gates in der pipelines.
Eine dritte Empfehlung besteht darin, Konfigurieren Sie die CI/CD System mit der gebotenen Sorgfalt. Starke Authentifizierung, keine Standardkennwörter oder unsicheren Einstellungen, minimale Berechtigungen … Achten Sie auf Schwachstellen in installierten Plugins und Erweiterungen. Dies könnte der Schwerpunkt der folgenden Beiträge sein, bitte bleiben Sie dran.
Die vierte Empfehlung besteht darin, nutzen Sie die CI/CD pipelines für Sicherheitsautomatisierung. Quellcodeanalyse (SAST), Quellenzusammensetzungsanalyse (SCA), Scannen von Geheimnissen, Anti-Malware-Tools, Container-Sicherheitsscanner oder automatisierte Laufzeitdetektoren (DAST und Malware) können routinemäßig auf dem pipelineUnd Ihre Organisation kann durchsetzen standards über die Berichterstattung über Sicherheitsscans in CI/CD.
Denken Sie daran, dass diese Tools die Expertenbewertung nicht aus der Gleichung entfernen, da Sie sonst ein falsches Sicherheitsgefühl bekommen könnten.
Wenn Sie mit den Top-Ten von OWASP vertraut sind, ist ein schönes aktuelles Projekt das OWASP Top 10 CI/CD Sicherheitsrisiko.
Haftungsausschlusshinweis
(1) Die Beispiele in diesem Beitrag verwenden GitHub als SCM, AWS als Cloud-Anbieter und GitHub Actions oder Jenkins als CI/CD Werkzeug. Sie sind nicht schwächer/sicherer als ihre Alternativen. Keine böse Absicht! Diese Werkzeuge sind leistungsstark und müssen entsprechend eingesetzt werden.
(2) M3M3N70 , Sumpfwut sind fiktive Charaktere. Jede Ähnlichkeit mit lebenden oder verstorbenen Personen oder Gruppen ist rein zufällig … oder etwa nicht?
Um mehr zu lesen
- Haymore, A. et al. „10 Geschichten aus der Praxis, wie wir Kompromisse eingegangen sind CI/CD pipelines ”. NCC Group, Januar 2022.
configure-aws-credentialsGitHub-Aktion , Konfigurieren von OpenID Connect in Amazon Web Services für Einzelheiten zum Ausführen von AWS-Befehlen für die Bereitstellung in GitHub-Workflows.- Lobacevski J. „So schützen Sie Ihre GitHub-Aktionen und -Workflows. Teil 1: Verhindern von PWN-Anfragen“. GitLab Security Lab, Dezember 2020.
- Lobacevski J. „So schützen Sie Ihre GitHub-Aktionen und -Workflows – Teil 2: Nicht vertrauenswürdige Eingaben“. GitLab Security Lab, Januar 2021.
- OWASP. „OWASP Top 10 CI/CD Sicherheitsrisiken““. Jul 2022.
- Saltzer J. & Schroeder M. „Der Schutz von Informationen in Computersystemen“. April 1975. Die Sicherheitsprinzipien haben sich mit der Technologie weiterentwickelt, aber 47 Jahre später sind die meisten S&S-Ideen noch immer gültig.
- Britisches NCSC. „Sichern Sie den Aufbau und die Bereitstellung pipeline" . UK National CyberSecurity Center, Februar 2019.
