Supply-Chain-Angriffe überwachen und stoppen

Ein Supply-Chain-Angriff ist eine spezielle Art von Cyberangriff, der sich auf die Lieferkette von Software oder Hardware konzentriert. Anstatt das Hauptziel direkt zu attackieren, zielt der Angreifer auf die Lieferanten oder Anbieter von Hardware und Software ab, die mit dem Hauptziel verbunden sind. Dies ermöglicht es dem Angreifer, indirekt in das Hauptziel einzudringen und das bestehende Vertrauen in die Lieferkette auszunutzen. Diese Angriffe werden typischerweise über Dienstleister mit Zugriffsrechten oder über Softwarehersteller durchgeführt.

In den letzten Jahren haben solche Cyberangriffe zugenommen und stellen nun eine erhebliche Bedrohung für die IT-Sicherheit dar, unabhängig davon, ob das betroffene Unternehmen ein Hersteller oder ein Kunde ist.

Die Erkennung und Neutralisierung von Supply-Chain-Angriffen kann eine Herausforderung sein. Unternehmen können jedoch ihre Fähigkeit zur Erkennung und Neutralisierung von Supply-Chain-Angriffen verbessern, indem sie verschiedene Ansätze kombinieren und fortschrittliche Erkennungstechnologien einsetzen. Kontinuierliche Überwachung, Threat Intelligence und ein proaktives Sicherheitskonzept sind entscheidende Elemente zur Abwehr solcher ausgeklügelten Bedrohungen.

Ein Network Detection & Response (NDR) mit Machine Learning kann ein wichtiger Bestandteil der Sicherheitsstrategie sein, um unter anderem Supply-Chain-Angriffe zu erkennen und zu bekämpfen und ihren Schadensradius zu minimieren. Eine regelmäßige und kontinuierliche Überwachung des Netzwerkverkehrs ist für die frühzeitige Erkennung von Angriffen auf die Lieferkette unerlässlich. Genau das bietet NDR: Echtzeiteinblick in das Netzwerk, so dass Sicherheitsteams sofort auf verdächtige Aktivitäten reagieren können.

Bevor wir uns jedoch mit der Technologie hinter der vorgestellten Lösung befassen, sollten wir die jüngsten, massiven Vorfälle untersuchen

Beispiele für Supply Chain Angriffe

Beispiel 1: SolarWinds Orion

Ein exemplarisches Szenario für einen derartigen Angriff lässt sich am Vorfall der SolarWinds Orion Supply Chain Ende 2020 illustrieren. In diesem Fall gelang es Cyberkriminellen, sich in den Entwicklungsprozess von SolarWinds einzuschleichen und eine schädliche Backdoor in die Softwareupdates einzufügen. Tausende von Kunden installierten unwissentlich diese manipulierte Software, was den Angreifern einen Fernzugriff auf sensible Netzwerke und Daten ermöglichte.

Mit NDR hätte es besser ausgesehen

Eine NDR-Lösung wie ExeonTrace hätte in Echtzeit erkannt, dass die Systeme von SolarWinds kompromittiert wurden. Ihr auf Machine Learning basierendes Modell ist dazu in der Lage, unautorisierten Netzwerkverkehr sofort zu identifizieren, insbesondere wenn Angreifer generierte Domains verwenden. ExeonTrace kann ungewöhnliche Aktivitäten in Echtzeit erkennen und Alarm auslösen, selbst bei verschlüsselten Daten, indem es die Muster der Datenströme analysiert.

In Assets lernt das Modell aber weiterhin mit unsupervised Machine Learning, wie das normale Verhalten in dem jeweiligen Netz aussieht. Dazu braucht es nicht unbedingt den Inhalt des Datenverkehrs zu kennen, sondern lediglich die Muster der Datenströme. Kommt es zu einer auffälligen Verhaltensänderung, schlägt es Alarm. Die Lösung kann daher auch mit verschlüsselten Daten arbeiten.

Beispiel 2: They liked to MoveIt

