Akteure, Taktiken und Abwehr von Supply Chain Attacks – Teil 2 Die Verteidigung der Softwarelieferkette

Nachdem wir im ersten Teil die Gefahren, Akteure und vielfältigen Eintrittsvektoren von Supply-Chain-Angriffen skizziert haben, gehen wir nun ins Detail und widmen uns der Verteidigung. Asaf Karas von Vdoo zeigt, wie man Risiken fundiert bewertet und Bedrohungen effektiv abwehrt. Hierbei helfen insbesondere Zehn Best Practices samt praktikabler Vorkehrungen und Methoden.

Im ersten Teil dieser Miniserie haben wir gelernt: Cybersicherheitsrisiken in der Lieferkette sind die Folge von Schwachstellen oder Sicherheitslücken, die absichtlich (bei einem Supply-Chain-Angriff) oder auch unbeabsichtigt über den Erwerb von Software und Hardware in ein Unternehmen gelangen. Wenngleich sich Angriffswege und -vektoren dabei ausgesprochen vielseitig gestalten, gibt es praktikable Vorkehrungen und Methoden, um die Risiken zu senken.

Zu betrachten ist dabei das „Wie“ einer Supply Chain Attack. Angriffe auf die Software-Lieferkette ähneln zwar in vielerlei Hinsicht anderen Cyberangriffen. Dennoch gibt es aber...

Drei recht typische Risiken für die Lieferkette:

• 1. Fehlende Transparenz – Zu viele Firmen haben kaum eine Ahnung davon, welche Software und Software-Komponenten sie genau einsetzen und wo.

• 2. Versteckte Abhängigkeiten – Selbst, wenn ein Unternehmen den Einsatz von Open Source-Komponenten nachvollzieht, unter der Oberfläche sind es immer mehr als erwartet. Dazu kommt, dass Open Source-Komponenten permanent geforkt und in verschiedensten Projekten benutzt werden, um neue Software zu entwickeln. Dadurch entstehen vielfältige Ebenen und Abhängigkeiten, die potenziell Schwachstellen enthalten.

• 3. False Positives – Unternehmen werden von irrelevanten Schwachstellenalarmen bei Third-Party Software regelrecht überflutet. Aber selbst, wenn es sich um einen berechtigten Hinweis auf eine Schwachstelle handelt, muss die noch nicht zwingend ganz oben auf der Prioritätenliste stehen.

Zero-Day-Schwachstellen

Wie bei anderen Cyberattacken auch, nutzen die Angreifer Schwachstellen in den Systemen der Opfer aus. Das sind beispielsweise Zero-Day-Schwachstellen. Sie sind bis dato unbekannt und können auf unterschiedliche Weise ausgenutzt werden – sei es um remote Schadcode auszuführen, an vertrauliche Informationen zu gelangen oder eine Denial-of-Service-Attacke zu starten. Sobald Zero-Day-Schwachstellen veröffentlicht oder ausgenutzt werden, bekommen sie normalerweise eine CVE-Identifikationsnummer (Common Vulnerabilities and Exposures). Zu diesem Zeitpunkt sind bereits technische Details bekannt, und Angreifer können einen entsprechenden Exploit entwickeln. Deshalb sollte man solche Schwachstellen zügig ausfindig machen und über Patches, Upgrades oder Konfigurations- oder Code-Änderungen beheben. Besonders risikoträchtig ist es, Softwarepakte von Dritten zu verwenden, die nicht mehr unterstützt werden. Ohne das Engagement der Community ist es unwahrscheinlich, dass bei diesen Paketen der Code aktualisiert und Sicherheitsprobleme behoben werden. Nicht selten stehen die Nutzer ohne Support da und müssen sich auf selbst erstellte Patches verlassen oder Pakete komplett austauschen.

Backdoors und Bugdoors – eine unheilige Allianz

