Wie man Supply-Chain-Angriffe überwacht und stoppt

Die Erkennung und Entschärfung von Supply-Chain-Angriffen kann eine Herausforderung sein, jedoch können Unternehmen durch die Kombination verschiedener Ansätze und den Einsatz fortschrittlicher Erkennungstechnologien ihre Fähigkeit zur Erkennung und Entschärfung von Supply-Chain-Angriffen verbessern. Permanente Überwachung, Threat Intelligence und ein proaktives Sicherheitskonzept sind entscheidende Elemente bei der Abwehr solch ausgefeilter Bedrohungen.

Ein Network Detection & Response (NDR) mit Machine Learning kann ein entscheidender Bestandteil der Sicherheitsstrategie sein, um unter anderem Supply-Chain-Angriffe zu erkennen, zu bekämpfen und ihren Gefahrenradius zu minimieren. Eine regelmässige und permanente Überwachung des Netzwerkverkehrs ist für die frühzeitige Erkennung von Angriffen auf die Lieferkette unerlässlich, und genau das bietet NDR: Echtzeiteinsicht in das Netzwerk, so dass Sicherheitsteams umgehend auf verdächtige Aktivitäten reagieren sollen.

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

Aktuelle Beispiele für Attacken auf die Software Supply Chain

Beispiel 1: Angriff auf die SolarWinds Orion Supply Chain

Der SolarWinds Orion-Vorfall Ende 2020 ist ein Beispiel für einen Angriff auf die Supply Chain: Hacker haben den Softwareentwicklungsprozess von SolarWinds kompromittiert und eine bösartige Backdoor in die Updates eingeschleust. Tausende von Kunden, darunter Regierungen und Fortune-500-Unternehmen, erhielten unwissentlich diese kompromittierte Software. Dadurch konnten die Angreifer per Remote-Zugriff auf sensible Netzwerke und Daten zugreifen.

Wie hätte NDR hier funktioniert?

Eine NDR-Lösung wie ExeonTrace hätte in Echtzeit erkennen können, dass die Systeme von Solarwinds kompromittiert wurden, da ihr auf Machine Learning basierendes Modell unzulässigen Netzwerkverkehr sofort entdeckt. Die Angreifer von Solarwinds haben generierte Domains verwendet (wenn Angreifer diese Methode verwenden, müssen sie sich nicht auf eine statische Adresse verlassen, um mit dem C&C-Server zu kommunizieren, der blockiert werden könnte) und ExeonTrace ist besonders schnell bei der Erkennung von Domains, die von Algorithmen generiert wurden. ExeonTrace funktioniert gut bei der Erkennung von unzulässigem Datenverkehr, da es durch überwachtes Machine Learning im Labor lernt, wie legitimer Webverkehr aussieht. Exeon generiert diese Daten selbst mithilfe automatisierter Webbrowser.

In den Assets des Kunden lernt das Modell aber weiterhin mit unüberwachtem 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: Die MoveIT-Sicherheitslücke, ausgenutzt von BianLian

Der MoveIt Supply-Chain-Angriff zielte in erster Linie auf ein Softwarepaket namens MoveIt, das in der Robotik für die Bewegungsplanung und -manipulation verwendet wird. Ein Angriff auf die Lieferkette liegt wie gesehen vor, wenn ein böswilliger Akteur den Entwicklungs- oder Distributionsprozess einer Software infiltriert und kompromittiert, so dass er bösartigen Code in die Software einschleusen kann, bevor diese den Endbenutzer erreicht. Im Fall von MoveIt verschafften sich die Angreifer unbefugten Zugriff auf die Build-Infrastruktur der Software. Die Build-Infrastruktur ist die Umgebung, in der der Softwarecode kompiliert und für den Vertrieb verpackt wird. Die Angreifer schleusten dann während des Build-Prozesses bösartigen Code in die MoveIt-Codebasis ein.

Sobald der bösartige Code in die Software integriert war, wurde er als Teil der regulären Software-Updates an die Benutzer verteilt. Die User installierten unwissentlich die kompromittierte Version von MoveIt, was es den Angreifern ermöglichte, Schwachstellen auszunutzen, vertrauliche Informationen zu stehlen und andere bösartige Aktivitäten auf den betroffenen Systemen auszuführen.

