Verhindern Sie Angriffe auf die Lieferkette mit dem Build Verifier von Encryption Consulting

Die Codesignierung ist ein entscheidender Mechanismus, um Authentizität und Vertrauen zu gewährleisten und sicherzustellen, dass Software während des Vertriebs nicht manipuliert wird. In der heutigen vernetzten Welt, in der Software die Grundlage bildet, ist die Sicherheit der Software-Lieferkette wichtiger denn je. Jüngste Ereignisse, wie der Angriff auf SolarWinds, haben die Schwachstellen dieser Lieferkette deutlich gemacht und uns eindringlich vor Augen geführt, wie wichtig sichere Codesignierungsverfahren sind. Dieser Blogbeitrag beleuchtet die Feinheiten solcher Angriffe, ihre Durchführung und untersucht proaktive Sicherheitsansätze zur Stärkung der Software-Lieferkette.

Build Verifier verhindert kurz gesagt einen Angriff im SolarWinds-Stil, bei dem Schadcode vor der Codesignierung in den Build eingeschleust wird, sodass das resultierende Artefakt eine gültige Signatur trägt. Build Verifier erkennt dies, indem es die Dateihashes zur Build-Zeit unabhängig neu berechnet und mit den beim Einchecken gespeicherten Hashes vergleicht. Bei jeder Abweichung, auch in Konfigurationsdateien und Abhängigkeiten, schlägt der Build automatisch fehl.

Wichtige Erkenntnisse

• SolarWinds war erfolgreich, weil die Angreifer den Build-Server vor der Signierung kompromittiert hatten, nicht den Signierungsprozess selbst; eine gültige Signatur auf bereits bösartigem Code ist genau das, worauf der Build Verifier abzielt.
• Diese Seite beschreibt eine spezifische Präventivmaßnahme (Hash-Verifizierung zur Build-Zeit). Informationen zum allgemeinen Vorgehen bei Verdacht auf eine Kompromittierung finden Sie unter [Link einfügen]. Stärkung der Sicherheit bei der Codesignierung gegen Integritätslücken.

Was ist der SolarWinds-Angriff?

Der SolarWinds-Angriff war ein massiver Lieferkettenangriff auf die SolarWinds-Orion-Plattform, eine weit verbreitete Software zur Infrastrukturverwaltung, die von großen Unternehmen und Regierungsbehörden eingesetzt wird. Durch die Kompromittierung von SolarWinds während der Softwareentwicklungsphase erlangten die Angreifer Zugang zu den Netzwerken der Plattformkunden, die ihre eigentlichen Ziele darstellten.

Bei einem Supply-Chain-Angriff wird der Schadcode während des Erstellungs- oder Herstellungsprozesses in das Produkt eingeschleust. So können Hacker die Endbenutzer ausnutzen, sobald diese das infizierte Produkt erhalten. In diesem Fall infiltrierten die Angreifer die Software-Updates mit Schadcode, bevor diese im Rahmen der routinemäßigen Wartung an die Kunden verteilt wurden.

Der Vorteil dieser Angriffsstrategie besteht darin, dass sie eine versteckte Hintertür in das Netzwerk jedes Endbenutzers des kompromittierten Produkts schafft. Mit der SolarWinds Orion-Plattform hatten die Angreifer einen noch mächtigeren Einstiegspunkt, da sie sich über die Netzwerke der Benutzer erstreckte und ihnen so erhebliche Kontrolle verschaffte.

Sobald die Hacker eingedrungen waren, konnten sie zusätzliche Schadsoftware einsetzen, um ihre Fähigkeiten zu erweitern, den Angriff zu intensivieren und unentdeckt zu bleiben. Dieser Angriff hatte weitreichende Auswirkungen und betraf zahlreiche Organisationen, die für ihre Geschäftstätigkeit auf SolarWinds Orion angewiesen waren. Dadurch wurden sensible Daten gefährdet.

Wie wurde der SolarWinds-Angriff durchgeführt?

