Google har introdusert OSS Rebuild-prosjektet, som er utviklet for å oppdage skjulte endringer i ferdige pakker publisert i repositorier. OSS Rebuild er basert på konseptet med reproduserbare bygg og går ut på å kontrollere samsvaret til en pakke plassert i repositoriet med en pakke som er hentet på grunnlag av gjenoppbygging fra referansekildekoden som tilsvarer den deklarerte versjonen av pakken. Verktøysettkoden er skrevet i Go og distribueres under Apache 2.0-lisensen.
For øyeblikket støtter OSS Rebuild verifisering av pakker fra NPM-repositorier (JavaScript/TypeScript), PyPI (Python) og Crates.io (Rust). Antallet støttede repositorier er planlagt utvidet i fremtiden. I praksis tillater verktøysettet identifisering av varianter av angrep i forsyningskjeden, der en ondsinnet oppdatering publiseres i repositoriet etter at kontoene til vedlikeholdere er kompromittert eller sabotasje er utført i prosjektet. Samtidig forblir koden i det opprinnelige repositoriet til hovedprosjektet korrekt, og ondsinnede endringer gjøres kun i de ferdige pakkene.
Systemet genererer automatisk et scenario for en reproduserbar bygging av den valgte pakken, om mulig, ved hjelp av heuristikker og valg av parametere som gjør det mulig å oppnå identitet til artefaktene som er levert i pakken. Hvis det ikke er mulig å reprodusere en pakke som er plassert i depotet automatisk, er det mulig å legge til en byggespesifikasjon manuelt. Etter at pakken er reprodusert, lagrer OSS Rebuild-verktøyet en beskrivelse av byggeprosessen for senere verifisering av nye versjoner av pakken. I tillegg publiseres informasjon for verifisering ved hjelp av SLSA-rammeverket.
Etter at en spesifikk pakkeversjon er verifisert, genereres attestasjonsdata, som kan brukes av andre til å evaluere allerede verifiserte pakker. Verifisering kan utføres ved å kjøre et kommandolinjeverktøy eller ved å sjekke en hash lagret i en separat skylagring. Pakkeverifiseringsinfrastrukturen kan distribueres på egenhånd. serverDu kan også bruke informasjon om kontrollene Google har utført for flere tusen pakker.
Eksempler på ulike angrepsmetoder som OSS Rebuild kan beskytte mot inkluderer å legge til en bakdør til XZ, injisere ondsinnet kode i den offisielle JavaScript-klienten for Solana-kryptovalutaen, og erstatte endringer via changed-files Actions-håndtereren:
- I tilfellet med XZ-prosjektet inneholdt ikke koden i depotet mistenkelige endringer, og de skadelige komponentene som dannet bakdøren ble levert i filene som ble brukt i testsettet for å sjekke at XZ-utpakkeren fungerte riktig. Bakdøren ble aktivert på byggesystemnivå, og selve XZ-kildekoden samsvarte med koden fra depotet. M4-makroene for Automake-verktøysettet som aktiverte bakdøren, ble bare inkludert i det ferdige arkivet med koden og var ikke i depotet. For å oppdage slike angrep bruker OSS Rebuild dynamisk analyse av artefaktene som ble levert i pakken, utførelsesstier og mistenkelige operasjoner.
- Innsettingen av ondsinnede endringer i @solana/web3.js-biblioteket skjedde på grunn av at vedlikeholderens konto ble kompromittert ved hjelp av sosial manipulering og phishing-metoder. En ny utgivelse ble publisert i NPM-depotet, inkludert ondsinnede endringer. Denne utgivelsen ble ikke opprettet i prosjektets Git-depot, og de ondsinnede endringene var bare tilstede i den resulterende pakken. Forsvaret i dette tilfellet handler om å identifisere kode i pakken som mangler i hoveddepotet.
- En kompromittering av depotet for endrede filer tillot et angrep på prosjekter som bruker endrede filer til å spore fil- og katalogendringer i en kontinuerlig integrasjonsinfrastruktur basert på GitHub-handlinger. For å beskytte mot endringserstatning etter at et byggemiljø er kompromittert, bruker OSS Rebuild sporing av endringer og mistenkelig aktivitet i standardiserte, nedskalerte byggemiljøer.
Kilde: opennet.ru