Diese Art von Angriffen ist deshalb so gefährlich, weil sie eine große Anzahl von Benutzern gefährdet, die auf die Integrität der Software vertrauen, die sie benutzen. Dies unterstreicht auch,wie wichtig es ist, den gesamten Prozess der Softwareentwicklung und -verteilung zu sichern, um unbefugten Zugriff und Manipulationen zu verhindern. Softwareentwickler und -betreuer sollten daher immer strenge Sicherheitsvorkehrungen treffen, um sich vor solchen Angriffen auf die Lieferkette zu schützen und die Sicherheit und Zuverlässigkeit der Software zu gewährleisten, die sie den Usern zur Verfügung stellen.

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

Bei vielen Cyberangriffen auf Softwaresysteme schleichen sich die Angreifer in der Regel in einen zentralen Server oder Codespeicher ein und fügen schädliche Elemente wie bösartigen Code oder gefälschte Updates hinzu. Diese Elemente werden dann an eine Vielzahl von Usern verschickt. Allerdings folgen nicht alle Supplychain-Cyberangriffe diesem Muster.

Nehmen Sie zum Beispiel den Codecov-Vorfall. Obwohl er oft mit dem SolarWinds-Angriff verglichen wird, gibt es doch wesentliche Unterschiede. Bei SolarWinds veränderten raffinierte Angreifer die offizielle Update-Datei SolarWinds.Orion.Core.BusinessLayer.dll im IT-Überwachungsprodukt Orion von SolarWinds. Der veränderte Code, der in der RefreshInternal()-Methode versteckt ist, aktiviert in Orion beim Laden des Inventory Manager-Plugins eine hinterhältige Backdoor. Die Auswirkungen betrafen nach Verbreitung des manipulierten Updates jedoch nur etwa 18.000 Orion-Kunden von SolarWinds, darunter auch US-Behörden.

Im Gegensatz dazu wurde bei dem Codecov-Angriff kein bösartiger Code an die Benutzer verteilt. Stattdessen nutzten die Angreifer einen fehlerhaften Prozess bei der Erstellung von Docker-Images aus, um Anmeldedaten zu erlangen. Mit diesen Zugangsdaten konnten sie den Codecov-Bash-Uploader manipulieren, der auf dem Codecov-Server gehostet wird. 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) befindet, waren viele Repositories bereits mit diesem Ort verknüpft, um ihre CI/CD-Daten auszutauschen.

Der schädliche Code blieb also nur auf dem kompromittierten Server, ohne sich weiter zu verbreiten, da die verknüpften Repositories bereits so eingestellt waren, dass sie Daten auf den kompromittierten Codecov-Server hochladen. Dies wirkte sich jedoch auf diese nachgelagerten Repositories aus, da sie ihre Informationen unwissentlich an den kompromittierten Bash-Uploader übermittelten. Die Angreifer haben Berichten zufolge Hunderte von Netzwerken mit Zugangsdaten infiltriert, die sie über den kompromittierten Bash-Uploader erhalten haben.

Beispiel 4: Angriff durch Dependency Confusion

In den letzten Jahren wurde in fast jedem Bericht über Angriffe auf die Supply Chain ein wiederkehrendes Problem hervorgehoben, das als Dependency Confusion bekannt ist. Dieses Problem hat an Bedeutung gewonnen, weil es sich um eine einfache und automatisierte Angriffsart handelt. Dabei wird ein Konstruktionsfehler in diversen Open-Source-Systemen ausgenutzt, welcher den Angreifern ein reibungsloses Vorgehen ermöglicht.

Um es einfach auszudrücken: Stellen Sie sich vor, Sie entwickeln eine Software, die sich auf eine private, intern erstellte Komponente stützt, die nicht öffentlich zugänglich ist. Ein cleverer Angreifer kann dies ausnutzen, indem er eine ähnlich bezeichnete 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.