Der Angriff auf SolarWinds begann am 20. Februar 2020 mit dem Einschleusen von Schadcode in Software-Updates. Bis zum 26. März 2020 wurden manipulierte Updates an SolarWinds-Kunden verteilt und installierten die Sunburst-Hintertür in deren Netzwerken. Über diese Hintertür erlangten die Angreifer direkten Zugriff. SolarWinds nutzte zwar Codesignierung, doch die Angreifer schleusten den Schadcode während der Entwicklung ein und umgingen so die Codesignierung . Sunburst kommunizierte mit den Servern der Angreifer, getarnt als legitimer Datenverkehr. Anschließend setzten die Angreifer die Malware Teardrop und Raindrop ein, um den Angriff auf ausgewählte Opfer auszuweiten. Der Angriff hatte erhebliche Auswirkungen auf Unternehmen, die auf SolarWinds Orion angewiesen waren.

Lassen Sie uns jede dieser Komponenten Schritt für Schritt besprechen:

1. Sunspot-Malware

   Sunspot, im September 2019 eingesetzt, war die erste Schadsoftware, die beim SolarWinds-Angriff zum Einsatz kam. Ihr einziger Zweck bestand darin, heimlich eine bösartige Hintertür in den Orion-Quellcode von SolarWinds einzuschleusen und so unbemerkt auf dem Build-Server zu agieren. Sobald Sunspot die Orion-Build-Befehle erkannte, ersetzte es den legitimen Code stillschweigend durch die kompromittierte Version.

2. Sunburst-Backdoor-Malware

   Sunburst, die primäre Backdoor-Malware, befand sich in der DLL-Datei „SolarWinds.Orion.Core.BusinessLayer.dll“. Ihre Funktion bestand darin, die Kommunikation mit den Servern der Angreifer über HTTP herzustellen. Sie war in einer trojanisierten Version einer Windows Installer-Patch-Datei versteckt und existierte neben legitimen Update-Dateien. Sunburst blieb nach der Installation zwei Wochen lang im Ruhezustand, um nicht entdeckt zu werden, und wurde dann aktiviert, um mit der Domäne der Angreifer zu kommunizieren. Die Kommunikation wurde als SolarWinds-API-Verkehr getarnt und zeichnete sensible Netzwerkdaten des Opfers auf.

3. Die Solorigate-DLL-Datei

   Die Angreifer betteten den Code von Sunburst in eine DLL-Datei ein und nannten sie „OrionImprovementBusinessLayer“, um sie optisch zu unterdrücken. Diese Klasse enthielt die komplette Backdoor-Funktionalität und war auf geringes Gewicht und Unauffälligkeit ausgelegt. Sie wurde in die Methode „RefreshInternal“ integriert, um einen regelmäßigen Aufruf ohne Unterbrechung des normalen Betriebs zu gewährleisten.

4. Träne & Regentropfen

   Nach der ersten Erkundung mit Sunburst setzten die Angreifer zusätzliche Schadsoftware, Teardrop und Raindrop, ein und zielten auf bestimmte Opfer ab, die für eine Eskalation geeignet erschienen.

Die SolarWinds-Angreifer verfolgten einen ausgeklügelten Plan, um den Build-Server vor der Code-Signierung zu kompromittieren und den Schadcode einzuschleusen. Die Infiltration des Build-Servers verschaffte ihnen einen strategischen Ansatzpunkt, um den Software-Update-Prozess zu manipulieren und den Schadcode vor der kritischen Code-Signierung einzuschleusen. Dadurch blieben die Angreifer unentdeckt, da der kompromittierte Code die Signatur eines gültigen SolarWinds-Zertifikats trug und so eine trügerische Fassade der Authentizität schuf.

Welche Methoden gibt es, um einen solchen Angriff erfolgreich auszuführen?

Lassen Sie uns verschiedene Strategien verstehen, die eingesetzt werden können, um ähnliche Angriffe durchzuführen und die Software-Lieferkette zu kompromittieren.

1. Unbefugter Zugriff auf Code-Signaturschlüssel

   Diese Taktik beinhaltet den Erwerb der kryptografischen Schlüssel, die zum Signieren von Softwarecode verwendet werden. Diese Schlüssel versichern den Nutzern, dass die heruntergeladene Software nicht manipuliert wurde. Durch den Diebstahl dieser Schlüssel können Angreifer ihren Schadcode signieren und ihn so für Nutzer und Sicherheitsprüfungen echt und vertrauenswürdig erscheinen lassen.

