Open Friday #95 Vortrag: Supply-Chain-Angriffe

Im Zuge meiner Open-Friday-Vortragsreihe zur sichereren Softwareentwicklung habe ich auf den Open Friday #95 am 29. April 2022 Supply-Chain-Angriffe beleuchtet. Da dies ein wichtiges Thema ist, möchte ich es hiermit einem breiteren Publikum zur Verfügung stellen. Analog zum Vortrag werde ich in diesem Blogbeitrag die nachfolgenden Themen behandeln, die ausführlichen Beispiele aber weglassen. Bei Rückfragen stehe ich gerne zur Verfügung.

Was sind Supply-Chain-Angriffe?
Welche Arten von Supply-Chain-Angriffen gibt es?
Wie kann man sich schützen?

IT Security Know-How beim Open Friday — Abb. 1: CI Open Friday #95 in Gather Town

Was sind Supply-Chain-Angriffe

Bei einem Supply-Chain-Angriff nutzt der Angreifer ein Ziel in der Lieferkette (Supply Chain), um sein eigentliches Ziel zu erreichen. Dies bietet einige Vorteile, da, nicht zuletzt durch ein vermeintliches Vertrauensverhältnis zwischen den Partnern in der Lieferkette, die Zugriffe innerhalb der Supply Chain oft weniger stark abgesichert sind. Dieses Angriffsmuster lässt sich auf die moderne Softwareentwicklung übertragen: Eine Anwendung nutzt heute viele Fremdbibliotheken. Die Supply Chain wäre in diesem Fall die Abhängigkeitskette an Fremdbibliotheken, die bei einer Kompromittierung ebenfalls ein Sicherheitsrisiko darstellen.

Die Ziele der Angreifer sind sehr unterschiedlich aber sie lassen sich gut in die beiden nachfolgenden Kategorien gruppieren:

Malware (zum Beispiel Trojaner, BackDoors, KryptoMiner) verbreiten
Daten (zum Beispiel Kreditkarten Informationen, Zugangsdaten) abgreifen

Arten von Supply-Chain-Angriffen

In diesem Abschnitt werde ich die möglichen Angriffsarten kurz beschreiben. Wichtig ist hierbei, dass sie meist in Kombination auftreten. Die folgende Klassifizierung ist daher vor allem als Hilfsmittel gedacht, um die Komplexität zu verdeutlichen.

Holger Weber

Security Consultant

Upstream-Server-Kompromittierung

Der Angreifer greift einen Upstream Server oder ein Repository an. Das Ziel ist es dann, diesen Server oder das Repository zu nutzen, um Schadsoftware an nachgelagerte Nutzer, Server, etc. zu verteilen. Diese Methode wird oft genutzt, wenn es um die Verteilung von Schadsoftware geht, weshalb Upstream Server und Repository immer kritisch betrachtet werden sollten [13]. Zwei bekannte Angriffe sind der Codecov [1, 2, 3] und UAParser.js [4, 5].

Mögliche Arten, den Dependency Tree anzugreifen

In der nachfolgenden Abbildung sind verschieden Möglichkeiten dargestellt, wie man den Dependency Tree angreifen kann. Hierbei unterscheidet man, ob man ein neues Package erstellt (beispielsweise um mittels Typosquatting jemanden zu verleiten, dieses Package anstelle des Originals zu nutzen), oder ob versucht wird, ein bestehendes Package zu infizieren. Alle Varianten ausführlich zu beschreiben, würde den Rahmen dieses Blogbeitrages sprengen, daher behandle ich im nächsten Abschnitt nur die Dependency Confusion genauer.

Angriffe auf den Dependency Tree — Abb.2: Angriffe auf den Dependeny Tree (angelehnt an Abb. von [6])

Dependency-Confusion-Angriffe

Bei Dependency-Confusion-Angriffen (auch bekannt als Namespace-Konfusion) wird eine private interne Abhängigkeit aus einem öffentlichen anstatt aus dem internen Repository nachgeladen. Ein Angreifer registriert die gleichnamige Abhängigkeit in einem öffentliche Repository und stellt eine höhere Version bereit, als zum Beispiel in der package.json Datei hinterlegt ist. Wenn die Version dann nicht festgeschrieben ist, sondern auch neuere Versionen geladen werden können (zum Beispiel ^1.0.0), kann die Version aus dem öffentlichen Repository gezogen werden. Alex Birsan demonstrierte die Möglichkeit bei PyPI, npm und RubyGems und es gelang ihm, 35 große Tech-Unternehmen (z.B. PayPal) anzugreifen [6]. Nach meinem Vortrag (Mai 2022) ist bekannt geworden, dass die deutsche Pen-Test-Firma CodeWhite in NPM mehrere komprimierte Bibliotheken für Pen-Tests bei großen deutschen Firmen abgelegt hat [7, 8].