Im Grunde handelt es sich um ein hinterhältiges Manöver, das sich die Art und Weise zunutze macht, 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 normalen SSL-Zertifikaten gibt es auch Code-Signing-Zertifikate. Im Gegensatz zu Zertifikaten, die zur Verschlüsselung des Datenverkehrs mit dem zentralen Server verwendet werden, vermittelt 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 verbunden ist, nun gestohlen wird, sind die Folgen für die Softwaresicherheit gravierend. Stellen Sie sich Folgendes vor: Der Angreifer gelangt in den Besitz des privaten Codesignierungsschlüssels und verwendet ihn, um bösartige Software so zu signieren, als handele es sich um ein legitimes Programm oder ein Update eines seriösen Unternehmens.

Vor ziemlich genau einem Jahr (Dezember/Januar 2023) wurden die Code-Signierungsschlüssel von Github und Microsoft von einer Gruppe von Angreifern gestohlen, und vor ein paar Wochen geschah das Gleiche mit AnyDesk.

Erinnern Sie sich an Stuxnet? Ein weiteres Beispiel für einen derart ausgeklügelten Angriff, bei dem die Angreifer gestohlene private Schlüssel verwendeten, um ihren bösartigen Code „vertrauenswürdig“ erscheinen zu lassen. Warum so weit in die Vergangenheit zurückgehen? Nun, es war einer der ersten Fälle, in denen böswillige Personen Code-Signatur-Zertifikate „erfolgreich“ verwendeten, um dieses falsche Gefühl von Sicherheit und Vertrauen zu vermitteln.

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

Beispiel 6: Angriff auf die CI/CD-Entwicklungsinfrastruktur

Stellen Sie sich einen raffinierten Angriff auf Computerprogramme vor, bei dem nicht nur schädliche Änderungen in ein Projekt auf GitHub eingeschleust werden, sondern der auch ein ausgeklügeltes System zur Automatisierung von Aufgaben auf GitHub ausnutzt. 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 helfen dabei, ihren Code reibungslos zu testen und bereitzustellen. Bei diesem Angriff kopieren die Angreifer echte Projekte von GitHub, nehmen kleine 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. Außerdem verdienen die Angreifer im Hintergrund Geld mit dem Mining von Kryptowährungen, ohne dass jemand dies bemerkt. Für das Projekt und die ahnungslosen Entwickler ist das eine doppelte Katastrophe.

Wie können sich Unternehmen schützen? Was können Sie sonst noch tun?

Hier sind 5 Möglichkeiten zur Bekämpfung von Angriffen auf die Lieferkette und warum sie effizient sind:

1. Die Erkennung von Anomalien im Netzwerkverkehr analysiert den Netzwerkverkehr auf ungewöhnliche Muster, insbesondere bei der Kommunikation mit externen Servern oder bei unerwarteten Datenübertragungen, und stellt fest, dass Anomalien im Netzwerkverkehr, im Benutzerverhalten oder in den Systemaktivitäten auf einen Angriff auf die Lieferkette hindeuten können. NDR-Tools identifizieren Anomalien durch einen Vergleich des aktuellen Verhaltens mit historischen Daten oder vordefinierten Normen.
2. Die Verhaltensanalyse zur Suche nach ungewöhnlichem oder unerwartetem Verhalten in Netzwerken und zur Überwachung von Anomalien bei der Prozessausführung, bei Dateiänderungen und bei der Netzwerkkommunikation kann verdächtige Aktivitäten aufzeigen, z.B. unbefugten Zugriff oder ungewöhnliche Datenexfiltrationsmuster. NDR-Lösungen mit Machine Learning verwenden Verhaltensanalysen, um eine Baseline des normalen Netzwerkverhaltens zu erstellen. Abweichungen von dieser Baseline können auf verdächtige Aktivitäten hindeuten, z.B. unerwartete Datenströme oder ungewöhnliche Kommunikationsmuster, die aus der Supply Chain stammen.
3. User and Entity Behaviour Analytics (UEBA) überwacht das Verhalten von Benutzern und Entitäten und identifiziert ungewöhnliche Aktivitäten oder Zugriffsmuster, um Angreifer in der Lieferkette aufzudecken, die versuchen, sich als legitime Benutzer oder Entitäten auszugeben.
4. Da NDR-Tools mit Threat-Intelligence-Feeds integriert werden, um über die neuesten Kompromittierungsindikatoren (Indicators of Compromise, IOCs) im Zusammenhang mit Angriffen auf die Lieferkette auf dem Laufenden zu bleiben, kann das Tool jegliche Netzwerkaktivität, die mit bekannten bösartigen Entitäten oder Techniken in Verbindung steht, identifizieren und eine Warnung ausgeben.
5. Die Integration von NDR mit EDR-Lösungen wird einen umfassenderen Überblick über die Netzwerk- und Endpunktaktivitäten bieten. Dadurch kann ein ganzheitlicherer Ansatz zur Erkennung von und Reaktion auf Angriffe auf die Supply Chain verfolgt werden.