Eine weitere Methode, sich versteckt Zugriff auf Systeme zu verschaffen sind Backdoors. Es gibt viele Formen von Backdoors und noch mehr Möglichkeiten, sie über Code oder die Konfiguration zu implementieren. Eine gängige, codebasierte Backdoor umgeht die Authentifizierung bei benutzerdefinierten Authentifizierungsmechanismen, die im Code implementiert sind.

Eine andere Form der Backdoor nutzt Auto-Update-Techniken für Code, mit denen man beliebige Codepakete (Shellcode, Shared Objects oder DLLs) von einem Remote-Server herunterladen und ausführen kann. Dazu muss man nicht mehr direkt über die offenen Management-Schnittstellen auf das Gerät zuzugreifen. Stattdessen wird die Backdoor „huckepack“ zum Angreifer gebracht. 

Bugdoors hingegen sind ein spezifischer Typ von Backdoor beziehungsweise Schwachstelle. Eine Bugdoor ist ein Softwarefehler, der wie eine Backdoor funktioniert, die später von jedem ausgenutzt werden kann, der sie in Code oder Hardware hinterlassen hat. Solche Bugdoors haben potenziell schwerwiegende Folgen, weil ein Angreifer so das Verhalten einer Soft- oder Hardware verändern kann. Der offensichtliche Vorteil einer Bugdoor als Backdoor: Die böse Absicht lässt sich leicht bestreiten, denn wo sind schon keine Fehler im System? Es ist sehr viel schwieriger zu unterscheiden, ob ein sicherheitsrelevanter Fehler unbeabsichtigt oder mit einer böswilligen Intention aufgetreten ist. Verglichen mit offensichtlichen Backdoors (wie fest codierte Anmeldeinformationen oder Dropper-Techniken) wie wir sie bei einigen der jüngsten Supply-Chain-Angriffe beobachten konnten, ist dieser Ansatz deutlich intelligenter.

Gängige Angriffsvektoren bei Supply-Chain-Angriffen

So vielfältig wie das „Wie“ eines Angriffs sind auch die einzelnen Angriffsvektoren. Anfällige Open Source-Komponenten sind am häufigsten für Exploits in der Lieferkette verantwortlich. Unternehmen wissen im Allgemeinen nicht, welche Fremdkomponenten sie in ihrer Software verwenden. Kommerzielle Software verbirgt den Code absichtlich, während Open Source-Komponenten mehrere Abhängigkeitsebenen aufweisen. Die meisten Entwickler verfolgen die genutzten Open Source-Komponenten nicht nach, geschweige denn recherchieren sie die direkten oder transitiven Abhängigkeiten. Hacker können beispielsweise Repositories dieser Abhängigkeiten kompromittieren und Schwachstellen in Komponenten einschleusen, die Entwickler nichtsahnend in proprietäre Produkte mitnehmen.

Aber auch die Vielzahl der vernetzten Geräte ist ein beliebtes Einfallstor. Drucker sind eines der Standardbeispiele. Ein weiterer Klassiker sind kompromittierte Update-Server wie im Falle des SUNBURST-Angriffs. Bei diesem Angriffsvektor werden Software-Updates benutzt, um Schadcode in das Unternehmen einzuschleusen und zu verteilen. Die Payload wird in Update-Pakete verborgen, vorzugsweise bevor diese kryptografisch signiert sind, damit sie über gültige Signaturen verfügen.

Auch White-Label-Geräte sind gängige Praxis in der Embedded-Industrie. Hardware-Komponenten und ganze Geräte werden neu verpackt, gebrandet und unter dem Namen des Anbieters oder Vertriebsunternehmens weiterverkauft. Meistens, ohne dass der ursprüngliche Hersteller genannt wird. Die Software in diesen Geräten kann proprietär oder Open Source sein, aber jede Schwachstelle, die vom Hersteller in diese Geräte eingebracht wird, verbreitet sich zuverlässig auf den Rest der Lieferkette. 

Alle geschilderten Szenarien und Vektoren auch in Kombination miteinander auftreten und die Bedrohungslage noch komplexer gestalten. Folgende Ansätze können jedoch das Risiko eines Supply-Chain-Angriffs senken.