2. Einbruch in den Build-Server, wie beim SolarWinds-Vorfall beobachtet

   Der Build-Server war ein kritisches Ziel des SolarWinds-Angriffs. Angreifer infiltrierten diesen Server, der für die Kompilierung und Verpackung von Software-Updates zuständig ist. Durch die Kompromittierung des Build-Servers erlangten sie die Kontrolle über den Software-Update-Prozess und konnten so vor der Codesignatur Schadcode einschleusen. Diese Manipulation ermöglichte es ihnen, schädliche Updates an ahnungslose Benutzer zu verteilen.

3. Einschleusen von Malware direkt in das Quellcode-Repository (schwierig, da sie dauerhafte Spuren hinterlässt)

   Das direkte Einschleusen von Malware in ein Quellcode-Repository ist eine Herausforderung, da es oft erkennbare Spuren hinterlässt. In diesem Repository speichern und verwalten Entwickler den Quellcode von Softwareprojekten. Unbefugte Änderungen, einschließlich des Einschleusens von Malware, können potenziell identifiziert und zum Angreifer zurückverfolgt werden. Daher ist diese Methode riskanter und wird eher erkannt.

4. Angriff auf die Workstation des Entwicklers

   Ein anderer Ansatz besteht darin, die Workstation eines Entwicklers zu kompromittieren. Entwickler verwenden diese Maschinen zum Schreiben, Testen und Entwickeln von Code. Erhält ein Angreifer Zugriff auf die Workstation eines Entwicklers, kann er den Code manipulieren, bevor er im Repository gespeichert wird. Diese Taktik kann schwer zu erkennen sein, wenn keine robusten Endpunkt-Sicherheitsmaßnahmen vorhanden sind.

Strategien zum Schutz vor solchen Angriffen

Um ähnliche Angriffe zu verhindern, können folgende Ansätze verfolgt werden:

1. Hash-Validierung

   Die Methode der Hash-Validierung ist ein zentraler Schutz gegen Supply-Chain-Angriffe wie den SolarWinds-Angriff. Sie dient als strenger Gatekeeper im Softwareentwicklungsprozess und stellt sicher, dass der zu signierende Code mit dem sicher im Quellcode-Repository gespeicherten Code übereinstimmt. Bei dieser Sicherheitsmaßnahme generiert der Build-Server einen Code-Hash, der dann vom Signaturserver überprüft wird.

   Der Signaturserver überprüft die Integrität des Codes selbstständig, indem er einen deterministischen Build im Quellcode-Repository initiiert und die Hashes vergleicht. Nur wenn diese Hashes übereinstimmen, autorisiert der Signaturserver die Code-Signatur und bietet so eine robuste Sicherheitsebene, die vor unbefugten Codeänderungen schützt.

2. Build-Verifizierer

   Eine zusätzliche Präventivmaßnahme gegen solche Angriffe ist ein strenges Hash-Validierungssystem, das nahtlos in die Softwareentwicklungspipeline integriert ist. Der Prozess beginnt mit der Berechnung von Dateihashes, sobald Code in einen bestimmten Release-Branch eingecheckt wird. Diese Hashes werden mithilfe von CodeSign Secure von Encryption Consulting sicher in einer verschlüsselten Datei gespeichert . Wenn der Build-Server anschließend einen Build vom entsprechenden Branch initiiert, ruft er den Code ab, berechnet die Hashwerte aller Dateien und speichert sie in einer Textdatei. Ein Build-Verifizierungsmodul vergleicht diese Hashwerte dann mit den sicher im Repository verschlüsselten Werten.

   Der Build wird erfolgreich ausgeführt, wenn für alle Hashwerte eine Übereinstimmung gefunden wird. Abweichungen in den Hashwerten veranlassen den Build Verifier jedoch, den Build als Fehler zu markieren, den Prozess sofort zu stoppen und Benachrichtigungen über die CI/CD-Pipeline auszulösen. Dieser robuste Ansatz gewährleistet eine strenge Überprüfung der Codeintegrität in mehreren Phasen und erhöht so die Sicherheit der Software-Lieferkette erheblich.

Wie kann der Build Verifier von Encryption Consulting dies verhindern?

