Google hat das SLSA-Framework (Supply-chain Levels for Software Artifacts) eingeführt, das bestehende Erfahrungen beim Schutz der Entwicklungsinfrastruktur vor Angriffen zusammenfasst, die in der Phase des Codeschreibens, Testens, Zusammenstellens und Verteilens eines Produkts durchgeführt werden.
Entwicklungsprozesse werden immer komplexer und abhängig von Tools Dritter, was günstige Bedingungen für die Weiterentwicklung von Angriffen schafft, bei denen es nicht um die Identifizierung und Ausnutzung von Schwachstellen im Endprodukt geht, sondern um die Gefährdung des Entwicklungsprozesses selbst (Supply-Chain-Angriffe, die in der Regel darauf abzielen). Einführung böswilliger Änderungen beim Schreiben von Code, Ersetzung verteilter Komponenten und Abhängigkeiten).
Das Framework berücksichtigt 8 Arten von Angriffen im Zusammenhang mit der Gefahr böswilliger Änderungen in der Phase der Codeentwicklung, Assemblierung, Prüfung und Verteilung des Produkts.
- A. Einbeziehung von Änderungen im Quellcode, die Hintertüren oder versteckte Fehler enthalten, die zu Schwachstellen führen.
Beispiel für einen Angriff: „Hypocrite Commits“ – ein Versuch, Patches mit Schwachstellen in den Linux-Kernel einzuschleusen.
Empfohlene Sicherheitsmethode: unabhängige Überprüfung jeder Änderung durch zwei Entwickler.
- B. Kompromittierung der Quellcode-Kontrollplattform.
Beispiel für einen Angriff: Einschleusen bösartiger Commits mit einer Hintertür in das Git-Repository eines PHP-Projekts, nachdem Entwicklerkennwörter durchgesickert sind.
Vorgeschlagene Schutzmethode: Erhöhte Sicherheit der Code-Management-Plattform (im Fall von PHP wurde der Angriff über eine wenig genutzte HTTPS-Schnittstelle durchgeführt, die es jedoch ermöglichte, Änderungen bei der Anmeldung mit einem Passwort ohne Überprüfung des SSH-Schlüssels zu senden die Tatsache, dass unzuverlässiges MD5 zum Hashen von Passwörtern verwendet wurde).
- C. Vornehmen von Änderungen in der Phase der Codeübertragung an das Build- oder Continuous-Integration-System (Code, der nicht mit dem Code aus dem Repository übereinstimmt, wird erstellt).
Beispiel für einen Angriff: Einschleusen einer Hintertür in Webmin durch Änderungen an der Build-Infrastruktur, was zur Verwendung von Codedateien führt, die sich von den Dateien im Repository unterscheiden.
Vorgeschlagene Schutzmethode: Überprüfung der Integrität und Identifizierung der Quelle des Codes auf dem Assembly-Server.
- D. Beeinträchtigung der Montageplattform.
Beispiel für einen Angriff: der SolarWinds-Angriff, bei dem bereits während der Montagephase für den Einbau einer Hintertür in das Produkt SolarWinds Orion gesorgt wurde.
Vorgeschlagene Schutzmethode: Implementierung erweiterter Sicherheitsmaßnahmen für die Montageplattform.
- E. Förderung von Schadcode durch Abhängigkeiten geringer Qualität.
Ein Beispiel für einen Angriff: die Einführung einer Hintertür in die beliebte Event-Stream-Bibliothek durch das Hinzufügen einer harmlosen Abhängigkeit und die anschließende Einbindung von bösartigem Code in eines der Updates dieser Abhängigkeit (die böswillige Änderung wurde nicht im Git-Repository widergespiegelt, war aber nicht der Fall). nur im fertigen MNP-Paket vorhanden).
Empfohlene Schutzmethode: SLSA-Anforderungen rekursiv auf alle Abhängigkeiten anwenden (im Fall von Event-Stream würde die Prüfung die Codeassembly aufdecken, die nicht dem Inhalt des Haupt-Git-Repositorys entspricht).
- F. Hochladen von Artefakten, die nicht im CI/CD-System erstellt wurden.
Beispiel für einen Angriff: Hinzufügen von bösartigem Code zum CodeCov-Skript, der es Angreifern ermöglichte, Informationen zu extrahieren, die in den Systemumgebungen der kontinuierlichen Integration von Kunden gespeichert sind.
Vorgeschlagene Schutzmethode: Kontrolle über die Quelle und Integrität von Artefakten (im Fall von CodeCov könnte sich herausstellen, dass das von der Website codecov.io gesendete Bash-Uploader-Skript nicht dem Code aus dem Projekt-Repository entspricht).
- G. Kompromittierung des Paket-Repositorys.
Beispiel für einen Angriff: Forscher konnten Spiegel einiger beliebter Paket-Repositories bereitstellen, um über sie schädliche Pakete zu verteilen.
Empfohlene Schutzmethode: Überprüfung, ob die verteilten Artefakte aus den deklarierten Quellcodes kompiliert werden.
- H. Den Benutzer verwirren, das falsche Paket zu installieren.
Beispiel für einen Angriff: Verwendung von Typosquatting (NPM, RubyGems, PyPI), um Pakete in Repositories zu platzieren, die in ihrer Schreibweise beliebten Anwendungen ähneln (z. B. coffe-script statt Coffee-script).
Um die gekennzeichneten Bedrohungen zu blockieren, bietet SLSA eine Reihe von Empfehlungen sowie Tools zur Automatisierung der Erstellung von Audit-Metadaten. SLSA fasst gängige Angriffsmethoden zusammen und stellt das Konzept der Sicherheitsschichten vor. Jede Ebene stellt bestimmte Infrastrukturanforderungen, um die Integrität der in der Entwicklung verwendeten Artefakte sicherzustellen. Je höher die unterstützte SLSA-Stufe ist, desto mehr Schutzmaßnahmen sind implementiert und desto besser ist die Infrastruktur vor häufigen Angriffen geschützt.
- SLSA 1 erfordert, dass der Build-Prozess vollständig automatisiert ist und Metadaten („Herkunft“) darüber generiert, wie Artefakte erstellt werden, einschließlich Informationen zu Quellen, Abhängigkeiten und dem Build-Prozess (für GitHub Actions wird ein Beispiel-Metadatengenerator für die Prüfung bereitgestellt). SLSA 1 enthält keine Elemente zum Schutz vor böswilligen Änderungen, sondern identifiziert lediglich Code und stellt Metadaten für das Schwachstellenmanagement und die Risikoanalyse bereit.
- SLSA 2 – erweitert die erste Ebene, indem es die Verwendung von Versionskontroll- und Assemblerdiensten erfordert, die authentifizierte Metadaten generieren. Durch den Einsatz von SLSA 2 können Sie die Herkunft des Codes nachvollziehen und bei vertrauenswürdigen Build-Services unberechtigte Änderungen am Code verhindern.
- SLSA 3 – bestätigt, dass der Quellcode und die Build-Plattform den Anforderungen von Standards entsprechen, die die Fähigkeit zur Prüfung des Codes und die Gewährleistung der Integrität der bereitgestellten Metadaten gewährleisten. Es wird davon ausgegangen, dass Prüfer Plattformen gemäß den Anforderungen der Standards zertifizieren können.
- SLSA 4 ist die höchste Stufe und ergänzt die vorherigen Stufen um folgende Anforderungen:
- Obligatorische Überprüfung aller Änderungen durch zwei verschiedene Entwickler.
- Alle Build-Schritte, Codes und Abhängigkeiten müssen vollständig deklariert werden, alle Abhängigkeiten müssen separat extrahiert und überprüft werden und der Build-Prozess muss offline durchgeführt werden.
- Mit einem wiederholbaren Build-Prozess können Sie den Build-Prozess selbst wiederholen und sicherstellen, dass die ausführbare Datei aus dem bereitgestellten Quellcode erstellt wird.
Source: opennet.ru