Spoločnosť Google predstavila rámec SLSA (Supply-chain Levels for Software Artifacts), ktorý sumarizuje existujúce skúsenosti v oblasti ochrany vývojovej infraštruktúry pred útokmi realizovanými počas písania kódu, testovania, zostavovania a distribúcie produktu.
Vývojové procesy sa stávajú čoraz zložitejšími a závislými od externých nástrojov, čo vytvára priaznivé podmienky pre uskutočňovanie útokov, ktoré nie sú zamerané na zisťovanie a zneužívanie zraniteľností v konečnom produkte, ale na kompromitáciu samotného vývojového procesu (supply chain útoky, ktoré majú zvyčajne za cieľ zavedenie škodlivých zmien počas písania kódu a substitúciu distribučných komponentov a závislostí).
Rámec zohľadňuje 8 typov útokov spojených s hrozbami na zavedenie škodlivých zmien v etape vývoja kódu, zostavovania, testovania a distribúcie produktu.
- A. Zaradenie zmien do zdrojového kódu, ktoré obsahujú backdoory alebo skryté chyby vedúce k zraniteľnostiam.
Príklad útoku: „Hypocrite Commits“ — pokus o zavedenie patchov s zraniteľnosťami do jadra Linuxu.
Navrhovaná metóda ochrany: nezávislé recenzovanie každej zmeny dvoma vývojármi.
- B. Kompromitácia platformy na správu zdrojového kódu.
Príklad útoku: zavedenie škodlivých commitov s backdoorom do Git-repozitára projektu PHP po úniku hesiel vývojárov.
Navrhovaná metóda ochrany: zvýšenie ochrany platformy na správu kódu (v prípade PHP bola útok vykonaný cez málo používané HTTPS rozhranie, ktoré umožnilo zaslanie zmien pri prihlásení pomocou hesla bez overenia SSH kľúča, pričom sa na hashovanie hesiel používal nespoľahlivý MD5).
- C. Vykonávanie zmien pri prenose kódu do systému zostavovania alebo kontinuálnej integrácie (kód zostavený, ktorý neodpovedá kódu z repozitára).
Príklad útoku: zavedenie backdoora do Webminu úpravou zostavovacej infraštruktúry, ktorá viedla k použitiu súborov s kódom odlišných od súborov v repozitári.
Navrhovaná metóda ochrany: kontrola integrity a identifikácia zdroja kódu na zostavovacích systémoch. serveri.
- D. Kompromitácia zostavovacej platformy.
Príklad útoku: útok SolarWinds, pri ktorom sa počas zostavovania zabezpečilo zavedenie backdoora do produktu SolarWinds Orion.
Navrhovaná metoda ochrany: zavedení rozšířených bezpečnostních opatření pro platformu sestavování.
- E. Šíření škodlivého kódu prostřednictvím nekvalitních závislostí.
Příklad útoku: zavedení backdooru do populární knihovny event-stream přidáním neškodné závislosti a následným začleněním škodlivého kódu v jednom z aktualizací této závislosti (škodlivá změna nebyla zaznamenána v git repozitáři, ale byla přítomna pouze v připraveném MNP balíčku).
Navrhovaná metoda ochrany: rekurzivní aplikace požadavků SLSA na všechny závislosti (v případě event-stream by kontrola odhalila sestavení kódu, které neodpovídá obsahu hlavního Git repozitáře).
- F. Stahování artefaktů, které nebyly vytvořeny v systému CI/CD.
Příklad útoku: přidání škodlivého kódu do skriptu CodeCov, který umožnil útočníkům získávat informace uložené v prostředích systémů kontinuální integrace klientů.
Navrhovaná metoda ochrany: sledování zdroje a integrity artefaktů (v případě CodeCov by bylo možné zjistit, že skript Bash Uploader stahovaný z webu codecov.io neodpovídá kódu z repozitáře projektu).
- G. Kompromitace repozitáře balíčků.
Příklad útoku: výzkumníkům se podařilo rozmístit zrcadla některých populárních repozitářů balíčků s cílem šířit skrze ně škodlivé balíčky.
Navrhovaná metoda ochrany: Kontrola, že distribuované artefakty byly sestaveny z deklarovaných zdrojových textů.
- H. Zmatek uživatele při instalaci nesprávného balíčku.
Příklad útoku: používání typového sklování (NPM, RubyGems, PyPI) k umístění v repozitářích balíčků, které se písemně podobají populárním aplikacím (například coffe-script místo coffee-script).
Pro blokování uvedených hrozeb SLSA navrhuje soubor doporučení a také nástrojů pro automatizaci vytváření metadat pro audit. SLSA shrnuje typové metody útoků a zavádí pojem úrovní ochrany. Každá úroveň klade určité požadavky na infrastrukturu, které zaručují integritu artefaktů používaných při vývoji. Čím vyšší úroveň SLSA je podporována, tím více ochranných prostředků je zavedených a tím lépe je infrastruktura chráněna před běžnými útoky.
- SLSA 1 — vyžaduje, aby bol proces zostavovania plne automatizovaný a generoval metadáta („provenance“) o tom, ako boli artefakty zostavené, vrátane informácií o pôvodných textoch, závislostiach a procese zostavovania (pre GitHub Actions je navrhnutý príklad generátora metadát na audit). SLSA 1 nezahŕňa prvky ochrany pred zavedeniami škodlivých zmien, ale iba najjednoduchším spôsobom identifikuje kód a poskytuje metadáta na riadenie zraniteľností a analýzu rizík.
- SLSA 2 — rozširuje prvú úroveň požiadavkou na používanie systému správy verzií a zostavovacích služieb, ktoré generujú autentifikované metadáta. Aplikácia SLSA 2 umožňuje sledovať pôvod kódu a zabraňuje neautorizovaným zmenám v kóde, pokiaľ sú použité dôveryhodné zostavovacie služby.
- SLSA 3 — potvrdzuje, že pôvodné texty a zostavovacia platforma spĺňajú požiadavky štandardov, ktoré zaručujú možnosť vykonať audit kódu a zabezpečiť integritu poskytnutých metadát. Predpokladá sa, že audítori môžu certifikovať platformy o zhodu s požiadavkami štandardov.
- SLSA 4 — najvyššia úroveň, ktorá dopĺňa predchádzajúce úrovne nasledujúcimi požiadavkami:
- Povinné preskúmanie všetkých zmien dvoma rôznymi vývojármi.
- Všetky kroky zostavovania, kód a závislosti musia byť plne deklarované, všetky závislosti musia byť osobitne vyextrahované a overené, a proces zostavovania musí prebiehať bez prístupu k sieti.
- Aplikácia procesu opakovateľného zostavenia — možnosť zopakovať proces zostavovania vlastnými silami a overiť, že vykonateľný súbor bol zostavený z poskytnutých pôvodných textov.
Zdroj: opennet.ru
