Google har præsenteret projektet OSS Rebuild, der har til formål at identificere skjulte ændringer i færdige pakker, der publiceres i repositories. OSS Rebuilds arbejde er baseret på konceptet med reproducerbare builds og går ud på at kontrollere overensstemmelsen mellem den pakke, der er placeret i repositoryen, og den pakke, der er modtaget ved at gensamle fra den referencekode, der svarer til den angivne version af pakken. Værktøjets kode er skrevet i Go-sproget og distribueres under Apache 2.0-licensen.
I øjeblikket implementerer OSS Rebuild verifikation af pakker fra repositories som NPM (JavaScript/TypeScript), PyPI (Python) og Crates.io (Rust). I fremtiden planlægges det at udvide antallet af understøttede repositories. I praksis gør værktøjet det muligt at identificere angreb af typen 'supply chain', hvor efter kompromittering af vedligeholderes konti eller diversitet inden for projektet, publiceres en skadelig opdatering i repositoryen. Her forbliver koden i det oprindelige repositories for hovedprojektet korrekt, mens de skadelige ændringer kun tilføjes i de færdige pakker.
Systemet danner automatisk et script til reproducerbar build af den valgte pakke, hvis muligt, ved at bruge heuristik og vælge parametre, der gør det muligt at opnå identitet i de artefakter, der leveres i pakken. Hvis det ikke er muligt automatisk at reproducere den pakke, der er offentliggjort i repositoryen, kan en build-specifikation tilføjes manuelt. Når det er lykkedes at reproducere pakken, gemmer værktøjet OSS Rebuild beskrivelsen af build-processen til efterfølgende kontrol af nye versioner af pakken. Derudover offentliggøres information til verifikation ved hjælp af SLSA-rammen.
Efter at en specifik version af pakken er blevet kontrolleret, genereres der attesteringsdata, som kan bruges af andre til at evaluere allerede verificerede pakker. Verifikation kan udføres ved at køre kommandolinjeværktøjet eller sammenligne en hash, der er gemt i en separat cloud-lagring. Infrastruktur til pakkeverifikation kan implementeres på egen serveren. Man kan også drage fordel af information om verificeringer, der udføres af Google for flere tusinde pakker.
Som eksempler på forskellige angrebsmetoder, som OSS Rebuild kunne beskytte imod, nævnes tilføjelse af en backdoor i XZ, indføring af ondsindet kode i den officielle JavaScript-klient for kryptovalutaen Solana og indsprøjtning af ændringer via actions-handleren changed-files:
- I tilfælde af projektet XZ indeholdt koden i depotet ikke mistænkelige ændringer, mens de komponenter, der udgjorde backdoor'en, blev leveret inde i filer, der blev brugt i testsættet for at kontrollere korrektheden af XZ's dekompressor. Backdoor'en blev aktiveret på systemniveau, og selve kildekoden til XZ svarede til koden fra depotet. De m4-makroer, der aktiverede backdoor'en, til Automake-værktøjet var kun inkluderet i det færdige arkiv med koden og manglede i depotet. For at opdage sådanne angreb anvender OSS Rebuild dynamisk analyse af de artefakter, der leveres i pakken, udførelsesveje og mistænkelige operationer.
- Indsprøjtning af ondsindede ændringer i biblioteket @solana/web3.js skete på grund af kompromittering af vedligeholderens konto ved hjælp af social engineering og phishing-metoder. En ny version med ondsindede ændringer blev lagt i NPM-depotet. Denne version blev ikke oprettet i Git-depotet for projektet, og de ondsindede ændringer var kun til stede i det resulterende paket. Beskyttelsen i dette tilfælde handler om at identificere koden i pakken, som mangler i hoveddepote.
- Kompromitteringen af changed-files-handlerens depot gjorde det muligt at udføre angreb på projekter, der bruger changed-files til at spore ændringer i filer og kataloger i infrastrukturen for kontinuerlig integration baseret på GitHub Actions. For at beskytte mod indsprøjtning af ændringer efter kompromittering af bygge-miljøet anvender OSS Rebuild overvågning af ændringer og mistænkelig aktivitet i standardiserede, beskårede bygge-miljøer.
Kilde: opennet.ru