Top 10 der Best Practices gegen Supply-Chain-Angriffe

1. Überprüfungsprozesse innerhalb der Lieferkette einführen

Machen Sie das Thema zum zentralen Element des gesamten Sicherheitsprozesses. Führen Sie Gespräche mit Ihren Lieferanten und stellen Sie sicher, dass sie den vorgegebenen Standards Ihres Unternehmens folgen. Fragen Sie konkret nach, was Ihre Lieferanten tun, um Sicherheitsprozesse zu verbessern und arbeiten Sie gemeinsam daran. Das Sicherheitsmanagement innerhalb der Lieferkette sollte ein ständiger Dialog im Tandem mit entsprechenden Kontrollmechanismen sein.

2. Integritätsprüfung für Binärcode implementieren

Überprüfen Sie heruntergeladene Software, indem Sie die Binärdatei hashen und mit dem vom Hersteller bereitgestellten Hash vergleichen. Diese Methode kann gegen MITM (Man-in-the-Middle)-Angriffe und bestimmte Lieferketten-Angriffe sehr effektiv sein. Beachten Sie, dass einige Paketmanager wie npm (für Node.js), NuGet (für .NET) und pip (für Python) eine automatische Integritätsprüfung heruntergeladener Pakete vor der Installation ermöglichen. 

3. SBOM anfordern und analysieren

Um bekannte oder potenzielle Schwachstellen zu identifizieren, brauchen Sie zwingend eine Software Bill of Materials (SBOM). Dies ist nur mit der vollen Kooperation des Anbieters möglich, der die SBOM zur Verfügung stellt, oder über automatisierte Scan-Tools, die die SBOM aus einem binären Image oder Artefakt des Anbieters kompilieren. 

4. Netzwerkbasierte Risikobewertungen durchführen

Netzwerk-Scans lassen sich in einigen Situationen verwenden, um anfällige Software-Komponenten zu erkennen. Ein Netzwerk-Fingerprinting wiederum hilft, anfälligen Code zu erkennen. Es gibt auch kommerzielle Tools, die diese Funktionen bieten. Meistens kommen aber FOSS-Tools direkt aus der InfoSec-Community oder von Schwachstellenforschern. Leider ist es nicht ganz einfach, Schwachstellen oder anfällige Versionen allein durch Netzwerküberprüfungen genau zu erkennen. Die Netzwerküberwachung kann aber dazu beitragen, tatsächliche Einbrüche zu identifizieren. So gelang es auch den SolarWinds SUNBURST-Angriff abzufangen.

5. Abhilfemaßnahmen mit kontextbezogener Bedrohungsanalyse priorisieren

Es ist wichtig, sich auf die Bedrohungen zu konzentrieren, die für eine bestimmte Umgebung und ihre spezifischen Bedingungen von Bedeutung sind. Verwenden Sie Lösungen für das Schwachstellen-Management und Software Composition Analysis, die neue Bedrohungen kontinuierlich überwachen und priorisieren, indem Sie Schwachstellen im Kontext ihrer Umgebung analysieren. Unabhängig davon, ob es ein Gerät, ein Server, ein Netzwerk oder in der Cloud ist. Das senkt die Zahl der False Positives.

6. Kontinuierlich beheben

Softwareschwachstellen müssen regelmäßig behoben werden. Wo möglich, sollten Sie eine Software gemäß Best Practices auf neue und gefixte Versionen aktualisieren. Wo das nicht möglich ist, sollte die Software gepatcht werden. Andernfalls lassen sich einige Schwachstellen durch die Isolierung der anfälligen Software abschwächen, entweder durch Sicherheitsmechanismen des Betriebssystems wie restriktive Container oder durch externe Dienste wie Firewalls.

7. MFA (Multi-Faktor-Authentifizierung) in kritischen Abschnitten des Software Development Lifecycle (SDLC) durchsetzen