Ein weiteres Beispiel ist der MoveIt-Supply-Chain-Angriff, der von BianLian ausgenutzt wurde. Dieser Angriff richtete sich vorrangig auf ein Softwarepaket namens MoveIt, das in der Robotik für Bewegungsplanung und -manipulation verwendet wird. Bei einem Supply-Chain-Angriff infiltriert und kompromittiert ein bösartiger Akteur den Entwicklungs- oder Distributionsprozess einer Software, um schädlichen Code einzufügen, bevor dieser den Endbenutzer erreicht. Im Falle von MoveIt erlangten die Angreifer unberechtigten Zugriff auf die Build-Infrastruktur der Software und fügten während des Build-Prozesses schädlichen Code in die MoveIt-Codebasis ein.

Nach der Integration des schädlichen Codes wurde dieser als Teil regulärer Software-Updates an die Benutzer verteilt. Die Benutzer installierten unwissentlich die kompromittierte Version von MoveIt, was den Angreifern ermöglichte, Schwachstellen auszunutzen, vertrauliche Informationen zu stehlen und andere schädliche Aktivitäten auf den betroffenen Systemen durchzuführen.

Solche Angriffe sind besonders gefährlich, da sie eine große Anzahl von Benutzern bedrohen, die auf die Integrität der von ihnen verwendeten Software vertrauen. Dies unterstreicht die Bedeutung der Absicherung des gesamten Prozesses der Softwareentwicklung und -verteilung, um unberechtigten Zugriff und Manipulationen zu verhindern. Softwareentwickler und -betreiber sollten daher stets strenge Sicherheitsmaßnahmen ergreifen, um sich vor derartigen Supply-Chain-Angriffen zu schützen und die Sicherheit sowie Zuverlässigkeit der bereitgestellten Software für User zu gewährleisten.

Beispiel 3: Kompromittierung eines Upstream-Servers: Codecov-Angriff

Bei zahlreichen Cyberangriffen auf Softwaresysteme dringen Angreifer oft in einen zentralen Server oder Codespeicher ein und fügen schädliche Elemente wie bösartigen Code oder gefälschte Updates hinzu, die dann an eine breite Nutzerbasis versandt werden. Nicht alle Angriffe auf die Lieferkette folgen jedoch diesem typischen Muster.

Ein exemplarisches Szenario ist der Codecov-Vorfall. Obwohl er gelegentlich mit dem SolarWinds-Angriff verglichen wird, weist er bedeutende Unterschiede auf. Im Fall von SolarWinds manipulierten geschickte Angreifer die offizielle Update-Datei SolarWinds.Orion.Core.BusinessLayer.dll im IT-Überwachungsprodukt Orion von SolarWinds. Der abgeänderte Code, der in der RefreshInternal()-Methode verborgen war, aktiviert beim Laden des Inventory Manager-Plugins in Orion eine heimtückische Hintertür. Die Auswirkungen beschränkten sich jedoch nach Verbreitung des manipulierten Updates auf etwa 18.000 Orion-Kunden von SolarWinds, darunter auch US-Behörden.

Im Gegensatz dazu erfolgte beim Codecov-Angriff keine Verbreitung bösartigen Codes an die Endbenutzer. Die Angreifer nutzten stattdessen einen fehlerhaften Prozess bei der Erstellung von Docker-Images aus, um Zugangsdaten zu erlangen. Mithilfe dieser Zugangsdaten konnten sie den Codecov-Bash-Uploader manipulieren, der auf dem Codecov-Server gehostet wurde. Dieser Uploader sammelt Umgebungsvariablen, die von den Continuous Integration/Continuous Delivery (CI/CD)-Umgebungen der Kunden gesendet werden. Obwohl sich das Bash-Uploader-Skript auf dem kompromittierten Server (codecov[.]io/bash) befand, waren viele Repositories bereits mit diesem Ort verknüpft, um ihre CI/CD-Daten auszutauschen.