Das liegt daran, dass DPI-Technologie nicht für die Analyse von verschlüsseltem Datenverkehr konzipiert wurde und verschlüsselte Paketnutzdaten nicht untersuchen kann. Dies ist ein erhebliches Manko von DPI, da die meisten modernen Cyberangriffe wie APT, Ransomware und Lateral Movement in ihrer Angriffsroutine stark auf Verschlüsselung setzen, um Angriffsinstruktionen von entfernten Command-and-Control-Servern (C&C) zu erhalten, die im Cyberspace verstreut sind. Wie bei einem Angriff auf die Supply Chain können die Angreifer einen Anbieter oder Partner innerhalb der Lieferkette eines Unternehmens kompromittieren. Die verschlüsselte Kommunikation zwischen der kompromittierten Einheit und dem Zielunternehmen kann von herkömmlichen DPI unbemerkt bleiben, was die Erkennung bösartiger Aktivitäten oder der Datenexfiltration erschwert. Ein weiteres Problem besteht darin, dass APTs häufig Befehls- und Kontrollserver einrichten, um ihre Aktivitäten zu verwalten und zu koordinieren. Die verschlüsselte Kommunikation zwischen kompromittierten Systemen und diesen C2-Servern hilft den APTs, ihre Tarnung aufrechtzuerhalten. Ohne die Möglichkeit, verschlüsselte Nutzdaten zu untersuchen, können DPI kritische Indikatoren für eine Gefährdung im Zusammenhang mit dieser Kommunikation leider oft übersehen. Abgesehen von den fehlenden encryption capabilities erfordert DPI viel Rechenleistung und Zeit, um den Datenteil der Pakete gründlich zu prüfen. Daher kann DPI in datenintensiven Netzwerken nicht alle Netzwerkpakete untersuchen, was es zu einer nicht praktikablen Lösung für Netzwerke mit hoher Bandbreite macht.

Eine leistungsfähige Erkennung, auch für Bedrohungen, die mehrere Datenquellen umfassen, oder zur automatischen Erkennung von Cyber-Bedrohungen wie Advanced Persistent Threats (APT), Ransomware, Angriffen auf die Lieferkette oder Datenlecks aus ungeschützten Systemen funktioniert jedoch besser mit einem NDR-System mit Metadatenanalyse. Diese Systeme sind dafür entwickelt worden, die Einschränkungen von DPI zu überwinden.

Durch den Einsatz von Metadaten für die Netzwerkanalyse können Sicherheitsteams die gesamte Netzwerkkommunikation überwachen, die über physische, virtualisierte oder Cloud-Netzwerke läuft, ohne den gesamten Datenbereich jedes Pakets zu untersuchen. Daher ist die Metadatenanalyse unabhängig von Verschlüsselung und kann mit dem ständig zunehmenden Netzwerkverkehr umgehen. Sie liefert den Security-Teams Echtzeitinformationen über den gesamten Netzwerkverkehr, und mit der Metadatenanalyse wird eine Vielzahl von Attributen über Netzwerkkommunikation, Anwendungen und Akteure (z. B. User-Anmeldungen) erfasst.

