Společnost Google představila rámec SLSA (Supply-chain Levels for Software Artifacts), který shrnuje dosavadní zkušenosti v ochraně vývoje před útoky, které se vyskytují během fáze psaní kódu, testování, sestavování a distribuce produktu.
Vývojové procesy se stávají stále složitějšími a závislejšími na externích nástrojích, což vytváří příznivé podmínky pro útoky, které nesouvisí se zjišťováním a zneužíváním zranitelností v konečném produktu, ale s kompromitací samotného vývojového procesu (útoky „supply chain“, které mají obvykle za cíl zavádění škodlivých změn během psaní kódu, nahrazování distribuovaných komponent a závislostí).
Rámec zohledňuje 8 typů útoků spojených s hrozbami nařízení škodlivých změn během fáze vývoje kódu, sestavování, testování a distribuce produktu.
- A. Vkládání změn do zdrojového kódu, které obsahují backdoory nebo skryté chyby vedoucí k zranitelnostem.
Příklad útoku: „Hypocrite Commits“ – pokus o prosazení patchů se zranitelnostmi do jádra Linuxu.
Navrhovaná metoda ochrany: nezávislé přezkoumání každé změny dvěma vývojáři.
- B. Kompromitace platformy pro správu zdrojového kódu.
Příklad útoku: zavedení škodlivých commity s backdoorem do Git repozitáře projektu PHP po úniku hesel vývojářů.
Navrhovaná metoda ochrany: Zvýšení ochrany platformy pro správu kódu (v případě PHP byl útok proveden prostřednictvím málo používaného HTTPS rozhraní, které umožňovalo odesílání změn po přihlášení heslem bez kontroly SSH klíče, přičemž pro hashování hesel byl použit nedůvěryhodný MD5).
- C. Vkládání změn během přenosu kódu do systému sestavování nebo kontinuální integrace (sestavuje se kód, který neodpovídá kódu v repozitáři).
Příklad útoku: zavedení backdooru do Webmin prostřednictvím změn v sestavovací infrastruktuře, které vedly k použití souborů s kódem, které byly odlišné od souborů v repozitáři.
Navrhovaná metoda ochrany: Kontrola integrity a identifikace zdroje příchozího kódu do sestavovacího procesu. serveru.
- D. Kompromitace sestavovací platformy.
Příklad útoku: útok SolarWinds, během něhož bylo během fáze sestavování zajištěno zavedení backdooru do produktu SolarWinds Orion.
Navrhovaná metoda ochrany: zavedení rozšířených opatření pro zabezpečení sestavovací platformy.
- E. Šíření škodlivého kódu prostřednictvím nekvalitních závislostí.
Příklad útoku: zavedení zadního kanálu do populární knihovny event-stream přidáním neškodné závislosti, která se následně zařadila do jedné z aktualizací této závislosti, obsahující škodlivý kód (škodlivá změna nebyla zaznamenána v gitovém repozitáři, ale byla přítomna pouze v hotovém MNP balíčku).
Navrhovaná metoda ochrany: rekurzivní uplatnění 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: kontrola zdroje a integrity artefaktů (v případě CodeCov by mohlo být zjištěno, že skript Bash Uploader stahovaný z webu codecov.io neodpovídá kódu z projektu).
- G. Kompromitace repozitáře balíčků.
Příklad útoku: výzkumníci se dokázali nasadit zrcadla některých populárních repozitářů balíčků s cílem šířit prostřednictvím nich škodlivé balíčky.
Navrhovaná metoda ochrany: Ověření, ž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: využití type-squatting (NPM, RubyGems, PyPI) k umístění do repozitářů balíčků, které se písemně podobají populárním aplikacím (například coffe-script místo coffee-script).
Pro blokaci uvedených hrozeb SLSA nabízí sadu doporučení a také nástroje pro automatizaci vytváření metadat pro audit. SLSA shrnuje typické 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 ochran byla zavedena a tím lépe je infrastruktura chráněna proti typickým útokům.
- SLSA 1 — vyžaduje, aby byl proces sestavování plně automatizován a generoval metadata o tom, jak byly artefakty sestaveny, včetně informací o původních textech, závislostech a procesu sestavení (pro GitHub Actions byl navržen příklad generátoru metadat pro audit). SLSA 1 nezahrnuje prvky ochrany proti škodlivým změnám, pouze jednoduchým způsobem identifikuje kód a poskytuje metadata pro řízení zranitelností a analýzu rizik.
- SLSA 2 — rozšiřuje první úroveň požadavkem na použití systému správy verzí a sestavovacích služeb, které generují autentizovaná metadata. Použití SLSA 2 umožňuje sledovat původ kódu a zabraňuje neoprávněným změnám kódu v případě použití důvěryhodných sestavovacích služeb.
- SLSA 3 — potvrzuje, že původní texty a sestavovací platforma splňují požadavky norem, které zajišťují auditovatelnost kódu a integritu poskytnutých metadat. Předpokládá se, že auditoři mohou certifikovat platformy na základě souladu s normami.
- SLSA 4 — nejvyšší úroveň, která doplňuje předchozí úrovně dalšími požadavky:
- Povinné přezkoumání všech změn dvěma různými vývojáři.
- Všechny kroky sestavování, kód a závislosti musí být plně deklarovány, všechny závislosti musí být odděleně extrahovány a ověřeny, a proces sestávání musí být prováděn bez přístupu k síti.
- Použití procesu opakovatelného sestavování — možnost opakovat proces sestavování vlastními silami a ujistit se, že spustitelný soubor byl sestaven z poskytnutých původních textů.
Zdroj: opennet.ru