Alle Komponenten der Entwicklungspipeline, die eine Authentifizierung erfordern oder unterstützen, sollten MFA verwenden. Das verhindert Angriffe, bei denen Anmeldeinformationen wie Benutzernamen und Passwörter gestohlen werden, sei es hartkodiert in Skripten oder durch einen gezielten Spear-Phishing-Angriff auf einen Entwickler. Jede Pipeline hat ihre spezifischen Merkmale und Komponenten und verdient eine eigene Bedrohungsanalyse, aber für einige Elemente des Entwickler-Ökosystems ist MFA ein MUSS.

Diese sollten ganz oben auf der Liste stehen:

• Kontrollsysteme für die Quellcodeversion (z. B. Gitlab oder Github) 

• Paket-Registries (z. B. npmjs) 

• Container-Registries (z. B. DockerHub, AWS ECR, Azure Container Registry) 

• Artefakt-Repositories (z. B. Artifactory oder Azure Artifacts) 

• CI/CD und Pipelines (z. B. Jenkins) 

• Build- und Entwickler-Maschinen

• Sichere interne Abhängigkeiten

8. Dependency Confusion-/Namesquatting- und Typosquatting-Angriffe gegen Entwickler vermeiden 

Verringern Sie die Wahrscheinlichkeit, dass Ihr Entwicklerteam einem dieser so lästigen wie riskanten Angriffe ausgesetzt ist, indem Sie eine Standard-Registry festlegen. Unternehmen, die eine interne, private Registry haben, sollten die Projekte in ihrer DevOps-Infrastruktur so konfigurieren, dass sie standardmäßig ihre Registry verwenden. Je nach verwendeter Sprache und Paketmanager gibt es unterschiedliche Konfigurationen.

9. Version-Pinning verwenden

Es ist ratsam, die zu installierenden Pakete in Bezug auf eine bestimmte Version so präzise wie möglich anzugeben, um Downgrade-Angriffe zu vermeiden. 

10. Ausführen bei Installation deaktivieren

Bei einigen Paketmanagern ist es möglich, die Installation von Quelldistributionen zu verhindern (Flag -only binary von pip) oder beliebige Installationsbefehle zu deaktivieren (Flag --ignore-scripts von npm). Damit wird die Ausführung während der Installation verweigert. Dies verhindert zwar nicht unbedingt die Ausführung von Code, wenn das Paket für die Produktion bereitgestellt wird. Es verhindert aber, dass der Code sofort auf dem Rechner eines Entwicklers ausgeführt wird.

Fazit

2017 traf der NotPetya-Angriff ukrainische Ziele und verbreitete sich schnell über den ganzen Globus. Die Folge waren Schäden in Milliardenhöhe. Seither warten Sicherheitsexperten auf den nächsten großen Lieferketten-Angriff. SolarWinds hat gezeigt, wie anfällig Behörden und Unternehmen sind, wenn die Software, die sie von externen Anbietern beziehen, unzureichend geschützt ist. In den kommenden Monaten werden wir vermutlich deutlich mehr Supply-Chain-Angriffe beobachten.

Stellungnahme des BSI

USA und UK warnen vor russischen Cyber-Angriffen

Die Verbreitung von eingebetteten Geräten hat die Bedrohungsoberfläche vergrößert und zu einem Anstieg bei Hardware-Angriffen geführt. Sie sind schwieriger auszuführen, aber auch schwieriger zu erkennen. Worauf also sollten Sicherheitsexperten angesichts dieser Herausforderungen achten?

Ein vielversprechender Ansatz ist der von der Community vorangetriebene „CycloneDX SBOM-Format Standard“. Der Standard soll die Erstellung und Nutzung digitaler Stücklisten vereinfachen und damit die Kommunikation und Koordination zwischen den Unternehmen erleichtern. Wir gehen davon aus, dass der nächste Schritt darin besteht, diese digitale SBOM in die (signierte) Binärdatei selbst einzubetten, so dass sie einfach wie Metadaten genutzt werden kann. Das bedeutet mehr Transparenz und vereinfacht einen komplexen, verteilten Prozess.

Über den Autor: Asaf Karas ist CTO und Mitgründer von Vdoo.

(ID:47493255)