Schwachpunkte der Sicherheit in einer Supply Chain

Originalartikel von David Fiser, Senior Cyber Threat Researcher

 

 

 

 

 

Der inzwischen berüchtigte Fall Orion Solar Winds hat sowohl in der Cybersicherheits-Community als auch in der Öffentlichkeit für viel Aufsehen gesorgt, und auch die weltweiten Angriffe auf die Supply Chain sind stärker in den Fokus gerückt. Die Attacken selbst sind nicht neu, es gibt sie schon seit einiger Zeit, und sie entwickeln sie sich zu immer fortschrittlicheren Formen weiter. Wo liegen also die Schwachpunkte bei der Sicherheit der Supply Chain?

Unter Supply Chain versteht man ganz allgemein „einen Prozess, um ein Produkt zum Verbraucher zu bringen“. In der IT-Welt ist das eine entwickelte Software. Softwareentwickler sollten unabhängig von der eingesetzten Methodik komplexe Projekte in einfachere Aufgaben aufteilen. Dadurch können Aufgaben definiert und bestimmten Entwicklern zur Nachverfolgung von Problemen zugewiesen werden. Dann schreiben die Entwickler ein Stück Code, das sie testen und die Änderungen ins Source Code Management (SCM) übertragen. Der Code wird von einer Continuous-Integration- und Continuous-Delivery  (CI/CD)-Pipeline verarbeitet, die bestimmte Aufgaben ausführt, um Builds, Tests oder das endgültige Deployment der Projektauswahl durchzuführen.

Bild 1. Ablauf des Entwicklungsprozesses

Jeder Schritt innerhalb des definierten Supply Chain-Prozesses hat seine eigenen Sicherheitsrisiken und Auswirkungen. Zum Beispiel könnten Sicherheitsverletzungen mit böswilligen Benutzern von Software zur Nachverfolgung von Problemen (Issue-tracking Software) anfangen. Der Täter könnte ein verärgerter Insider sein, der sich sichere Informationen zunutze macht, oder auch jemand, der eine Schwachstelle missbraucht. In diesen Szenarien sind die Auswirkungen höchstwahrscheinlich gering, da es viele andere Schritte innerhalb der Supply Chain gibt. Dieses Szenario beinhaltet eine Ausnahme – die Authentifizierung.

Da die Stärke der gesamten Supply Chain von ihrem schwächsten Glied definiert wird, bedeutet das Nichtbeachten von Best Practices (z. B. die Wiederverwendung von Passwörtern oder das Fehlen geeigneter Authentifizierungsmechanismen), dass der böswillige Akteur Zugang zu Systemen erhalten kann, die, wenn exponiert, größeren Schaden nehmen.

Entwickler und das SCM

Der Entwickler stellt einen integralen Teil der Supply Chain dar, denn es bedarf einer Person zum Erstellen von Code. Der menschliche Faktor muss als Schwachstelle und mögliches Sicherheitsrisiko betrachtet werden. Natürlich soll er nicht durch Maschinen ersetzt werden, sondern er sollte eher über die Risiken aufgeklärt werden, die er eingeht.

Kürzlich haben Forscher Bedrohungsakteure identifiziert, die auf Schwachstellenforscher abzielten. Aus technischer Sicht ist es interessant, dass diese Bedrohung in einer Visual Studio-Projektdatei versteckt war – und zwar innerhalb des Prebuild-Ereignisses – und eine PowerShell-gesteuerte Payload auslöste. Aus diesem Szenario lassen sich zwei Schlüsse ziehen. Der erste betrifft den Grad des Vertrauens zwischen „Kollegen“ und der zweite (trifft am meisten auf Entwickler zu) ist eine bessere Übernahme von Quellcode und die Integration von Drittanbieterprojekten. Teams sollten darauf achten, welchen Quellcode und welche Projekte sie integrieren. Nötig ist eine Überprüfung der Quelle des verwendeten Codes, der Software, der Plugins oder der Container. Mehr dazu auch unter „Sicherheit für Online-Entwicklungsplattformen“.

Der Entwickler hat auch Zugriff auf den nächsten Teil der Supply Chain, das SCM. Dabei geht es um Anmeldeinformationen, und da die wiederholte Eingabe von Anmeldeinformationen für den Zugriff mühsam ist, werden sie gespeichert. Damit aber besteht das Risiko von Anmeldeinformationslecks, und die Auswirkungen sind größer, wenn sie in unverschlüsselter Form gespeichert sind.

Entwickler sollten auch keine hart codierten Anmeldeinformationen ins SCM legen, etwa wenn sie Infrastructure as Code (IaC) einsetzen.

CI/CD -Pipeline

Ein weiterer Teil der Supply Chain ist die CI/CD-Pipeline. Hier gibt es einen harten Konkurrenzkampf zwischen den Softwareanbietern. Dazu gehören Jenkins, GitLab, TeamCity, Azure DevOps und andere. Die Pipeline innerhalb der CI/CD-Software lässt sich in mehrere Bestandteile aufteilen:

Bild 2. CI/CD-Pipeline

Systemzugang