Beispielsweise werden für jede Sitzung, die das Netzwerk durchläuft, eine Quell-/Ziel-IP-Adresse, die Session-Länge, das verwendete Protokoll (TCP, UDP) und die Art der verwendeten Services protokolliert. Metadaten können daher alle Schlüsselattribute erfassen, die zur Erkennung und Verhinderung fortgeschrittener Cyberangriffe beitragen:

• Host- und Server-IP-Adresse, Port-Nummer,
• Informationen zum geografischen Standort,
• DNS- und DHCP-Informationen, die Geräte IP-Adressen zuordnen,
• Webseiten, auf die zugegriffen wird, zusammen mit der URL und Header-Informationen,
• Zuweisung von Benutzern zu Systemen unter Verwendung von DC-Protokolldaten,
• verschlüsselte Websites - Verschlüsselungstyp, Verschlüsselung und Hash,
• Client/Server-FQDN, Objekt-Hashes wie JavaScript und Bilder, usw.

• Eine umfassende Strategie für das Risikomanagement in der Supply Chain, die robuste Gegenmaßnahmen und Praktiken implementiert, einschließlich der Überprüfung und Kontrolle von Drittanbietern.
• Es ist wichtig, ein umfassendes Inventar der in der Infrastruktur des Unternehmens verwendeten Software- und Hardwarekomponenten zu führen. Falls Sie noch nichts davon gehört haben, sollten Sie sich eine Software-Stückliste ansehen und prüfen, welche Ihrer (Sicherheits-)Anbieter diese zur Verfügung stellen.
• Ausserdem ist es wichtig, sich über die neuesten Bedrohungen und Schwachstellen in der Cybersicherheitslandschaft zu informieren und sich an Communities zum Austausch von Bedrohungsdaten zu beteiligen, um Informationen über potenzielle Risiken in der Lieferkette auszutauschen.
• Identifizierung und Dokumentation des Liefernetzwerks und der beteiligten Akteure mit Schwerpunkt auf den relevanten Abhängigkeiten und Risiken, um Transparenz zu schaffen.
• Kategorisierung von Assets, einschließlich Daten, Informationen und IT-Systemen, die mit Dritten geteilt werden, und Erstellung von Zugriffschutzprotokollen.
• Vertragliche Festlegung von Sicherheitsanforderungen und Meldepflichten für Dritte sowie Richtlinien für die Vergabe und Beendigung von Verträgen.
• Überwachung der Leistung von Lieferanten durch routinemässige Sicherheitsaudits, einschliesslich Reifegradbewertungen und Bedrohungsanalysen.
• Festlegung von Verantwortungen für den sicheren Betrieb von Produkten/Dienstleistungen während ihres gesamten Lebenszyklus, einschliesslich Massnahmen nach dem Service. Durch die Festlegung einer Basislinie für das normale Verhalten dieser Partner können alle Abweichungen als potenzielle Risiken erkannt werden.
• Fortschrittliche NDR-Tools können zur Ü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 alle Abweichungen als potenzielle Risiken erkannt werden.

Unternehmen mit Sitz in Deutschland können über das Bundesamt für Sicherheit in der Informationstechnik (BSI) grundlegende Tipps und Reifegrad-Checklisten zur IT-Sicherheit abrufen. Über die Einhaltung von Vorschriften wie der KRITIS Verordnung oder branchenspezifischen Anforderungen wie der UNECE-Regelung Nr. 155 im Automobilbereich hinaus müssen in Deutschland ansässige Unternehmen gemäss § 8b Abs. 4 BSI-Gesetz alle zum Zeitpunkt der Entdeckung eines Vorfalls vorliegenden Erkenntnisse unverzüglich an das BSI melden. Diese Meldepflicht gilt für das einzelne Unternehmen und erstreckt sich über Liefernetzwerke.

Angesichts der Dringlichkeit und Bedeutung des Themas beteiligen sich Regierungen und Behörden weltweit aktiv an der Entwicklung gesetzlicher Anforderungen und Spezifikationen, insbesondere im Hinblick auf Cybersecurity-Bedrohungen in Lieferkettennetzwerken.

Wenn Sie Fragen haben oder weitere Informationen wünschen, zögern Sie nicht, uns zu kontaktieren!