Der schädliche Code blieb somit auf dem kompromittierten Server, ohne sich weiter zu verbreiten, da die verknüpften Repositories bereits so konfiguriert waren, dass sie Daten auf den kompromittierten Codecov-Server hochladen. Dies beeinträchtigte jedoch diese nachgelagerten Repositories, da sie unwissentlich ihre Informationen an den kompromittierten Bash-Uploader weiterleiteten. Berichten zufolge infiltrierten die Angreifer Hunderte von Netzwerken mit den Zugangsdaten, die sie über den kompromittierten Bash-Uploader erlangten.

Beispiel 4: Angriff durch Dependency Confusion

In zahlreichen Berichten über Angriffe auf die Lieferkette in den vergangenen Jahren wurde wiederholt ein Problem namens Dependency Confusion betont. Diese Schwachstelle hat an Bedeutung gewonnen, da sie eine einfache und automatisierte Angriffsmethode darstellt. Hierbei wird ein Konstruktionsfehler in verschiedenen Open-Source-Systemen ausgenutzt, was den Angreifern eine reibungslose Vorgehensweise ermöglicht.

Um es einfacher zu erklären: Stellen Sie sich vor, Sie entwickeln Software, die auf einer privat erstellten Komponente basiert, die nicht öffentlich zugänglich ist. Ein geschickter Angreifer könnte dies ausnutzen, indem er eine ähnlich benannte Komponente mit einer höheren Versionsnummer in einem öffentlichen Repository registriert. Ihr Software-Build könnte dann versehentlich die Version des Angreifers anstelle der internen Version einbinden.

Grundsätzlich handelt es sich um ein raffiniertes Manöver, das die Art und Weise ausnutzt, wie Softwarekomponenten verwaltet werden, und sich zu einem häufigen Problem in der technischen Sicherheitslandschaft entwickelt hat.

Beispiel 5: Gestohlene SSL- und Code Signing-Zertifikate

Neben herkömmlichen SSL-Zertifikaten existieren auch Code-Signing-Zertifikate. Im Gegensatz zu Zertifikaten, die zur Verschlüsselung des Datenverkehrs mit dem zentralen Server dienen, verleiht ein Code-Signing-Zertifikat ein Gefühl der Authentizität, da die Software erfolgreich mit dem privaten Schlüssel des Anbieters signiert wurde. Wenn dieser private Schlüssel, der mit dem Zertifikat verknüpft ist, gestohlen wird, hat dies gravierende Auswirkungen auf die Sicherheit der Software. Stellen Sie sich vor: Der Angreifer erlangt Zugriff auf den privaten Codesignierungsschlüssel und nutzt ihn, um bösartige Software zu signieren, die als legitimes Programm oder Update eines seriösen Unternehmens erscheint.

Vor etwa einem Jahr (Dezember/Januar 2023) wurden die Codesignierungsschlüssel von GitHub und Microsoft von einer Gruppe von Angreifern gestohlen, und vor wenigen Wochen wiederholte sich dies bei AnyDesk.

Erinnern Sie sich an Stuxnet? Ein weiteres Beispiel für einen raffinierten Angriff, bei dem die Angreifer gestohlene private Schlüssel einsetzten, um ihren bösartigen Code als „vertrauenswürdig“ erscheinen zu lassen. Warum greifen wir so weit zurück? Nun, es war einer der ersten Fälle, in denen bösartige Personen Codesignatur-Zertifikate erfolgreich einsetzten, um ein falsches Gefühl von Sicherheit und Vertrauen zu vermitteln.

Zusammenfassend lässt sich sagen, dass Probleme im Bereich Codesignatur etwas sind, auf das man besonders achten sollte und das Unternehmen jeder Größe treffen kann. Wenn Sie also beim nächsten Mal von SSL- und Codesignatur-Zertifikaten hören, sollten Sie wissen, dass es sich nicht nur um technischen Fachjargon handelt, sondern dass dies wichtige Schutzmaßnahmen in der digitalen Welt sind und dass die Sicherheit dieser Schlüssel für alle von entscheidender Bedeutung ist, aber auch Gefahren birgt.