Der Build Verifier von Encryption Consulting spielt eine zentrale Rolle bei der Gewährleistung der Integrität des Build-Prozesses. Er erkennt diese Änderung umgehend und stuft den jeweiligen Build als FEHLER ein. Anschließend werden Benachrichtigungen generiert und an die betroffenen Parteien gesendet, um sofortige Korrekturmaßnahmen einzuleiten. Diese Funktion unterstreicht die Effektivität des Build Verifiers von Encryption Consulting bei der Gewährleistung der Sicherheit und Zuverlässigkeit der Softwareentwicklungspipeline.

Während die konventionelle Methode der Hash-Validierung zweifellos ein wertvoller Schutzmechanismus gegen Supply-Chain-Angriffe ist, hebt der Build Verifier von Encryption Consulting die Softwaresicherheit auf ein umfassenderes Niveau. Beide Ansätze haben das gemeinsame Prinzip, die Codeintegrität durch Hash-Abgleich sicherzustellen. Der entscheidende Unterschied liegt jedoch im Umfang der jeweiligen Überwachung. Der konventionelle Ansatz konzentriert sich primär auf den Code und überprüft, ob dieser mit der Version des Repositorys übereinstimmt.

Konventionelle Hash-Validierung vs. Build-Verifizierer

	Konventionelle Hash-Validierung	Build-Verifizierer
Geltungsbereich	Nur Quellcode	Code, Konfigurationsdateien und Abhängigkeiten
Überprüfungsmethode	Der Signaturserver erstellt und vergleicht Hashes unabhängig.	Die beim Einchecken berechneten Hashwerte werden mit den beim Build-Prozess neu berechneten Hashwerten verglichen.
Ausfallverhalten	Die Unterzeichnung wird aufgrund von Unstimmigkeiten verweigert.	Der Build wurde als FEHLGESCHLAGEN markiert und die CI/CD-Pipeline sendet sofort Benachrichtigungen.
Erkennt eine Kompromittierung eines Build-Servers im SolarWinds-Stil	Ja, für Quellcodeänderungen	Ja, einschließlich Änderungen, die in Konfigurationsdateien oder Abhängigkeiten versteckt sind und bei einer reinen Codeprüfung möglicherweise übersehen werden.

Häufig gestellte Fragen

Hätte Build Verifier speziell den SolarWinds-Angriff erkannt?

Die Angreifer von SolarWinds manipulierten die Build-Ausgabe direkt auf dem kompromittierten Build-Server, bevor sie diese signierten. Eine Hash-Abweichung zwischen dem eingecheckten Code und der Berechnung zur Build-Zeit ist genau die Diskrepanz, die der Build-Verifizierer erkennen soll. Dadurch schlägt der Build fehl und die Pipeline wird benachrichtigt, anstatt ein gültig signiertes, aber manipuliertes Artefakt durchzulassen.

Ersetzt Build Verifier die Notwendigkeit eines HSM-gestützten Schlüsselspeichers?

Nein, sie decken unterschiedliche Risiken ab. Die HSM-gestützte Schlüsselspeicherung verhindert Zertifikatsdiebstahl; der Build-Verifizierer verhindert, dass ein kompromittierter Build jemals den Signierschritt mit einer gültigen Signatur erreicht. Beide Kontrollmechanismen ergänzen sich, sie ersetzen sich nicht.

Fazit

Angesichts des SolarWinds-Angriffs, der Schwachstellen in der Software-Lieferkette aufgedeckt hat, ist es unerlässlich, proaktive Sicherheitsmaßnahmen zu prüfen. Angreifer führen solche Angriffe durch, indem sie Build-Server vor dem Code-Signatur-Prozess gezielt kompromittieren, Schadcode in Software-Updates einschleusen und durch gültige Signaturen der Erkennung entgehen.

Zusammenfassend lässt sich sagen, dass der Schutz der Software-Lieferkette innovative Ansätze wie den Build Verifier von Encryption Consulting erfordert, um Vertrauen in die digitale Welt zu schaffen. Angesichts der sich ständig weiterentwickelnden Cyberbedrohungen ist es unerlässlich, immer einen Schritt voraus zu sein. Der Build Verifier ist ein Beleg für proaktive Sicherheit in einer komplexen Cybersicherheitslandschaft.