Midstream-Server-Kompromittierung

Bei der Midstream-Server-Kompromittierung versucht der Angreifer, eine Software-Upgrade-Funktionalität oder die CI/CD Pipeline zu manipulieren [13]. Dabei kommt es dem Angreifer zugute, dass Links zu Content Delivery Network (CDN) Adressen oft nicht als verdächtig eingestuft werden. Dies hat sich zum Beispiel auch der Angriff auf den weit verbreiten Passwort-Manager Passwordstate von Clickstudios zu Nutze gemacht. Angreifer haben hier die In-Place-Upgrade-Funktionalität manipuliert, um eine bösartige DLL-Datei zu verbreiten. Hierzu haben sie Benutzerhandbücher, Hilfedateien und Powershell-Erstellungsskripte so geändert, das Links auf einen bösartigen CDN-Server verwiesen haben [9, 10].

Magecard

Der Name Magecard kommt von einem Konsortium, bestehend aus mindestens zwölf cyberkriminellen Organisationen, welches bisher mindestens zwei Millionen Webseiten angegriffen hat. Die Anzahl der Angriffe ist in der COVID Pandemie um mehr als 20 Prozent gestiegen. Magecart-Angriffe sind clientseitige Angriffe mittels JavaScript. Ziel sind sensible Daten, zum Beispiel Kreditkarteninformationen. Nicht alle Magecart-Angriffe sind Supply-Chain-Angriffe, wenn aber Supply-Chain-Angriffe genutzt werden, dann meistens Upstream- oder Midstream-Server-Kompromittierungen. Einer der bekanntesten Magecard-Angriffe ist Cardbleed (kein Supply-Chain-Angriff), bei dem über 2800 Webseiten mittels einer ZeroDay-Lücke angegriffen wurden, die eine alte Version der Magento Shop-Software nutzten, welche out of Support war. Hierbei wurde Malware über das Adminpanel installiert [11, 12].

gestohlene Zertifikate

Wenn ein Angreifer Zugriff auf die privaten Schlüssel von Zertifikaten erlangt, dann kann er das Zertifikat (sofern es sich um ein SSL-/TLS- Zertifikat handelt) für Man-in-the-Middle-Angriffe nutzen. Wird das Zertifikat genutzt, um Artefakte zu signieren, dann kann der Angreifer vertrauenswürdige Artefakte erzeugen und somit Malware als legitime Software oder offizielles Update tarnen [13]. Es gibt bisher keine bekannten Angriffe, aber es wurde ein HashiCorp PGP-Schlüssel im Rahmen des Codecov Angriffes preisgegeben. Es gibt bisher jedoch keine Hinweise, dass der PGP-Schlüssel zum Signieren missbraucht wurde [13, 14, 15, 16].

Angriffe auf CI/CD Pipelines

Wenn ein Angreifer Zugriff auf die CI/CD Pipeline erlangt, kann er zum Beispiel mit Malware infizierte Artefakte erzeugen oder Umgebungsvariablen extrahieren und versenden [13]. Die folgend abgebildete Threat Matrix für CI/CD Pipelines hat Hiroki Suezawa auf seinem Github Repository threat-matrix-cicd bereitgestellt. In der Matrix sind die verschiedenen Bedrohungen gut und übersichtlich dargestellt. Im Repository schlägt Hiroki Suezawa auch für jede Bedrohung Mitigierungsmöglichkeiten vor [17]. Bekannte Angriffe auf die CI/CD Pipeline sind Codecov [14, 15, 16] und Solarwinds [18, 19, 20].

Initial Access	Execution	Persistance	Privilege Escalation	Defense Evasion	Credential Access	Lateral Movement	Exfiltration	Impact
Supply Chain Compromise on CI/CD	Modify CI/CD Configuration	Compromise CI/CD Server	Get credential for Deployment (CD) on CI stage	Add Approver using Admin permission	Dumping Env Variables in CI/CD	Exploitation of Remote Services	Exfiltrate data in Production environment	Denial of Services
Valid Account of Git Repository (Personal, Token, SSH Key, Login password, Browser Cookie)	Inject code to IaC configuration	Implant CI/CD runner images	Privileged Escalation and compromise other CI/CD pipeline	Bypass Review	Access to Cloud Metadata	(Monorepo) Get credential of different folder’s context	Clone Git Repositories
Valid Account of CI/CD Service (Personal Token, Login password, Browser Cookie)	Inject code to source code	Modify CI/CD Configuration		Access to Secret Manager from CI/CD kicked by different repository	Read credentials file	Privileged Escalation and compromise other CI/CD pipeline
Valid Admin account of Server hosting Git Repository	Supply Chain Compromise on CI/CD	Inject cote to IaC configuration		Modify Caches of CI/CD	Get credential from CI/CD Admin Console
	Inject bad dependency	Inject code to source code		Implant CI/CD runner images
	SSH to CI/CD pipelines	Inject bad dependency
	Modify the configuration of Production environment
	Deply modified applications or server images to production environment

