Google heeft het OSS Rebuild-project gepresenteerd, dat is bedoeld om verborgen wijzigingen in gepubliceerde pakketten in repositories te identificeren. Het werk van OSS Rebuild is gebaseerd op het concept van reproduceerbare builds en richt zich op het controleren van de overeenstemming tussen het pakket in de repository en het pakket dat is verkregen door herbouw uit de referentie broncode die overeenkomt met de opgegeven versie van het pakket. De code van de tool is geschreven in de taal Go en wordt verspreid onder de Apache 2.0-licentie.
Momenteel ondersteunt OSS Rebuild de verificatie van pakketten uit de NPM (JavaScript/TypeScript), PyPI (Python) en Crates.io (Rust) repositories. In de toekomst is het de bedoeling om het aantal ondersteunde repositories uit te breiden. In de praktijk stelt de tool in staat om aanvallen van het type 'supply chain' te identificeren, waarbij na compromittering van de accounts van de maintainer of een interne sabotage, een kwaadwillige update in de repository wordt gepubliceerd. Hierbij blijft de code in de oorspronkelijke repository van het hoofdproject correct, terwijl de kwaadwillige wijzigingen alleen in de gepubliceerde pakketten worden aangebracht.
Het systeem genereert automatisch een script voor de reproduceerbare build van het gekozen pakket, indien mogelijk, door heuristiek te gebruiken en parameters te selecteren die ervoor zorgen dat de kunstmatige objecten die in het pakket worden geleverd identiek zijn. Als het niet lukt om het gepubliceerde pakket in de repository automatisch te reproduceren, is handmatige toevoeging van de bouwspecificatie mogelijk. Nadat het is gelukt om het pakket te reproduceren, slaat de OSS Rebuild-tool de beschrijving van het bouwproces op voor een latere controle van nieuwe versies van het pakket. Daarnaast worden informatie voor verificatie gepresenteerd met gebruik van het SLSA-framework.
Na het uitvoeren van de controle van een specifieke versie van het pakket, worden certificeringsgegevens gegenereerd die door anderen kunnen worden gebruikt om al geverifieerde pakketten te beoordelen. De controle kan worden uitgevoerd door het uitvoeren van de commandoregelutility of door het vergelijken van de hash die is opgeslagen in een aparte cloudopslag. De infrastructuur voor het controleren van pakketten kan op een eigen de server. Daarnaast kan gebruik worden gemaakt van informatie over controles die door Google zijn uitgevoerd voor duizenden pakketten.
Als voorbeelden van verschillende aanvalsmethoden die OSS Rebuild zou kunnen beschermen, worden het toevoegen van een backdoor in XZ, het injecteren van kwaadaardige code in de officiële JavaScript-client voor de cryptovaluta Solana, en het doorvoeren van wijzigingen via de Actions-handler changed-files genoemd.
- In het geval van het project XZ bevatte de code in de repository geen verdachte wijzigingen, terwijl de componenten die de backdoor vormden werden geleverd binnen bestanden die werden gebruikt in de testset voor de controle van de correctheid van de XZ-uitpaktool. De backdoor werd geactiveerd op het niveau van het build-systeem, en de broncode van XZ kwam overeen met de code uit de repository. De activerende backdoor m4-macro's voor de Automake-toolkit waren alleen opgenomen in het kant-en-klare archief met code en ontbraken in de repository. Voor het detecteren van dergelijke aanvallen gebruikt OSS Rebuild dynamische analyse van de geleverde artefacten in het pakket, uitvoeringspaden en verdachte operaties.
- De invoering van kwaadaardige wijzigingen in de bibliotheek @solana/web3.js vond plaats door het compromitteren van het account van de maintainer, met gebruik van social engineering- en phishing-methoden. In de NPM-repository werd een nieuwe release geplaatst die kwaadaardige wijzigingen bevatte. In de Git-repository van het project was deze release niet aangemaakt en waren de kwaadaardige wijzigingen alleen aanwezig in het eindpakket. Bescherming in dit geval komt neer op het identificeren van code in het pakket die ontbreekt in de hoofdrepository.
- De compromittering van de repository van de changed-files handler maakte een aanval mogelijk op projecten die changed-files gebruiken voor het volgen van wijzigingen in bestanden en mappen in een op GitHub Actions gebaseerde continue integratie-infrastructuur. Om bescherming te bieden tegen wijzigingen na compromittering van de build-omgeving, past OSS Rebuild het volgen van wijzigingen en verdachte activiteiten toe in gestandaardiseerde verkorte build-omgevingen.
Bron: opennet.ru
