Tvrtka Google predstavila je okvir SLSA (Supply-chain Levels for Software Artifacts), koji sažima postojeće iskustvo u zaštiti infrastrukture razvoja od napada koji se provode tijekom pisanja koda, testiranja, građenja i distribucije proizvoda.
Procesi razvoja postaju sve složeniji i ovisni o vanjskim alatima, što stvara povoljne uvjete za napade koji nisu usmjereni na pronalaženje i iskorištavanje ranjivosti u konačnom proizvodu, već na kompromitaciju samog procesa razvoja (napadi 'supply chain', obično fokusirani na ubacivanje zlonamjernih promjena tijekom pisanja koda, zamjenu distribuiranih komponenata i ovisnosti).
Okvir uzima u obzir 8 vrsta napada vezanih uz prijetnje ubacivanja zlonamjernih promjena u fazi razvoja koda, građenja, testiranja i distribucije proizvoda.
- A. Uključivanje promjena u izvorni kod koje sadrže backdoore ili skrivene greške koje dovode do ranjivosti.
Primjer napada: 'Hypocrite Commits' — pokušaj ubacivanja zakrpa s ranjivostima u jezgru Linuxa.
Predložena metoda zaštite: neovisno recenziranje svake promjene od strane dva programera.
- B. Kompromitacija platforme za upravljanje izvorom.
Primjer napada: ubacivanje zlonamjernih commitova s backdoorom u Git repozitorij projekta PHP nakon curenja lozinki programera.
Predložena metoda zaštite: poboljšanje zaštite platforme za upravljanje kodom (u slučaju PHP napad je proveden putem malo korištenog HTTPS sučelja koje je dopuštalo slanje promjena prijavom lozinkom bez provjere SSH ključa, pri čemu je za hashiranje lozinki korišten nesiguran MD5).
- C. Izmjene u fazi prijenosa koda u sustav za izgradnju ili kontinuiranu integraciju (građen je kod koji se ne podudara s kodom iz repozitorija).
Primjer napada: ubacivanje backdoora u Webmin promjenama u sustavu za izgradnju, što je dovelo do korištenja datoteka s kodom koje se razlikuju od datoteka u repozitoriju.
Predložena metoda zaštite: provjera cjelovitosti i identifikacija izvora dolaska koda na izgradnju. serveru.
- D. Kompromitacija platforme za izgradnju.
Primjer napada: SolarWinds napad, tijekom kojeg je u fazi izgradnje omogućeno ubacivanje backdoora u proizvod SolarWinds Orion.
Predložena metoda zaštite: implementacija naprednih mjera sigurnosti u platformi za izradnju.
- E. Promocija zloćudnog koda kroz niskokvalitetne ovisnosti.
Primjer napada: implementacija leđa u popularnu biblioteku event-stream, kroz dodavanje bezopasne ovisnosti koja se kasnije uključila u jedno od ažuriranja te ovisnosti zloćudnim kodom (zloćudna promjena nije bila prikazana u git repozitoriju, već je bila prisutna samo u gotovom MNP paketu).
Predložena metoda zaštite: rekurzivna primjena zahtjeva SLSA na sve ovisnosti (u slučaju event-stream, provjera bi otkrila sastavljanje koda koji ne odgovara sadržaju osnovnog Git repozitorija).
- F. Učitavanje artefakata koji nisu stvoreni u CI/CD sustavu.
Primjer napada: dodavanje zloćudnog koda u CodeCov skriptu, što je omogućilo napadačima da izvuku informacije pohranjene u okruženjima sustava kontinuirane integracije klijenata.
Predložena metoda zaštite: kontrola izvora i cjelovitosti artefakata (u slučaju CodeCov moglo je biti utvrđeno da skripta Bash Uploader koja se preuzima s web stranice codecov.io ne odgovara kodu iz repozitorija projekta).
- G. Kompromitacija repozitorija paketa.
Primjer napada: istraživačima je uspjelo postaviti zrcala nekoliko popularnih repozitorija paketa s ciljem širenja zloćudnih paketa kroz njih.
Predložena metoda zaštite: provjeriti da se distribuirani artefakti stvaraju iz navedenih izvornih tekstova.
- H. Uvođenje u zabunu korisnika za instalaciju pogrešnog paketa.
Primjer napada: korištenje type-squattinga (NPM, RubyGems, PyPI) za postavljanje paketa u repozitorije, koji izgledaju slično popularnim aplikacijama (npr. coffe-script umjesto coffee-script).
Za blokiranje istaknutih prijetnji, SLSA nudi skup preporuka, kao i alate za automatizaciju izrade metapodataka za reviziju. SLSA sumira tipične metode napada i uvodi koncept razina zaštite. Svaka razina postavlja određene zahtjeve za infrastrukturu, omogućujući jamstvo cjelovitosti artefakata koji se koriste u razvoju. Što je viša podržana razina SLSA, to je više mjera zaštite implementirano i bolja je infrastruktura zaštićena od tipičnih napada.
- SLSA 1 — zahtijeva da proces izrade bude potpuno automatiziran i generira metapodatke („provenance“) o tome kako su artefakti prikupljeni, uključujući informacije o izvornoj kodu, ovisnostima i procesu izrade (primjer generatora metapodataka za reviziju je predložen za GitHub Actions). SLSA 1 ne uključuje elemente zaštite od zloćudnih promjena, a samo jednostavno identificira kod i pruža metapodatke za upravljanje ranjivostima i analizu rizika.
- SLSA 2 — proširuje prvi nivo zahtjevom za korištenje sustava za upravljanje verzijama i usluga izrade koje generiraju autentificirane metapodatke. Primjena SLSA 2 omogućuje praćenje porijekla koda i sprječava neautorizirane promjene u kodu kada se koriste pouzdane usluge izrade.
- SLSA 3 — potvrđuje da izvorni kod i platforma za izradu ispunjavaju standarde koji jamče mogućnost provođenja revizije koda i osiguranje integriteta dostavljenih metapodataka. Predviđa se da revizori mogu certifikovati platforme u skladu sa standardima.
- SLSA 4 — najviši nivo, koji dopunjuje prethodne nivoe sljedećim zahtjevima:
- Obavezno pregledavanje svih promjena od strane dva različita programera.
- Svi koraci izrade, kod i ovisnosti moraju biti potpuno deklarirani, sve ovisnosti moraju biti posebno ekstraktirane i provjerene, a proces izrade mora se izvoditi bez pristupa mreži.
- Primjena procesa ponovljive izrade — mogućnost ponovnog izvođenja procesa izrade samostalno i uvjeravanje da je izvršna datoteka sastavljena od dostavljenih izvora.
Izvor: opennet.ru
