Codesignatur ist ein entscheidender Mechanismus, um Authentizität und Vertrauen zu schaffen und sicherzustellen, dass Software während der Verteilung nicht kompromittiert wird. In der heutigen vernetzten Welt, in der Software die Grundlage bildet, war die Sicherheit der Software-Lieferkette noch nie so wichtig. Jüngste Ereignisse, wie der SolarWinds-Angriff, haben die Schwachstellen aufgezeigt, die in dieser Lieferkette ausgenutzt werden können, und sie erinnern eindringlich daran, wie wichtig der Schutz von Code-Signierungspraktiken. Dieser Blog befasst sich mit den Feinheiten solcher Angriffe, beleuchtet ihre Ausführung und untersucht proaktive Sicherheitsansätze zur Stärkung der Software-Lieferkette.
Was ist der SolarWinds-Angriff?
Der Angriff auf SolarWinds war ein massiver Supply-Chain-Angriff Der Angriff zielte auf die SolarWinds Orion-Plattform ab, eine von großen Unternehmen und Behörden häufig genutzte Software zur Verwaltung von Infrastrukturen. Durch die Kompromittierung von SolarWinds während der Softwareentwicklungsphase verschafften sich die Angreifer Zugriff auf die Netzwerke der Plattformkunden, die ihr eigentliches Ziel waren.
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 Einfügen von Schadcode in Software-Updates. Bis zum 26. März 2020 wurden kompromittierte Updates an SolarWinds-Kunden verteilt und installierten die Sunburst-Hintertür in deren Netzwerken. Über diese Hintertür verschafften sich die Angreifer direkten Zugriff. SolarWinds nutzte Code Signing, doch die Angreifer fügten den Schadcode während der Entwicklung ein und umgingen CodesignaturSunburst kommunizierte getarnt als legitimer Datenverkehr mit den Servern der Angreifer. Die Angreifer setzten dann die Schadsoftware 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:
-
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.
-
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.
-
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.
-
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.
-
Unbefugter Zugriff auf Code-Signaturschlüssel
Diese Taktik beinhaltet den Erwerb der kryptografische Schlüssel Wird zum Signieren von Softwarecode verwendet. Diese Schlüssel geben Benutzern die Sicherheit, dass die heruntergeladene Software nicht manipuliert wurde. Durch den Diebstahl dieser Schlüssel können Angreifer ihren Schadcode signieren, sodass dieser für Benutzer und Sicherheitskontrollen authentisch und vertrauenswürdig erscheint.
-
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.
-
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.
-
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:
-
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.
-
Build-Verifizierer
Eine zusätzliche Schutzmaßnahme gegen solche Angriffe ist ein rigoroses Hash-Validierungssystem, das nahtlos in die Softwareentwicklungs-Pipeline integriert ist. Der Prozess beginnt mit der Berechnung von Datei-Hashes, sobald Code in einen bestimmten Release-Zweig eingecheckt wird. Diese Hashes werden sicher in einer verschlüsselten Datei gespeichert. CodeSign Secure von Encryption Consulting. Wenn der Build-Server anschließend einen Build aus dem angegebenen Branch initiiert, ruft er den Code ab, berechnet Hashwerte für alle Dateien und speichert sie in einer Textdatei. Ein Build-Verifier-Modul vergleicht diese Hashwerte dann mit den im Repository sicher 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.
Der Build Verifier von Encryption Consulting bietet eine umfassendere Verteidigungsstrategie. Er prüft den Code und dehnt sein wachsames Auge auf wichtige Konfigurationsdateien und Abhängigkeiten aus. Dieser erweiterte Umfang ermöglicht es, subtile Änderungen zu erkennen, die bei der herkömmlichen Hash-Validierung möglicherweise unbemerkt bleiben.
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.
