Ob Paket-Hijacking, Dependency Confusion, Typosquatting, Kompromittierungen der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) oder die simple Ausnutzung veralteter Abhängigkeiten im Web – es gibt zahlreiche Angriffe auf Software-Lieferketten, mit denen Angreifer ihre Opfer ausschalten, sie erpressen und kritische Daten exfiltrieren können.erpressen können.
Oft ist es effizienter, ein schwaches Glied in der Kette anzugreifen, um ein größeres Ziel zu erreichen – wie es in den vergangenen Jahren bei Kaseya oder SolarWinds geschehen ist. Angreifer können RCE (Remote Code Execution) einschleusen oder die Zugangsdaten von Entwicklern abgreifen, um ihre Privilegien auszuweiten und unbemerkt bösartige Aktionen auszuführen.
Außerdem müssen sie möglicherweise nur ein einziges Paket kompromittieren, um Malware an eine große Zahl von Benutzern und Organisationen zu verbreiten, denn die heutige Lieferkette ist extrem komplex und vernetzt.
Natürlich können Entwickler nicht für alle Schwachstellen verantwortlich gemacht werden, doch sie verfügen in der Regel über privilegierte Konten und sogar direkten Zugriff auf sensible Dokumente und Pipelines, wodurch sie zunehmend attraktive Ziele darstellen.
Um Entwickler beim Schutz vor Angriffen auf die Lieferkette zu unterstützen, haben die US-amerikanische National Security Agency (NSA), die Cybersecurity and Infrastructure Security Agency (CISA) und das Office of the Director of National Intelligence (ODNI) kürzlich einen umfassenden Leitfaden veröffentlicht, der ihnen helfen soll, ihren Code und ihre Prozesse abzusichern.
Siehe die wichtigsten Tools zum Debuggen und Absichern von Code
Stoppen bösartiger Code-Injektionen
Laut dem Leitfaden nutzen Bedrohungsakteure weiterhin öffentlich bekannt gemachte Schwachstellen. Statt darauf zu warten, „schleusen sie proaktiv bösartigen Code in Produkte ein, die anschließend rechtmäßig über die globale Lieferkette an nachgelagerte Stellen verteilt werden“.
Entwicklungsteams haben häufig Schwierigkeiten mit Updates und dem zeitaufwendigen DevOps (Development and Operations). Daher automatisieren sie CI/CD-Pipelines für automatisierte Bereitstellungen und Tests. Der Prozess ist jedoch manchmal falsch konfiguriert und verfügt häufig nicht über Sicherheitsprüfungen.
Eine weitere verbreitete Technik besteht darin, ein Paket zu kompromittieren, das nur von Entwicklern verwendet wird (z. B. devDependencies in Node), um deren Zugangsdaten wie AWS-Schlüssel abzugreifen.
Der neue US-amerikanische Leitfaden benennt gängige Bedrohungsszenarien während des Softwarelebenszyklus:
- Ein Angreifer schleust absichtlich bösartigen Code ein, oder ein Entwickler fügt unbeabsichtigt anfälligen Code in ein Produkt ein.
- Anfälliger Quellcode oder Binärdateien von Drittanbietern werden wissentlich oder unwissentlich in ein Produkt integriert.
- Schwachstellen im Build-Prozess werden ausgenutzt, um bösartige Software in eine Komponente eines Produkts einzuschleusen.
- Ein Produkt innerhalb des Bereitstellungsmechanismus wird verändert, wodurch bösartige Software in das vom Kunden eingesetzte ursprüngliche Paket, Update- oder Upgrade-Bundle eingeschleust wird.
Das Dokument führt konkrete Maßnahmen zur Risikominderung auf:
- Architektur- und Designdokumente erstellen.
- Ein geschultes, qualifiziertes und vertrauenswürdiges Entwicklungsteam zusammenstellen.
- Bedrohungsmodelle für das Softwareprodukt erstellen.
- Pläne für Sicherheitstests definieren und umsetzen.
- Freigabekriterien definieren und das Produkt anhand dieser Kriterien bewerten.
- Richtlinien und Verfahren für den Produktsupport und den Umgang mit Schwachstellen etablieren.
- Die Fähigkeiten und das Verständnis der Entwickler für den sicheren Entwicklungsprozess bewerten und Schulungen zuweisen.
- Die Sicherheitsverfahren und -prozesse für jede Softwareversion dokumentieren und veröffentlichen.
Code sicher absichern
Das Schreiben sicheren Codes umfasst unabhängig von der Programmiersprache Verfahren wie Code-Reviews und Sicherheitstests, auch wenn manche Sprachen wie Rust standardmäßig die Sicherheit priorisieren.
Der Leitfaden hebt hervor, wie häufig sowohl absichtliche als auch unbeabsichtigte Einschleusungen bösartigen Codes bei Angriffen vorkommen.
Ingenieure und Entwickler können in scheinbar harmlosen Situationen kompromittiert werden, etwa durch Unzufriedenheit oder äußere Einflussnahme. Fehlende Schulungen können auch schwerwiegende Designfehler erklären, die nur sehr schwer zu erkennen sind und zu Zero-Day-Angriffen führen können, die monatelang ungepatcht bleiben.
Außerdem implementieren Programmierer gerne spezielle Parameter und andere Debugging-Funktionen, um die Fehlersuche oder Einrichtung zu erleichtern. Leider gelangen diese „Hacks“ aus Bequemlichkeit nicht selten in die Produktionsumgebung, oder jemand vergisst schlicht, sie nach der Verwendung zu entfernen.
Der Leitfaden fordert technische Teams auf, die folgenden Gegenmaßnahmen umzusetzen:
- Einen ausgewogenen, authentifizierten Prozess für das Einchecken von Quellcode implementieren, etwa bewährte Verfahren für GIT-Repositories und Multifaktor-Authentifizierung (MFA).
- Automatische statische und dynamische Sicherheits-/Schwachstellenscans durchführen.
- Nächtliche Builds mit Sicherheits- und Regressionstests durchführen.
- Funktionen Anforderungen zuordnen, etwa der Einschränkung von Entwicklerpaketen und dem Löschen nicht verwendeter Abhängigkeiten.
- Code-Reviews priorisieren und kritischen Code überprüfen.
- Schulungen zur sicheren Softwareentwicklung und Programmierung implementieren.
- Die Entwicklungsumgebung mit Methoden wie VPN, MFA, „Jump-Host“ und Bedrohungsmodellierung für jede Umgebung härten.
Den Build-Prozess verbessern
Unabhängig davon, ob es um den einzelnen Entwickler oder die Produktions-Build-Umgebung geht, sollte die Sicherheit der Software überprüft werden, bevor sie an Endbenutzer ausgeliefert und verteilt wird. Teams können verschiedene Tools und Techniken einsetzen. Zum Beispiel:
- Indirekte Kontrollen wie Schwachstellenscans, Penetrationstests, Wasserzeichen, Data Loss Prevention (DLP) und Integritätsprüfungen implementieren
- SBOMs (Software Bill of Materials) und digitale Signaturen zur Validierung von Auslieferungen
- Schnelle iterative Zyklen (agile Entwicklung)
- Zugriffsprotokolle für alle Pipelines
- Geheimnisse verschlüsseln
- Prinzip der geringsten Privilegien
- Netzwerksegmentierung
- On-Premises-Bereitstellung
- Versionskontrolle
- A/B-Tests in CI/CD-Pipelines
Best Practices für die Versionskontrolle
Das Dokument enthält Richtlinien zum Schutz des Quellcodes.
Zunächst beginnen Zugriff und Validierung mit guten Prinzipien für das Quellcode-Management (SCM), um Änderungen an einem Quellcode-Repository nachzuverfolgen.
Entwicklungsteams sollten außerdem Benachrichtigungen aktivieren, um über neu entdeckte Bedrohungen, Versionen oder Updates informiert zu werden. Große Plattformen für die Versionsverwaltung wie GitLab oder GitHub bieten solche Funktionen, doch der Leitfaden empfiehlt, noch weiter zu gehen und „ein Protokoll aller Entwickler und der von ihnen heruntergeladenen Komponenten“ zu führen.
MFA sollte „für jeden Zugriff“ auf das Repository aktiviert werden. Teams können außerdem grundlegende Git-Branches nutzen, um Ordnung zu schaffen:
- Entwickler arbeiten im Entwicklungs-Branch.
- Verantwortliche übertragen die Software nach Code-Review und Freigabe in einen QA-Branch (Quality Assurance).
- QA-Teams testen die Software aus dem QA-Branch.
- Bei einer Freigabe kann der Branch in die Produktionsumgebung zusammengeführt werden.
Der Leitfaden empfiehlt, den Zugriff auf den Produktions-Branch auf „eine kleine Gruppe von Build- und Teammitgliedern“ zu beschränken und nach jeder Veröffentlichung Sperrverfahren zu implementieren, um die Builds abzusichern.
Entwickler sollten Commits ebenfalls signieren. Im Leitfaden wird dies zwar nicht ausdrücklich erwähnt, doch einige Angriffe beruhen auf gestohlenen Schlüsseln, mit denen Commits übertragen werden. In diesem Fall werden die nicht autorisierten Änderungen einem legitimen Benutzer zugeschrieben.
Es ist nicht ungewöhnlich, dass Entwickler temporäre Schlüssel zum Einrichten von Umgebungen verwenden. Wenn sie die Schlüssel nach der Verwendung nicht entfernen, könnte ein Angreifer sie finden, nachdem er Zugriff auf den Server erlangt hat.
Ein weiterer Angriff kann darin bestehen, die Identität eines legitimen Maintainers vorzutäuschen, indem ein gefälschtes Paket erstellt und Git mit den Informationen des Maintainers konfiguriert wird (z. B. Typosquatting).
Entwickler können Commits mit GPG-Schlüsseln (Gnu Privacy Guard) oder Bibliotheken wie Gitsign signieren. Das ist nicht absolut sicher, doch diese zusätzliche Sicherheitsebene lässt sich relativ einfach einrichten.
Weiterlesen: Die besten Tools für das Schwachstellenmanagement