Abb. 3: CI/CD Pipelines Threat Matrix [17]

Social Engineering

Beim Social Engineering versucht ein Angreifer, Personen zwischenmenschlich zu beeinflussen. Ziel ist es entweder, hilfreiche Informationen zum Erreichen des Angriffsziels zu erlangen, oder aber die Person zu animieren, eine mit Malware infizierte Datei oder Webseite zu öffnen. Häufig geht es darum, Zugriff auf die Systeme zu bekommen, ob nun via Malware oder über Zugangsdaten. Beliebte Social-Engineering-Methoden sind Phishing (Mail) und Vishing (Voice-Phishing via Telefon), insbesondere Spear-Phishing/Vishing (auf die Person maßgeschneidert). Bei dem Angriff auf der US-Einzelhändler Target 2013/14 wurden mit einem Spear-Phishing-Angriff die Zugangsdaten eines Lieferanten von Heizungs-, Lüftungs- und Klimaanlagen erbeutet. Mit diesen Daten verschafften sich die Angreifer Zugang zu Target, manipulierten dort die Point-of-Sale-Geräte (Kreditkartenlesegeräte) und erbeuteten auf diesem Wege ca. 110 Million Datensätze [21, 22, 23, 24].

Schutzmaßnahmen

Nachfolgend stelle ich auf sehr allgemeiner Ebene die wichtigsten Schutzmöglichkeiten vor. Diese sind nicht vollständig und abschließend, sondern sollen den Einstieg erleichtern. Konkrete Maßnahmen sollten immer der individuellen Situation angepasst sein. Als Basis empfehle ich, eine Bedrohungsanalyse (zum Beispiel nach STRIDE) durchzuführen, um beispielsweise die Bedrohungen der Software Supply Chain zu erfassen und anschließend entweder zu mitigieren, oder als Risiko zu akzeptieren. Nachfolgend beschreibe ich die Schutzmaßnahmen nach Themen gruppiert.

Wie funktioniert eigentlich eine Bedrohungsanalyse? Das beschreiben wir hier in unserem Blog:

Threat Modeling

Sicherer Umgang mit Zugangsdaten

In diesem Abschnitt geht es um Schutzmaßnahmen für Zugangsdaten. Die OWASP bietet hier mit ihren Cheatsheet-Webseiten [29, 30, 31, 32, 33] eine gute Unterstützung. Hier eine kurze Übersicht:

Keine Zugangsdaten in die Repositories einchecken
Privilegierte Accounts (zum Beispiel Admins) schützen
- wenn möglich Multi-Faktor-Authentifizierung (MFA), mindestens 2FA, nutzen
- für jeden Benutzer einen Account je Anwendung verwenden
- für jeden Account von verschieden Anwendungen eines Benutzers immer ein anderes Passwort und wenn möglich Benutzernamen/Email verwenden
- immer sichere Passwörter verwenden
  - am besten von einem Passwortmanager generiert
  - mindestens 25 Zeichen (Sonderzeichen, Zahlen, Groß- und Kleinbuchstaben)
CI/CD Pipeline
- keine Zugangsdaten als Umgebungsvariablen hinterlegen
- keine Zugangsdaten in Konfigurationsdateien ablegen
- Secret-Management-Systeme nutzen (z.B. HashiCorp Vault) nutzen
  - die Pipeline benötigt einen sicheren Zugang zum Secret-Management-System, zum Beispiel mit einem Zertifikat
- die Anzahl der Personen mit privilegiertem Zugang zur Pipeline beschränkt halten
- Zugangsdaten regelmäßig rollieren
- beim Forken oder Kopieren eines Repositories oder einer Job Definition dürfen die Zugangsdaten nicht mitkopiert werden
- alle Aktivitäten mitgeloggen und monitoren
  - zum Beispiel, um Secret Extraction oder Missbrauch zu erkennen
- Dokumentieren, welche Zugangsdaten von der CI/CD Pipeline genutzt werden
  - zum Beispiel, welche Personen Zugangsdaten sehen/manipulieren können

CI/CD Pipeline absichern