Aus Sicht der Sicherheit muss der Zugang zu solchen Systemen begrenzt und nicht für jeden möglich sein. Er sollte im Unternehmensnetzwerk versteckt sein und nur für Benutzer mit bestimmten Rollen und damit speziellen Zugriffsrechten offenstehen. Selbst der einfache Zugang zum Internet stellt ein Sicherheitsrisiko dar, da eine Schwachstelle vorhanden sein könnte, die von Bedrohungsakteuren aktiv ausgenutzt wird.

Systemkonfiguration

Eine mögliche Quelle für Sicherheitsrisiken und damit verbundenen Problemen sind Fehlkonfigurationen. Bestimmte Konfigurationen sind für bestimmte Umgebungen sinnvoll. Ein Unternehmen benötigt beispielsweise mehrere Benutzer, die Zugriff auf das System haben, aber jeder hat eine andere Rolle. In dieser Situation sollte eine rollenbasierte Sicherheit konfiguriert werden. Allerdings gibt es bei diesen Konfigurationen auch Fallen, wie bereits im Fall von Jenkins beschrieben. Angesichts der zunehmenden Komplexität der Software und zunehmenden Konfigurationsmöglichkeiten ist ein Test auf häufige Software-Fehlkonfigurationen sehr zu empfehlen.

Erhalten von Source Code

Hier lassen sich zwei Muster unterscheiden: SCM ist in CI/CD integriert, wie etwa beim Azure DevOps Server, oder das SCM läuft in verschiedenen Umgebungen, sodass Zugangs-Tokens oder Zugangsinformationen innerhalb des Systems gespeichert werden müssen. Die Art und Weise, wie Software die Quellcode-Anmeldeinformationen speichert, ist von entscheidender Bedeutung, da ihre Freilegung zu bösartigen Quellcode-Modifikationen führen kann.

Konfiguration der Build-Umgebung

Hier geht es sicherheitstechnisch um die übermittelten Zugangsinformtionen. Es besteht das Risiko der Übergabe von unverschlüsselten Anmeldeinformationen und deren Speicherung in Form von Build-Artefakten. Im Wesentlichen enthalten einige Konfigurationsvoraussetzungen sensible Informationen, die in der Regel nach einem Build zurückbleiben.

Build

In dieser Phase wird der Quellcode in die Ziel-Binärform kompiliert. Angriffe hat es sowohl im Fall von Solar Winds als auch im Fall von CCleaner gegeben. Da es sich um einen der letzten Schritte in der Supply Chain handelt, wird danach nicht mehr viel überprüft. Außerdem sind die erstellten ausführbaren Binärdateien heutzutage in der Regel digital signiert. Das bedeutet, dass jede Codeänderung, die nach dem Signieren erfolgt, keine gültige digitale Signatur hat. Der Hash der Binärdatei würde nicht übereinstimmen, und da er mit einem privaten Schlüssel verschlüsselt ist, wäre es nicht möglich, ohne dessen Kenntnis einen gültigen Hash zu erzeugen. Aus diesem Grund ist der Build-Prozess ein geeignetes Ziel für Supply-Chain-Angriffe. Allerdings wird nicht jede Software mit einer digitalen Signatur ausgeliefert.

Beim digitalen Signieren sollte der private Schlüssel des Zertifikats unbedingt geheim gehalten werden. Dessen Offenlegung würde bedeuten, dass Angreifer jede beliebige Software mit diesem Zertifikat digital signieren können.

Implementierung oder Produktauslieferung

Dies ist der letzte Teil der Supply Chain. Zunächst einmal kann der Implementierungsprozess innerhalb der CI/CD-Software spezifiziert und nach einem erfolgreichen Build oder Test ausgelöst werden. Daher können hier Architekturinformationen zusammen mit den Anmeldeinformationen und anderen sensiblen Infos vorhanden sein, und das unterstreicht die Notwendigkeit ihrer adäquaten Verwaltung.

Der einfachste Weg für einen Angreifer ist der Austausch des gesamten Softwareprodukts. Das Einschleusen von Schadcode ist ein weiterer Weg, der sich für bestimmte (nicht digital signierte) Anwendungen eignet. Als Beispiel wären die Code-Injection-Angriffe auf WordPress-Websites zu nennen, bei denen bösartige Codeschnipsel über die Ausnutzung einer Schwachstelle oder Sicherheitslücke eingefügt werden.

Das Einschleusen von ausführbarem Binärcode ist ebenfalls möglich, hängt aber stärker von der kompilierten Binärdatei und den Fähigkeiten des Angreifers ab. Hinzu kommt, dass bei Vorhandensein einer digitalen Signatur der Binärdatei sich der Angriff leicht entdecken lässt, und daher ist dieser Weg nicht effizient. Der einfache Austausch der Binärdatei ist für Angreifer bequemer. Das Hacken eines Delivery-Servers (Server, die es Benutzern ermöglichen, tatsächliche Software-Produkte herunterzuladen), auf dem die Binärdatei gespeichert ist, ist jedoch keine einfache Aufgabe und würde erhebliche Ressourcen erfordern. Stattdessen werden Taktiken wie Phishing, Betrugskampagnen oder DNS-Spoofing-Angriffe eingesetzt und bekannte Software-Marken (sogar von Sicherheitsanbietern) missbraucht, um bösartige oder Grayware-Payloads zu liefern.

Mehr über dokumentierte Angriffe auf die Supply Chain beinhaltet die GitHub-Seite.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.