Das Unternehmen Google hat das Framework SLSA (Supply-chain Levels for Software Artifacts) vorgestellt, das die bestehenden Erfahrungen zum Schutz der Entwicklungsinfrastruktur vor Angriffen zusammenfasst, die in der Phase des Codierens, Testens, der Erstellung und Verbreitung von Produkten stattfinden.
Entwicklungsprozesse werden zunehmend komplexer und abhängiger von externen Werkzeugen, was günstige Bedingungen für Angriffe schafft, die nicht auf die Entdeckung und Ausnutzung von Schwachstellen im Endprodukt abzielen, sondern auf die Kompromittierung des eigentlichen Entwicklungsprozesses (Angriffe auf die "Lieferkette", die in der Regel darauf abzielen, schädliche Änderungen im Codierungsprozess einzuführen, verbreitete Komponenten und Abhängigkeiten zu manipulieren).
Das Framework berücksichtigt 8 Arten von Angriffen, die mit Bedrohungen verbunden sind, die schädliche Änderungen in der Phase des Codierens, Erstellens, Testens und Verbreitens von Produkten einführen.
- A. Einfügen von Änderungen in den Quellcode, die Backdoors oder versteckte Fehler enthalten, die zu Schwachstellen führen.
Beispiel für einen Angriff: "Hypocrite Commits" – der Versuch, schwache Patches im Kernel von Linux einzuführen.
Vorgeschlagene Schutzmaßnahme: Unabhängige Überprüfung jeder Änderung durch zwei Entwickler.
- B. Kompromittierung der Quellcode-Verwaltungsplattform.
Beispiel für einen Angriff: Einführen bösartiger Commits mit einer Backdoor in das Git-Repository des PHP-Projekts nach einem Passwort-Leck von Entwicklern.
Vorgeschlagene Schutzmaßnahme: Verbesserung des Schutzes der Plattform zur Verwaltung des Codes (im Fall von PHP wurde der Angriff über eine wenig genutzte HTTPS-Schnittstelle durchgeführt, die das Einfügen von Änderungen erlaubte, während der Zugriff mit Passwort ohne Überprüfung des SSH-Schlüssels möglich war, obwohl zur Hashfunktion der Passwörter eine unsichere MD5-Methode verwendet wurde).
- C. Einfügen von Änderungen, wenn der Code an das Build-System oder die kontinuierliche Integration übergeben wird (es wird Code aufgebaut, der nicht dem Code im Repository entspricht).
Beispiel für einen Angriff: Einführen einer Backdoor in Webmin durch Änderungen in der Build-Infrastruktur, die zur Nutzung von Dateien mit Code führten, die sich von den Dateien im Repository unterscheiden.
Vorgeschlagene Schutzmaßnahme: Überprüfung der Integrität und Identifikation der Quelle des eingehenden Codes beim Build. Server.
- D. Kompromittierung der Build-Plattform.
Beispiel für einen Angriff: SolarWinds-Angriff, bei dem in der Phase des Buildings das Einschleusen einer Backdoor in das Produkt SolarWinds Orion ermöglicht wurde.
Vorgeschlagene Schutzmaßnahme: Implementierung erweiterter Sicherheitsmaßnahmen für die Build-Plattform.
- E. Verbreitung von schadhafter Software durch minderwertige Abhängigkeiten.
Beispielfall eines Angriffs: Einfügen eines Backdoors in die beliebte Bibliothek event-stream durch das Hinzufügen einer harmlosen Abhängigkeit, die dann in einem der Updates dieser Abhängigkeit schadhafter Code enthielt (die schadhafte Änderung war nicht im Git-Repository erfasst, sondern nur im fertigen MNP-Paket vorhanden).
Vorgeschlagene Schutzmaßnahme: Rekursive Anwendung der SLSA-Anforderungen auf alle Abhängigkeiten (im Falle von event-stream hätte die Überprüfung eine Code-Zusammenstellung aufgedeckt, die nicht dem Inhalt des Haupt-Git-Repositories entsprach).
- F. Hochladen von Artefakten, die nicht im CI/CD-System erstellt wurden.
Beispielfall eines Angriffs: Hinzufügen von schadhafter Software zum CodeCov-Skript, das es Angreifern ermöglichte, Informationen, die in den Umgebungen der kontinuierlichen Integrationssysteme der Kunden gespeichert waren, abzurufen.
Vorgeschlagene Schutzmaßnahme: Kontrolle der Quelle und Integrität von Artefakten (im Fall von CodeCov hätte festgestellt werden können, dass das über codecov.io bereitgestellte Bash Uploader-Skript nicht mit dem Code im Projekt-Repository übereinstimmte).
- G. Kompromittierung des Paket-Repositorys.
Beispielfall eines Angriffs: Forschern gelang es, Mirror einiger beliebter Paket-Repositories einzurichten, um schadhafte Pakete zu verbreiten.
Vorgeschlagene Schutzmaßnahme: Überprüfung, dass die verbreiteten Artefakte aus den angegebenen Quelltexten erstellt wurden.
- H. Verwirrung des Benutzers bei der Installation eines falschen Pakets.
Beispielfall eines Angriffs: Verwendung von Typ-Squatting (NPM, RubyGems, PyPI) zum Platzieren von Paketen in Repositories, die in der Schreibweise beliebten Anwendungen ähneln (z. B. coffe-script anstelle von coffee-script).
Um die genannten Bedrohungen zu blockieren, bietet SLSA eine Reihe von Empfehlungen sowie Werkzeuge zur Automatisierung der Erstellung von Metadaten für Audits an. SLSA fasst typische Angriffsarten zusammen und führt das Konzept von Schutzlevels ein. Jedes Niveau stellt bestimmte Anforderungen an die Infrastruktur, um die Integrität der bei der Entwicklung verwendeten Artefakte zu garantieren. Je höher das unterstützte SLSA-Niveau, desto mehr Schutzmittel sind implementiert und desto besser ist die Infrastruktur vor typischen Angriffen geschützt.
- SLSA 1 — erfordert, dass der Aufbauprozess vollständig automatisiert ist und Metadaten („provenance“) darüber generiert, wie Artefakte zusammengestellt werden, einschließlich Informationen zu den Quelltexten, Abhängigkeiten und dem Aufbauprozess (für GitHub Actions wurde ein Beispiel für einen Metadatengenerator zur Prüfung vorgeschlagen). SLSA 1 umfasst keine Elemente zum Schutz vor der Einführung schädlicher Änderungen, sondern identifiziert den Code lediglich auf einfache Weise und stellt Metadaten zur Verwaltung von Schwachstellen und Risikoanalysen zur Verfügung.
- SLSA 2 — erweitert die erste Stufe durch die Anforderung, ein Versionsverwaltungssystem und Build-Dienste zu verwenden, die authentifizierte Metadaten erzeugen. Die Anwendung von SLSA 2 ermöglicht die Rückverfolgbarkeit des Ursprungs des Codes und verhindert unbefugte Änderungen am Code, wenn vertrauenswürdige Build-Dienste verwendet werden.
- SLSA 3 — bestätigt, dass die Quelltexte und die Build-Plattform den Anforderungen der Standards entsprechen, die eine Prüfung des Codes und die Gewährleistung der Integrität der bereitgestellten Metadaten ermöglichen. Es wird angenommen, dass Prüfer die Plattformen auf die Erfüllung der Standards zertiizieren können.
- SLSA 4 — die höchste Stufe, die die vorherigen Stufen mit folgenden Anforderungen ergänzt:
- Die obligatorische Überprüfung aller Änderungen durch zwei verschiedene Entwickler.
- Alle Schritte des Builds, der Code und die Abhängigkeiten müssen vollständig deklariert werden, alle Abhängigkeiten müssen separat extrahiert und überprüft werden, und der Build-Prozess muss ohne Zugriff auf das Netzwerk durchgeführt werden.
- Die Anwendung eines reproduzierbaren Build-Prozesses — die Möglichkeit, den Build-Prozess selbst zu wiederholen und sicherzustellen, dass die ausführbare Datei aus den bereitgestellten Quelltexten erstellt wurde.
Quelle: opennet.ru
