Es scheint kaum eine Woche zu vergehen, ohne dass eine neue Schwachstelle die Anfälligkeit der Softwareabhängigkeiten offenlegt, aus denen die Softwarelieferkette besteht.
Ein großer Teil der Softwareentwicklung nutzt die Vorteile von Open-Source-Plattformen und Drittanbietern für eine pünktliche Bereitstellung. Zahlreiche Personen und Organisationen pflegen diese Codebasen.
Wenn Sie alle Komponenten berücksichtigen, die Sie für Ihre Software benötigen, ergibt sich eine ziemlich lange Kette, und auch diese Komponenten haben Abhängigkeiten. Jede schwache Stelle kann die gesamte Softwarelieferkette kompromittieren und Ihr Unternehmen einem Risiko aussetzen. SolarWinds und Kaseya sind zwei aktuelle, viel beachtete Beispiele für Angriffe auf die Softwarelieferkette, und bei beiden Anbietern wurden infolgedessen Kunden kompromittiert. Das Ausmaß der Abhängigkeiten und Risiken ist enorm.
Komplexe Softwareabhängigkeiten
Moderne Anwendungen haben Hunderte von Abhängigkeiten, darunter zahlreiche Open-Source-Komponenten. Als Entwickler schreiben wir den größten Teil des Codes, der in unserer Software und unseren Anwendungen verwendet wird, nicht selbst. Das kann Sicherheitsrisiken schaffen, da Sie den Code, den Sie nicht selbst geschrieben haben und pflegen, nicht vollständig kontrollieren können.
Sie sind sicher, solange alle Abhängigkeiten sicher sind. Leider sind ungepatchte Schwachstellen in Software ziemlich häufig und führen mitunter zu Angriffen auf die Lieferkette, wenn Hacker sie ausnutzen.
Noch problematischer ist, dass selbst sichere Anbieter durch fehlerhafte Updates verwundbar werden können – und das ist schwer zu erkennen. Bei Angriffen auf die Lieferkette müssen Hacker keinen Commit-Zugriff erlangen, um die Codebasis zu kompromittieren. Ihre CI/CD-Pipelines bringen fehlerhafte Anbietersoftware für sie in die Produktionsumgebung.
Letztlich spielt es keine Rolle, ob die Schwachstelle absichtlich eingebaut wurde, um eine Sicherheitslücke zu verbreiten, oder ob es sich um einen dummen Fehler eines ahnungslosen Entwicklers handelt. Das Ergebnis ist dasselbe.
Lesen Sie auch: SBOMs: Absicherung der Softwarelieferkette
Wie Hacker die Lieferkette kompromittieren
In diesem Jahr veröffentlichte Microsoft ein Whitepaper über eine neue Technik namens Dependency Confusion, auch als Substitutionsangriff bekannt, die sich auf den Prozess der Anwendungserstellung in vertrauenswürdigen Unternehmensumgebungen konzentriert.
Ein Projekt kann seine Komponenten aus mehreren Quellen beziehen. Es gibt sowohl private als auch öffentliche Code-Repositorys.
Wenn Hacker den Namen eines der privaten Repositorys herausfinden, können sie öffentliche Repositorys mit demselben Namen registrieren und ihre Version dessen hochladen, was eigentlich eine interne Bibliothek sein sollte. Der Paketmanager kann durch die mehreren Feeds verwirrt werden und statt des internen Repositorys die öffentliche Version herunterladen, weil das öffentliche Repository die höhere Versionsnummer hat.
Manchmal können Sie die Informationen direkt in der Produktionsumgebung erhalten, zum Beispiel:
https://website.com/package.json
In der Datei package.json speichert npm oder yarn die Namen und Versionen der installierten Pakete. Sie sollte nicht über das Web zugänglich sein. Leider können Hacker auch dann an Informationen gelangen, wenn diese Datei nicht öffentlich zugänglich ist und Entwickler vergessen haben, Source-Map-Dateien in der Produktionsumgebung zu deaktivieren. Diese .map-Dateien werden normalerweise zum Debuggen von JavaScript verwendet und enthalten mehrere Verweise auf node_modules.
Angreifer können auch andere Techniken wie Typosquatting einsetzen. Sie veröffentlichen öffentliche Pakete mit Namen, die bekannten Paketnamen ähneln, und warten darauf, dass Entwickler eine Abhängigkeit in ihrer package.json oder composer.json falsch schreiben.
Eine weitere bekannte Technik besteht darin, manipulierte Pull-Requests einzureichen. Hacker verstecken mitunter Schadcode in scheinbar legitimen Fehlerbehebungen. Maintainer können diese Änderungen prüfen und den Code in den Hauptbranch übernehmen, was zu vergifteten Deployments in der Produktionsumgebung führt.
Unabhängig vom Vorgehen wird die Kompromittierung von Update-Mechanismen bei Angriffen auf die Softwarelieferkette immer häufiger.
Lesen Sie auch: Die besten Tools für Code-Debugging und Codesicherheit
Die Angriffe auf SolarWinds und Kaseya
Im Jahr 2020 kompromittierten hochentwickelte Angreifer erfolgreich Orion, das am weitesten verbreitete SolarWinds-Produkt, um Schadsoftware einzuschleusen, die in einem Update verborgen war. Der Vorfall wurde in SUNBURST umbenannt.
SolarWinds ist ein bedeutender Anbieter von Netzwerkmanagementsystemen mit Hunderttausenden Kunden, darunter das US-Verteidigungsministerium. Die Produkte des Unternehmens automatisieren zahlreiche Aktivitäten, etwa die Verteilung von Updates und Patches an Benutzer. Letztlich waren zwar weniger als 100 Installationen betroffen, doch rund 18.000 waren potenziell für diesen Angriff anfällig.
Durch die Kompromittierung des von Orion verwendeten Update-Kanals mit einer bösartigen, digital signierten .DLL (SolarWinds.Orion.Core.BusinessLayer.dll) gelang es den Hackern, kritische Dokumente aus verschiedenen Behörden und Unternehmen zu exfiltrieren.
Die .DLL blieb tagelang inaktiv und stellte dann eine Verbindung zu mehreren Command-and-Control-Servern her, um zusätzliche Anweisungen wie Dateiübertragungen und Systemaufzählungen zu erhalten. Die Hacker installierten außerdem eine angepasste Version von Cobalt Strike auf den Zielsystemen.
Die US-Regierung schrieb diese Aktivitäten den mit dem russischen Auslandsgeheimdienst (SVR) verbundenen Angreifern zu. Die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) wies Bundesbehörden an, SolarWinds-Produkte zu entfernen und Ermittlungen einzuleiten.
Diese Maßnahme beseitigte die Bedrohung jedoch nicht vollständig, da die Behörden nicht sagen konnten, ob sie ihre Gegner tatsächlich ausgeschaltet hatten oder nicht. Dadurch blieben die Angreifer eine Advanced Persistent Threat (APT).
Im Juli 2021 nahmen Angreifer Kaseya ins Visier. Das Unternehmen bietet verschiedene IT-Produkte an, darunter Tools zur Verwaltung von Netzwerken und Endpunkten, Compliance-Dienste und Automatisierungsplattformen. Zu den zahlreichen Kunden zählen Managed-Service-Provider, die andere Unternehmen betreuen, wodurch Kaseya eine zentrale Rolle in der Lieferkette einnimmt.
Die Bedrohungsgruppe REvil nutzte eine Schwachstelle in einer Weboberfläche aus, über die sich Authentifizierungsprozesse umgehen, Payloads hochladen und manipulierte SQL-Befehle aus der Ferne einschleusen ließen. Jeder mit dem vertrauenswürdigen VSA-Server verbundene Client führt Aufgaben aus, ohne einen Alarm auszulösen oder Anmeldedaten anzufordern. Deshalb nahmen die Hacker Kaseya ins Visier.
Die Ransomware-Gruppe verlangte Bitcoin im Gegenwert von 70 Millionen US-Dollar, um einen Entschlüsseler bereitzustellen und Unternehmen die Wiederherstellung ihrer Dateien zu ermöglichen. Kaseya musste seine Server herunterfahren und Kunden weltweit warnen. Das Unternehmen bat CISA und das FBI um Unterstützung, doch der Schaden war bereits angerichtet.
Lesen Sie auch: Die besten Tools für das Management von Drittanbieterrisiken (TPRM)
So lassen sich Angriffe auf die Lieferkette eindämmen
Aufgrund des weitreichenden Schadens, den eine Bedrohungsgruppe ausgehend von einer einzigen Quelle anrichten kann, wird es auch künftig Angriffe auf die Lieferkette geben. Ebenso dürfte sich die umfangreiche Kette aus Software- und IT-Abhängigkeiten kaum verändern. In einem der wenigen positiven Aspekte sieht ein Branchenbeobachter Verbesserungen bei den Abwehrmaßnahmen, was die Lage etwas entschärfen könnte.
Es gibt keine Möglichkeit, einen Angriff auf die Lieferkette für immer zu verhindern. Das bedeutet jedoch nicht, dass Sie keine vorbeugenden Maßnahmen ergreifen können. Folgende Maßnahmen können helfen:
- Führen Sie eine strengere Anbieterrichtlinie ein. Beziehen Sie nichts aus mehreren privaten Registrys, wenn Sie nur eine verwenden können.
- Wenn Sie ein privates Repository registrieren, registrieren Sie ein öffentliches Repository mit demselben Namen, um Typosquatting zu verhindern.
- Halten Sie sämtliche Software auf dem neuesten Stand, auch wenn nun selbst der Update-Prozess ein Risiko darstellt.
- Sichern Sie alle Konfigurationsdateien ab und spielen Sie sie niemals in der Produktionsumgebung ein – oder beschränken Sie zumindest den Zugriff darauf.
- Seien Sie bei IT-Managementschnittstellen äußerst vorsichtig. Privilegierte Konten mit einem sehr hohen Zugriffslevel sollten nur in geringer Zahl vorhanden sein.
- Setzen Sie mehrere Verteidigungsebenen ein und verwenden Sie Monitoring-Tools wie SIEM oder SOAR, um verdächtiges Verhalten frühzeitig zu erkennen.
- Segmentieren Sie Ihre Netzwerke. Lassen Sie nicht zu, dass ein Sicherheitsverstoß auf niedriger Ebene das gesamte System offenlegt.
Als Nächstes lesen: Die besten IT-Asset-Management-Tools für mehr Sicherheit