Das Unternehmen Google hat das Projekt OSS Rebuild ins Leben gerufen, das darauf abzielt, unsichtbare Änderungen in fertiggestellten Paketen, die in Repositories veröffentlicht werden, zu identifizieren. Die Funktionsweise von OSS Rebuild basiert auf dem Konzept reproduzierbarer Builds und beschränkt sich auf den Abgleich des im Repository veröffentlichten Pakets mit dem aus dem Referenz-Quellcode erzeugten Paket, das der angegebenen Version des Pakets entspricht. Der Code des Tools ist in Go geschrieben und wird unter der Apache 2.0-Lizenz vertrieben.
Derzeit unterstützt OSS Rebuild die Verifizierung von Paketen aus den Repositories NPM (JavaScript/TypeScript), PyPI (Python) und Crates.io (Rust). Zukünftig ist eine Erweiterung der unterstützten Repositories geplant. In der Praxis ermöglicht das Tool die Identifizierung von Angriffen der Klasse „Supply Chain“, bei denen nach der Kompromittierung von Konten oder einer Sabotage innerhalb des Projekts ein bösartiges Update im Repository veröffentlicht wird. Währenddessen bleibt der Code im Quellrepository des Hauptprojekts intakt, und bösartige Änderungen werden nur in die fertigen Pakete eingefügt.
Das System generiert automatisch einen reproduzierbaren Build-Szenario für das ausgewählte Paket, indem es Heuristiken verwendet und Parameter auswählt, die eine Identität der im Paket gelieferten Artefakte gewährleisten. Wenn das Paket im Repository nicht automatisch reproduziert werden kann, besteht die Möglichkeit, eine Build-Spezifikation manuell hinzuzufügen. Nachdem das Paket erfolgreich reproduziert wurde, speichert das OSS Rebuild-Toolkit eine Beschreibung des Build-Prozesses zur späteren Überprüfung neuer Paketversionen. Zusätzlich werden Informationen zur Verifizierung unter Verwendung des SLSA-Frameworks veröffentlicht.
Nach der Überprüfung einer bestimmten Version des Pakets werden Attestierungsdaten erstellt, die von anderen zur Bewertung bereits verifizierter Pakete verwendet werden können. Die Überprüfung kann durch das Ausführen eines Befehlszeilen-Tools oder den Abgleich eines in einem separaten Cloud-Speicher gespeicherten Hashs erfolgen. Die Infrastruktur zur Überprüfung von Paketen kann in einer eigenen Server. Außerdem können Informationen über die von Google durchgeführten Überprüfungen für mehrere tausend Pakete genutzt werden.
Ein Beispiel für verschiedene Angriffsmethoden, gegen die OSS Rebuild Schutz bieten könnte, ist das Hinzufügen eines Backdoors in XZ, das Einschleusen von bösartigem Code in den offiziellen JavaScript-Client der Kryptowährung Solana und das Einfügen von Änderungen über den Actions-Handler changed-files.
- Im Fall des Projekts XZ enthielt der Code im Repository keine verdächtigen Änderungen, während die Komponenten, die das Backdoor bildeten, in den Dateien vorhanden waren, die im Testset zur Überprüfung der korrekten Funktionsweise des XZ-Dekomprimierers verwendet wurden. Das Backdoor wurde auf der Ebene des Build-Systems aktiviert, während der Quellcode von XZ mit dem Code aus dem Repository übereinstimmte. Die zur Aktivierung des Backdoors verwendeten m4-Makros für die Automake-Toolchain waren nur im fertigen Archiv mit dem Code enthalten und nicht im Repository. Um solche Angriffe zu erkennen, nutzt OSS Rebuild eine dynamische Analyse der im Paket gelieferten Artefakte, Ausführungspfade und verdächtigen Operationen.
- Die Einschleusung schädlicher Änderungen in die Bibliothek @solana/web3.js erfolgte aufgrund der Kompromittierung des Kontos eines Betreuers, unter Verwendung von Social Engineering und Phishing-Techniken. Eine neue Version wurde im NPM-Repository veröffentlicht, die schädliche Änderungen enthielt. Im Git-Repository des Projekts wurde diese Version nicht erstellt, und die schädlichen Änderungen waren nur im resultierenden Paket vorhanden. Der Schutz in diesem Fall besteht darin, im Paket Code zu identifizieren, der im Hauptrepository fehlt.
- Die Kompromittierung des Repositories des changed-files-Handlers ermöglichte einen Angriff auf Projekte, die changed-files zur Überwachung von Änderungen an Dateien und Verzeichnissen in der auf GitHub Actions basierenden Continuous Integration-Infrastruktur verwenden. Zum Schutz vor der Einspeisung von Änderungen nach der Kompromittierung der Build-Umgebung wird in OSS Rebuild eine Überwachung von Veränderungen und verdächtigen Aktivitäten in standardisierten, eingeschränkten Build-Umgebungen angewendet.
Quelle: opennet.ru