Beispiel 6: Angriff auf die CI/CD-Entwicklungsinfrastruktur

Stellen Sie sich einen ausgeklügelten Angriff auf Software vor, bei dem nicht nur schädliche Änderungen in ein GitHub-Projekt eingebracht werden, sondern auch ein automatisiertes System zur Aufgabenautomatisierung auf GitHub ausgenutzt wird. Dieser Angriff geht über das bloße Verursachen von Ärger hinaus – er nutzt das Automation-Setup auch heimlich, um Kryptowährung zu generieren.

Auf GitHub können Entwickler mithilfe von GitHub Actions automatisierte Prozesse einrichten. Diese Prozesse unterstützen sie dabei, ihren Code nahtlos zu testen und bereitzustellen. Bei diesem Angriff kopieren die Angreifer echte Projekte von GitHub, nehmen geringfügige Anpassungen an der Automatisierungseinrichtung vor und schlagen diese Änderungen dann dem ursprünglichen Projekteigentümer vor. Wenn der Eigentümer die Änderungen akzeptiert, schleichen sich die schädlichen Modifikationen wieder in das Projekt ein und verursachen alle Arten von Problemen. Gleichzeitig verdienen die Angreifer im Hintergrund Geld durch das Mining von Kryptowährungen, ohne dass dies jemand bemerkt. Für das Projekt und die nichtsahnenden Entwickler ist dies eine doppelte Katastrophe.

Wie können Unternehmen ihre Sicherheit stärken?

Welche weiteren Maßnahmen sind möglich? Hier sind fünf Strategien zur Abwehr von Angriffen auf die Lieferkette und warum sie effektiv sind:

1. Identifikation von Netzwerkanomalien:

Die Überprüfung des Netzwerkverkehrs auf ungewöhnliche Muster, insbesondere in Bezug auf die Kommunikation mit externen Servern oder unerwartete Datenübertragungen, erfolgt durch die Analyse von Anomalien. NDR-Tools nutzen diesen Ansatz, indem sie aktuelles Verhalten mit historischen Daten oder vordefinierten Standards vergleichen.

2. Verhaltensanalyse:

Die Überwachung von ungewöhnlichem oder unerwartetem Verhalten in Netzwerken, einschließlich Prozessausführung, Dateiänderungen und Netzwerkkommunikation, ermöglicht es NDR-Lösungen mit Machine Learning, verdächtige Aktivitäten zu erkennen. Dabei wird eine Baseline des normalen Netzwerkverhaltens erstellt, und Abweichungen davon können auf mögliche Angriffe aus der Lieferkette hinweisen.

3. User and Entity Behaviour Analytics (UEBA):

Diese Methode beobachtet das Verhalten von Benutzern und Entitäten, um ungewöhnliche Aktivitäten oder Zugriffsmuster zu identifizieren. UEBA zielt darauf ab, Angreifer in der Lieferkette zu entlarven, die versuchen, sich als legitime Benutzer oder Entitäten auszugeben.

4. Integration von Threat Intelligence Feeds:

Durch die Verknüpfung von NDR-Tools mit Threat-Intelligence-Feeds bleiben Unternehmen über die neuesten Kompromittierungsindikatoren (Indicators of Compromise, IOCs) im Zusammenhang mit Angriffen auf die Lieferkette informiert. Dadurch kann jede Netzwerkaktivität identifiziert werden, die mit bekannten bösartigen Entitäten oder Techniken in Verbindung steht.

5. Integration von NDR und EDR-Lösungen:

Die Zusammenführung von Network Detection and Response (NDR) mit Endpoint Detection and Response (EDR)-Lösungen ermöglicht einen umfassenderen Einblick in die Netzwerk- und Endpunktaktivitäten. Diese Integration unterstützt einen ganzheitlichen Ansatz zur Erkennung und Reaktion auf Angriffe auf die Lieferkette.