Schutzmaßnahmen die die Zugangsdaten der Pipeline betreffen habe ich bereits beschrieben, somit wird dies in diesem Abschnitt nicht mehr behandelt. Weitere Information sind auf den Webseiten [34, 35] zu finden.

CI/CD Pipeline ist zu härten wie eine Produktionsumgebung
- alle Komponenten der Pipeline werden regelmäßig gepatcht und wichtige Security Patches werden sofort eingespielt
- alle Kommunikation erfolgt nur über verschlüsselte Verbindungen
  - wenn möglich Transport Layer Security (TLS) 1.3, mindestens jedoch TLS 1.2
- die Pipeline sollte in einem eigen Netzwerksegment, wenn möglich ohne direkten Zugang zum Internet, liegen
- Logging & Monitoring für alle ausgehenden Daten
Infrastructure as Code (IaC) ist wie der Quellcode der Anwendung zu sichern
alle Container Images müssen auf Schwachstellen gescannt werden, wenn sie in die Registry gelangen
alle erzeugten Artefakte oder Container sollten immer signiert werden

Beratung und Support für Ihre IT Security finden Sie hier:

Security Consulting Security Champion

Quellcode absichern

Es gibt eine Vielzahl an Tools, die bei der Absicherung des Quellcodes helfen – einer der wichtigsten Schutzmechanismen ist aber immer noch das Vier-Augen-Prinzip. Insbesondere sicherheitskritische Bereiche sollten von affinen Entwicklern oder einem Security-Experten einem Codereview unterzogen werden. Hierbei ist wichtig, dass die Person die Programmiersprache gut beherrscht. Nachfolgend noch als Liste die wichtigsten Punkte:

regelmäßig Software Compostion Analysis Tools verwenden
- zum Beispiel OWASP Dependency Check [36], Whitesource [37], etc.
regelmäßig Static Application Security Testing (SAST) Tools [38] verwenden
- zum Beispiel Fortify, SpotBugs mit FindSecBugs, SonarQube [40]
Quellcode sollte immer nach dem Vier-Augen-Prinzip behandelt werden. Bei sicherheitskritischen Bereichen sollten Code-Reviews von Experten durchgeführt werden.
- zum Beispiel Commiter != Merger (Vier-Augen-Prinzip)
Es sollte ein Dependency Management geben.
- Dependencies dürfen nur aus vertrauenswürdigen Quellen verwendet werden
- Bei Dependencies sollten immer feste Versionen, wenn möglich auch für transitive Dependencies, gesetzt werden.
  - zum Beispiel mittels Gradle resolutionStrategy.activeDependencyLocking [39]

Social Engineering

Beim Schutz vor Social Engineering ist es wichtig, alle Personen des Unternehmens und der Zulieferer zu sensibilisieren. Dabei gilt die Devise: „Unsicheres Verhalten muss bewusst sein, nur dann kann es vermieden werden.“ Sicheres Verhalten ist erlernbar, es muss aber regelmäßig aufgefrischt werden. Die Seite „10 Tipps zum Schutz vor Social Engineering“ [42] zeigt, worauf man achten sollte. Videos veranschaulichen, wie einfach beispielsweise Vishing [44] ist. Social Engineering nutzt oft die folgenden Verhaltensweisen aus [41]:

Vorurteile/Erwartungen (Beispiel: Jemand, der wie Techniker aussieht, verlangt wegen eines „Notfalls“, dass die Tür zum Serverraum geöffnet wird.)
Autoritätshörigkeit (Beispiel: Der Chef weist aus dem Urlaub eine dringende Zahlung an)
Neugierde (Beispiel: Was ist auf dem auf dem Parkplatz gefunden USB-Stick?)
Automatismen (Beispiel: Beim morgendlichen Mailcheck auf einen Phishing-Link klicken)
Angst (Beispiel: In einer Mail wird gedroht, dass das Amazon Konto gesperrt wird, wenn nicht innerhalb von x Tagen eine Verifizierung über den beigefügten Link erfolgt)
Hilfsbereitschaft (Beispiel: Tür aufhalten, weil die Person die Hände voll hat)

Exkurs: Typischer Aufbau moderner Software

Moderne Software besteht aus zahlreichen (OpenSource) Bibliotheken, welche wiederum aus vielen kleineren (OpenSource) Bibliotheken oder Projekten bestehen. Manche der Bibliotheken bestehen nur aus wenigen (hundert) Zeilen Quellcode und werden häufig von einem Maintainer in dessen Freizeit betreut. Das Bild des Eisbergs, wo nur wenig oberhalb der Oberfläche zu sehen ist, trifft es schon gut. Noch besser finde ich aber das XKCD-Bild „Dependency“, da es die Fragilität perfekt auf den Punkt bringt.