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?

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.

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].

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.

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].

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].

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].

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].

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

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]. 

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.

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

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

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]

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)

[1] www.heise.de/news/Codecov-Gehacktes-Entwickler-Tool-Bash-Uploader-zum-Datendiebstahl-missbraucht-6019302.html
[2] about.codecov.io/security-update/
[3] blog.gitguardian.com/codecov-supply-chain-breach/ 
[4] www.heise.de/news/Schadcode-in-weit-verbreiteter-JavaScript-Bibliothek-UAParser-js-entdeckt-6226975.html 
[5] github.com/faisalman/ua-parser-js/issues/536 
[6] medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 
[7] www.heise.de/news/Verwirrung-um-vermeintlichen-Dependency-Confusion-Angriff-auf-deutsche-Firmen-7089135.html 
[8] snyk.io/blog/npm-dependency-confusion-attack-gxm-reference/ 
[9] www.heise.de/news/Passwordstate-Passwort-Manager-von-Click-Studios-gehackt-6027188.html 
[10] www.bleepingcomputer.com/news/security/passwordstate-password-manager-hacked-in-supply-chain-attack/ 
[11] www.vaimo.com/magecart-attacks-protect-your-business/ 
[12] www.zdnet.de/88382806/2-000-magento-onlineshops-gehackt/ 
[13] www.computerwoche.de/a/so-wird-ihre-software-lieferkette-gehackt,3551514 
[14] www.heise.de/news/Codecov-Gehacktes-Entwickler-Tool-Bash-Uploader-zum-Datendiebstahl-missbraucht-6019302.html 
[15] about.codecov.io/security-update/ 
[16] blog.gitguardian.com/codecov-supply-chain-breach/ 
[17] github.com/rung/threat-matrix-cicd 
[18] www.spektrum.de/news/solarwinds-ein-hackerangriff-der-um-die-welt-geht/1819187 
[19] www.faz.net/aktuell/wirtschaft/digitec/solarwinds-hack-massiver-cyberangriff-gefaehrdet-deutsche-behoerden-17134477.html 
[20] www.all-about-security.de/allgemein/angriff-auf-die-supply-chain-solarwinds/ 
[21] www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/ 
[22] www.commerce.senate.gov/services/files/24d3c229-4f2f-405d-b8db-a3a67f183883 
[23] securityintelligence.com/target-breach-protect-against-similar-attacks-retailers/;
[24] secarma.com/a-brief-history-of-supply-chain-attacks/ 
[25] www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/ 
[26] www.heise.de/news/Bugs-mit-Vorsatz-University-of-Minnesota-von-Linux-Kernel-Mitarbeit-ausgesperrt-6024245.html 
[27] github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf 
[28] it-seal.de/du-bist-die-firewall/ 
[29] cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html 
[30] cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_CheatSheet.html 
[31] cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html 
[32] cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_CheatSheet.html 
[33] owasp.org/www-pdf-archive//Secure_Password_Storage.pdf 
[34] www.docker.com/blog/securing-enterprise-software-supply-chain-using-docker/ 
[35] www.paloaltonetworks.com/cyberpedia/what-is-the-ci-cd-pipeline-and-ci-cd-security 
[36] owasp.org/www-project-dependency-check/ 
[37] www.whitesourcesoftware.com/ 
[38] owasp.org/www-community/Source_Code_Analysis_Tools 
[39] docs.gradle.org/current/userguide/dependency_locking.html 
[40] www.sonarqube.org/features/security/ 
[41] cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html 
[42] it-seal.de/du-bist-die-firewall/ 
[43] www.treesolution.com/news/10-tipps-zum-schutz-vor-social-engineering 
[44] www.youtube.com/watch;
[45] xkcd.com/2347/