Zusätzlich zu technologischen Lösungen ist eine umfassende Strategie für das Risikomanagement in der Lieferkette entscheidend, die robuste Gegenmaßnahmen und bewährte Praktiken beinhaltet. Dazu gehört die Überprüfung und Kontrolle von Drittanbietern sowie die Sicherstellung eines umfassenden Inventars der in der Unternehmensinfrastruktur verwendeten Software- und Hardwarekomponenten.

Die Information über aktuelle Bedrohungen und Schwachstellen in der Cybersicherheitslandschaft ist unerlässlich. Die Beteiligung an Communities zum Austausch von Bedrohungsdaten ermöglicht es, potenzielle Risiken in der Lieferkette besser zu verstehen und zu bewältigen.

Die Identifizierung und Dokumentation des Liefernetzwerks, unter besonderer Berücksichtigung der relevanten Abhängigkeiten und Risiken, trägt zur Schaffung von Transparenz bei. Die Kategorisierung von Assets, die mit Dritten geteilt werden, sowie die Erstellung von Zugriffschutzprotokollen sind entscheidend, um Sicherheitsstandards aufrechtzuerhalten.

Die vertragliche Festlegung von Sicherheitsanforderungen und Meldepflichten für Dritte, zusammen mit klaren Richtlinien für die Vergabe und Beendigung von Verträgen, ist notwendig, um die Sicherheit in der Lieferkette zu gewährleisten.

Die Überwachung der Leistung von Lieferanten durch regelmäßige Sicherheitsaudits, Reifegradbewertungen und Bedrohungsanalysen ist von großer Bedeutung, um frühzeitig potenzielle Schwachstellen zu erkennen und zu beheben.

Die Festlegung von Verantwortlichkeiten für den sicheren Betrieb von Produkten/Dienstleistungen während ihres gesamten Lebenszyklus, einschließlich Maßnahmen nach dem Service, trägt dazu bei, eine Basislinie für das normale Verhalten von Partnern zu etablieren, sodass Abweichungen als potenzielle Risiken erkannt werden können.

Fortgeschrittene NDR-Tools können zur kontinuierlichen Überwachung und Bewertung der Sicherheitslage von Partnern in der Lieferkette eingesetzt werden. Durch die Festlegung einer Baseline für das normale Verhalten dieser Partner können Abweichungen effektiv als potenzielle Risiken identifiziert werden.

Für Unternehmen mit Sitz in Deutschland stehen grundlegende Tipps und Reifegrad-Checklisten zur IT-Sicherheit über das Bundesamt für Sicherheit in der Informationstechnik (BSI) zur Verfügung. Zusätzlich zu regulatorischen Anforderungen, wie der KRITIS-Verordnung oder branchenspezifischen Vorschriften wie der UNECE-Regelung Nr. 155 im Automobilbereich, sind Unternehmen gemäß § 8b Abs. 4 des BSI-Gesetzes verpflichtet, alle relevanten Erkenntnisse im Falle eines Vorfalls unverzüglich dem BSI zu melden. Diese Meldepflicht erstreckt sich über das einzelne Unternehmen und betrifft auch Liefernetzwerke.

Vor dem Hintergrund der Dringlichkeit und Bedeutung dieses Themas engagieren sich Regierungen und Behörden weltweit aktiv in der Entwicklung gesetzlicher Anforderungen und Spezifikationen, insbesondere im Hinblick auf Cybersecurity-Bedrohungen in Lieferkettennetzwerken.

Die Entscheidung für oder gegen Deep Packet Inspection (DPI)?

Einige NDR-Lösungen integrieren Funktionen zur Deep Packet Inspection, die darauf abzielen, den Inhalt von Netzwerkdatenpaketen zu analysieren und dabei bösartige Payloads oder Kommunikationsparameter in Bezug auf Angriffe auf die Lieferkette zu identifizieren.

Jedoch ergibt sich hierbei eine Herausforderung: Unternehmen setzen zunehmend auf Verschlüsselung, um ihren Netzwerkverkehr und Online-Interaktionen abzusichern und so die Cybersecurity und Datensicherheit zu stärken. Dies bietet jedoch auch Cyberkriminellen die Gelegenheit, im Verborgenen zu agieren und schwerwiegende Cyberangriffe zu initiieren.

