Google hat das SLSA-Framework (Supply-chain Levels for Software Artifacts) vorgestellt, das die vorhandenen Erfahrungen zum Schutz von Entwicklungsinfrastrukturen vor Angriffen zusammenfasst, die während der Phase des Codierens, Testens, Bauens und Verteilens von Produkten auftreten.
Die Entwicklungsprozesse werden zunehmend komplexer und abhängig von externen Werkzeugen, was ideale Bedingungen für Angriffe schafft, die nicht auf die Identifizierung und Ausnutzung von Schwachstellen im Endprodukt abzielen, sondern auf die Kompromittierung des Entwicklungsprozesses selbst (Supply-Chain-Angriffe, die in der Regel darauf abzielen, schädliche Änderungen während des Codierens einzuführen sowie verteilte Komponenten und Abhängigkeiten zu manipulieren).
Das Framework berücksichtigt 8 Arten von Angriffen, die mit der Bedrohung von schädlichen Änderungen während der Codierung, des Zusammenbaus, des Testens und der Verteilung von Produkten verbunden sind.
- 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, Patches mit Schwachstellen in den Linux-Kernel zu bringen.
Vorgeschlagene Schutzmaßnahme: Unabhängige Überprüfung jeder Änderung durch zwei Entwickler.
- B. Komprimierung der Quellcodeverwaltungsplattform.
Beispiel eines Angriffs: Einschleusung schädlicher Commits mit einem Backdoor in das Git-Repository des PHP-Projekts nach einer Passwortleakage von Entwicklern.
Vorgeschlagene Schutzmaßnahme: Verbesserung der Sicherheit der Quellcodeverwaltungsplattform (im Falle von PHP wurde der Angriff über eine wenig genutzte HTTPS-Schnittstelle durchgeführt, die Änderungen bei der Anmeldung per Passwort ohne Überprüfung des SSH-Schlüssels zuließ, wobei MD5 zur Passwort-Hashing verwendet wurde, was unsicher ist).
- C. Änderungen bei der Übertragung des Codes in das Build-System oder die kontinuierliche Integration (es wird Code kompiliert, der vom Repository abweicht).
Beispiel eines Angriffs: Einschleusung eines Backdoors in Webmin durch Änderungen an der Build-Infrastruktur, die zur Nutzung von Code-Dateien führten, die von den Dateien im Repository abweichen.
Vorgeschlagene Schutzmaßnahme: Überprüfung der Integrität und Identifikation der Quelle des Codes, der in den Build eingeht. Server.
- D. Kompromittierung der Build-Plattform.
Beispiel eines Angriffs: der SolarWinds-Angriff, bei dem während des Build-Prozesses ein Backdoor in das Produkt SolarWinds Orion integriert wurde.
Vorgeschlagene Schutzmaßnahme: Implementierung erweiterter Sicherheitsmaßnahmen für die Build-Plattform.
- E. Verbreitung von schadhafter Software durch minderwertige Abhängigkeiten.
Beispiel eines Angriffs: Einschleusung eines Backdoors in die beliebte Bibliothek event-stream durch Hinzufügen einer harmlosen Abhängigkeit, gefolgt von der Einbeziehung schadhafter Software in einem der Updates dieser Abhängigkeit (die schadhafte Änderung war nicht im Git-Repository aufgeführt, sondern nur im fertigen MNP-Paket vorhanden).
Vorgeschlagene Schutzmaßnahme: rekursive Anwendung der SLSA-Anforderungen auf alle Abhängigkeiten (im Fall von event-stream hätte die Prüfung den Code-Build identifiziert, der nicht dem Inhalt des Haupt-Git-Repositories entsprach).
- F. Hochladen von Artefakten, die nicht im CI/CD-System erstellt wurden.
Beispiel eines Angriffs: Hinzufügen von schädlichem Code zu dem CodeCov-Skript, das Angreifern ermöglichte, Informationen aus den Umgebungen der kontinuierlichen Integrationssysteme der Kunden zu extrahieren.
Empfohlene Schutzmaßnahme: Überwachung der Quelle und Integrität von Artefakten (im Fall von CodeCov wurde festgestellt, dass das von der Seite codecov.io bereitgestellte Bash Uploader-Skript nicht mit dem Code aus dem Projekt-repositorium übereinstimmt).
- G. Kompromittierung des Paketrepositories.
Beispiel eines Angriffs: Forschern gelang es, Spiegel einiger beliebter Paketrepositories einzurichten, um über diese bösartige Software zu verbreiten.
Empfohlene Schutzmaßnahme: Überprüfung, dass die verbreiteten Artefakte aus den angegebenen Quelltexten erstellt wurden.
- H. Verwirrung des Benutzers bei der Installation des falschen Pakets.
Beispiel eines Angriffs: Verwendung von Typo-Squatting (NPM, RubyGems, PyPI), um in Paketrepositories ähnlich benannte Pakete wie beliebte Anwendungen zu platzieren (z.B. coffe-script statt coffee-script).
Um die identifizierten Bedrohungen zu blockieren, bietet SLSA einen Satz von Empfehlungen sowie Werkzeuge zur Automatisierung der Erstellung von Metadaten für Audits an. SLSA fasst die typischen Angriffsmethoden zusammen und führt das Konzept von Schutzstufen ein. Jede Stufe stellt spezifische Anforderungen an die Infrastruktur, die die Integrität der bei der Entwicklung verwendeten Artefakte gewährleisten sollen. Je höher die unterstützte SLSA-Stufe, desto mehr Schutzmaßnahmen sind implementiert und desto besser ist die Infrastruktur gegen gängige Angriffe geschützt.
- SLSA 1 — erfordert, dass der Build-Prozess vollständig automatisiert ist und Metadaten („provenance“) darüber generiert, wie Artefakte erstellt werden, einschließlich Informationen über Quellcodes, Abhängigkeiten und den Build-Prozess (für GitHub Actions wird ein Beispiel für einen Metadaten-Generator für Audits angeboten). SLSA 1 beinhaltet keine Schutzmaßnahmen gegen die Einführung bösartiger Änderungen, sondern identifiziert lediglich den Code in einfachster Weise und bietet Metadaten zur Verwaltung von Sicherheitsanfälligkeiten und Risikoanalysen an.
- SLSA 2 – erweitert die erste Stufe um die Anforderung, ein Versionsverwaltungssystem und Build-Dienste zu verwenden, die authentifizierte Metadaten generieren. Die Anwendung von SLSA 2 ermöglicht es, die Herkunft des Codes zu verfolgen und unautorisierte Änderungen am Code zu verhindern, wenn vertrauenswürdige Build-Dienste verwendet werden.
- SLSA 3 – bestätigt, dass der Quellcode und die Build-Plattform die Anforderungen von Standards erfüllen, die eine Code-Auditierung und die Gewährleistung der Integrität der bereitgestellten Metadaten ermöglichen. Es wird angenommen, dass Auditoren die Plattformen auf Übereinstimmung mit den Standardanforderungen zertifizieren können.
- SLSA 4 – die höchste Stufe, die die vorherigen Stufen um folgende Anforderungen ergänzt:
- Eine verpflichtende Überprüfung aller Änderungen durch zwei unterschiedliche Entwickler.
- Alle Schritte beim Build, 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 Netzwerkzugang durchgeführt werden.
- Die Anwendung des wiederholbaren Build-Prozesses ermöglicht es Ihnen, den Build-Vorgang eigenständig zu wiederholen und sicherzustellen, dass die ausführbare Datei aus den bereitgestellten Quelltexten erstellt wurde.
Quelle: opennet.ru
