Das Unternehmen Google hat das Projekt OSS Rebuild vorgestellt, das darauf abzielt, versteckte Änderungen in veröffentlichten Paketen in Repositories zu identifizieren. Die Arbeit von OSS Rebuild basiert auf dem Konzept von reproduzierbaren Builds und besteht darin, die Übereinstimmung des im Repository abgelegten Pakets mit dem Paket, das auf der Grundlage des Referenzquellcodes, der der angegebenen Version des Pakets entspricht, neu erstellt wurde, zu überprüfen. Der Code des Tools ist in der Programmiersprache Go geschrieben und wird unter der Apache 2.0-Lizenz veröffentlicht.
Derzeit unterstützt OSS Rebuild die Überprüfung von Paketen aus den Repositories NPM (JavaScript/TypeScript), PyPI (Python) und Crates.io (Rust). In Zukunft soll die Anzahl der unterstützten Repositories erweitert werden. In der Praxis ermöglicht das Tool die Identifizierung von Angriffsszenarien der Kategorie „Lieferkette“, bei denen nach der Kompromittierung von Konten von Betreuern oder Sabotage innerhalb des Projekts ein böswilliges Update im Repository veröffentlicht wird. Der Code im ursprünglichen Repository des Hauptprojekts bleibt dabei intakt, während bösartige Änderungen nur in die veröffentlichten Pakete eingebracht werden.
Das System erstellt nach Möglichkeit automatisch ein Skript für den reproduzierbaren Build des ausgewählten Pakets, indem es Heuristiken verwendet und Parameter auswählt, die eine Identität der gelieferten Artefakte im Paket ermöglichen. Wenn es nicht möglich ist, das im Repository abgelegte Paket automatisch zu reproduzieren, kann eine Build-Spezifikation manuell hinzugefügt werden. Nachdem das Paket erfolgreich reproduziert wurde, speichert das Tool OSS Rebuild die Beschreibung des Build-Prozesses zur späteren Überprüfung neuer Versionen des Pakets. Zusätzlich werden Informationen zur Überprüfung unter Verwendung des SLSA-Frameworks veröffentlicht.
Nach der Überprüfung einer bestimmten Version des Pakets werden Zertifizierungsdaten erstellt, die von anderen zur Bewertung bereits verifizierter Pakete verwendet werden können. Die Überprüfung kann durch das Ausführen eines Kommandozeilenwerkzeugs oder durch den Abgleich eines Hashwerts, der in einem separaten Cloud-Speicher gespeichert ist, erfolgen. Die Infrastruktur zur Überprüfung von Paketen kann auf eigenen Server. Auch kann auf Informationen über Prüfungen zugegriffen werden, die von Google für mehrere Tausend Pakete durchgeführt werden.
Als Beispiele für verschiedene Angriffsmethoden, vor denen OSS Rebuild Schutz bieten könnte, werden das Hinzufügen eines Backdoors in XZ, das Einfügen von schädlichem Code in den offiziellen JavaScript-Client für die Kryptowährung Solana und das Einfügen von Änderungen über den Actions-Handler changed-files angeführt.
- Im Fall des Projekts XZ enthielt der Code im Repository keine verdächtigen Änderungen, während die schädlichen Komponenten, die den Backdoor bildeten, in Dateien geliefert wurden, die im Testset zur Überprüfung der Funktionstüchtigkeit des XZ-Entpackers verwendet wurden. Der Backdoor wurde auf der Ebene des Build-Systems aktiviert, während der Quellcode von XZ mit dem Code aus dem Repository übereinstimmte. Die aktivierenden Backdoor m4-Makros für das Automake-Toolkit waren nur im fertigen Archiv mit dem Code enthalten und fehlten im Repository. Zur Erkennung solcher Angriffe wird in OSS Rebuild eine dynamische Analyse der im Paket gelieferten Artefakte, Ausführungswege und verdächtigen Operationen eingesetzt.
- Das Einfügen von schädlichen Änderungen in die Bibliothek @solana/web3.js geschah aufgrund der Kompromittierung des Accounts des Betreuers unter Verwendung von Methoden des Social Engineering und Phishings. Im NPM-Repository wurde eine neue Version veröffentlicht, die schädliche Änderungen enthielt. Im Git-Repository des Projekts wurde diese Version jedoch 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 changed-files-Handlers ermöglichte einen Angriff auf Projekte, die changed-files zur Verfolgung von Änderungen an Dateien und Verzeichnissen in der GitHub Actions-gestützten Continuous Integration-Infrastruktur verwenden. Um Änderungen nach der Kompromittierung der Build-Umgebung in OSS Rebuild zu verhindern, wird eine Überwachung von Änderungen und verdächtigen Aktivitäten in standardisierten reduzierten Build-Umgebungen eingesetzt.
Quelle: opennet.ru