Das Hauptproblem liegt darin, dass die DPI-Technologie nicht darauf ausgelegt ist, verschlüsselten Datenverkehr zu analysieren, da sie keine verschlüsselten Paketnutzdaten untersuchen kann. Dies stellt eine erhebliche Schwäche von DPI dar, da viele moderne Cyberangriffe, wie Advanced Persistent Threats (APTs), Ransomware und laterale Bewegungen, stark auf Verschlüsselung setzen, um Anweisungen von entfernten Command-and-Control-Servern (C&C) zu empfangen.

Insbesondere bei Angriffen auf die Lieferkette können Angreifer einen Anbieter oder Partner innerhalb der Lieferkette eines Unternehmens kompromittieren. Die verschlüsselte Kommunikation zwischen der kompromittierten Einheit und dem Zielunternehmen bleibt für herkömmliche DPI-Lösungen unbemerkt, was die Erkennung bösartiger Aktivitäten oder der Datenexfiltration erschwert.

Ein weiteres Problem ist, dass APTs oft Befehls- und Kontrollserver einrichten, um ihre Aktivitäten zu koordinieren. Die verschlüsselte Kommunikation zwischen kompromittierten Systemen und diesen C2-Servern hilft den APTs, ihre Tarnung aufrechtzuerhalten. Ohne die Fähigkeit, verschlüsselte Nutzdaten zu untersuchen, können DPI-Lösungen kritische Indikatoren für Gefährdungen, die mit dieser Kommunikation verbunden sind, leider oft übersehen.

Abgesehen von den fehlenden Verschlüsselungsfähigkeiten erfordert DPI erhebliche Rechenleistung und Zeit, um den Datenteil der Pakete gründlich zu prüfen. Daher ist DPI in datenintensiven Netzwerken nicht in der Lage, alle Netzwerkpakete zu durchsuchen, was es zu einer unpraktikablen Lösung für Netzwerke mit hoher Bandbreite macht.

Hingegen erweist sich ein NDR-System mit Metadatenanalyse als effektivere Lösung für die Erkennung von Bedrohungen aus verschiedenen Datenquellen und für die automatische Identifikation von Cyberbedrohungen wie APTs, Ransomware und Angriffen auf die Lieferkette.

Durch die Nutzung von Metadaten für die Netzwerkanalyse können Sicherheitsteams die gesamte Netzwerkkommunikation überwachen, unabhängig davon, ob sie physische, virtualisierte oder Cloud-Netzwerke durchläuft, ohne den gesamten Datenbereich jedes Pakets zu durchforsten. Die Metadatenanalyse ist unabhängig von Verschlüsselung und kann mit dem kontinuierlich steigenden Netzwerkverkehr umgehen. Sie bietet Echtzeitinformationen über den gesamten Netzwerkverkehr und erfasst zahlreiche Attribute in Bezug auf Netzwerkkommunikation, Anwendungen und Akteure (z. B. Benutzeranmeldungen).

Durch die Implementierung einer NDR-Lösung mit Metadatenanalyse erhalten Sicherheitsteams einen umfassenden Überblick über die Netzwerkaktivitäten, unabhängig von der Verschlüsselung. Dieser Ansatz, kombiniert mit System- und Applikationsprotokollen, trägt zur Identifizierung von Schwachstellen bei und verbessert die Transparenz, insbesondere im Hinblick auf Schatten-IT, die häufig von Cyberkriminellen ausgenutzt wird.

Im Gegensatz zu DPI-basierten NDR-Lösungen bietet dieser Ansatz eine ganzheitliche Sichtbarkeit und deckt blinde Flecken effektiv auf.

Quelle: Exeon-Blog

Sie haben Fragen? Michael Tullius*, Sales Director, Exeon können Sie über Linkedin direkt ansprechen.
* Kontaktmöglichkeit über Linkedin