A Google bemutatta az SLSA (Supply-chain Levels for Software Artifacts) keretrendszert, amely összegzi a meglévő tapasztalatokat a fejlesztési infrastruktúra védelméről a kódírás, tesztelés, gyűjtés és termékmegosztás szakaszában bekövetkező támadásokkal szemben.
A fejlesztési folyamatok egyre bonyolultabbá válnak, és egyre inkább függenek harmadik féltől származó eszközöktől, ami kedvező feltételeket teremt az olyan támadások számára, amelyek nem a végtermékben található sérülékenységek azonosítására és kihasználására irányulnak, hanem a fejlesztési folyamat kompromittálására (az „ellátási lánc”-támadások jellemzően a kódírás során végrehajtott rosszindulatú változások beiktatására, valamint a terjesztett komponensek és függőségek helyettesítésére összpontosítanak).
A keretrendszer nyolc támadástípust vesz figyelembe, amelyek a kódfejlesztés, gyűjtés, tesztelés és termékmegosztás szakaszában bekövetkező rosszindulatú változtatásokkal kapcsolatos fenyegetéseket jelentik.
- A. Rosszindulatú változtatások, amelyek hátsó bejáratokat vagy rejtett hibákat tartalmaznak, amelyek sérülékenységeket eredményeznek a forráskódban.
Támadás példája: „Hypocrite Commits” – A Linux kernelébe a sérülékenységekkel rendelkező javítások előmozdításának kísérlete.
A javasolt védelmi módszer: minden változtatás független felülvizsgálata két fejlesztő által.
- B. A forráskód kezelésére szolgáló platform kompromittálása.
Támadás példája: rosszindulatú commitok hátsó bejárattal való beillesztése a PHP projekt Git-tárhelyére a fejlesztők jelszavainak kiszivárgása után.
A javasolt védelmi módszer: A forráskódot kezelő platform védelmének javítása (a PHP esetében a támadást egy kevéssé használt HTTPS-értelmezés útján hajtották végre, amely lehetővé tette a jelszóval való bejelentkezést anélkül, hogy ellenőrizték volna az SSH-kulcsot, miközben a jelszavak hasheléséhez megbízhatatlan MD5-öt használtak).
- C. Változtatások bevezetése a kód átadása során az építési rendszerbe vagy a folyamatos integrációba (a gyűjtött kód nem felel meg a repozitóriumban lévő kódnak).
Támadás példája: hátsó bejárat beillesztése a Webminbe a gyűjtési infrastruktúrába történő változtatásokkal, amelyek olyan fájlokat használnak, amelyek különböznek a repozitóriumban lévő fájloktól.
A javasolt védelmi módszer: A kód forrásának ellenőrzése és az integritás az építési folyamat során. szerveren.
- D. Az építési platform kompromittálása.
Támadás példája: a SolarWinds támadása, amely során az építési szakaszban hátsó bejárat beiktatása történt a SolarWinds Orion termékbe.
Javasolt védelmi módszer: kiterjesztett biztonsági intézkedések bevezetése a gyűjtőplatform védelme érdekében.
- E. Rossz minőségű függőségek által terjesztett rosszindulatú kód.
Támadási példa: hátsó ajtó bevezetése a népszerű event-stream könyvtárba ártalmatlan függőség hozzáadásával, amelyet később egy ilyen függőség frissítésében rosszindulatú kódra cseréltek (a rosszindulatú módosítás nem volt látható a git-reposzitoriumban, csak a kész MNP-csomagban volt jelen).
Javasolt védelmi módszer: az SLSA követelmények rekurzív alkalmazása minden függőségre (az event-stream esetében a vizsgálat kimutatta volna, hogy a kód összegyűjtése nem felel meg a fő Git-reposzitorium tartalmának).
- F. Olyan artefaktumok letöltése, amelyeket nem a CI/CD rendszerben készítettek.
Támadási példa: rosszindulatú kód hozzáadása a CodeCov szkripthez, amely lehetővé tette a támadók számára, hogy információt nyerjenek ki a folyamatos integrációs rendszerek környezeteiben tárolt adatokból.
Javasolt védelmi módszer: az artefaktumok forrásának és épségének ellenőrzése (a CodeCov esetén megállapítható lett volna, hogy a codecov.io webhelyről szolgáltatott Bash Uploader szkript nem felel meg a projekt reposzitoriumának kódjának).
- G. Csomagrepository kompromittálása.
Támadási példa: kutatóknak sikerült népszerű csomagrepositoryk tükörképét létrehozniuk, a rosszindulatú csomagok terjesztésének céljából.
Javasolt védelmi módszer: Ellenőrizni kell, hogy a terjesztett artefaktumok a megadott forráskódokból készültek.
- H. A felhasználót zavarba ejtő csomag telepítése.
Támadási példa: a típusra való rászorítás (NPM, RubyGems, PyPI) használata a csomagrepositorykban, amelyek írásban hasonlítanak a népszerű alkalmazásokra (például coffe-script a coffee-script helyett).
A megjelölt fenyegetések blokkolására az SLSA ajánl egy sor javaslatot, valamint automatizálási eszközöket a nyilvántartási metaadatok létrehozásához. Az SLSA összefoglalja a tipikus támadási módszereket, és bevezeti a védelmi szintek fogalmát. Minden szint bizonyos követelményeket támaszt az infrastruktúrával szemben, amelyek garantálják a fejlesztés során használt artefaktumok épségét. Minél magasabb az SLSA támogatott szintje, annál több védelmi eszköz van érvényben, és annál biztonságosabb az infrastruktúra a tipikus támadásokkal szemben.
- SLSA 1 — teljesen automatizált gyártási folyamatot követel meg, amely metadátumokat generál a gyűjtés folyamatáról, beleértve az forrástextusokat, függőségeket és a gyártási folyamatot (a GitHub Actions esetében példát javasoltak a metadátumok auditálására). A SLSA 1 nem tartalmaz védelmet a kártékony módosítások ellen, csupán az egyszerű kódazonosítást biztosítja, és metadátumokat nyújt a sebezhetőségek kezeléséhez és kockázatelemzéshez.
- SLSA 2 — kiterjeszti az első szintet az verziókezelő rendszer és az autentikált metadátumokat generáló gyártó szolgáltatások használatának követelményével. A SLSA 2 alkalmazása lehetővé teszi a kód származásának nyomon követését, és megakadályozza a jogosulatlan módosítások végrehajtását a kódban, ha megbízható gyártószolgáltatásokat használnak.
- SLSA 3 — megerősíti, hogy a forrástextusok és a gyártási platform megfelel a szabványok követelményeinek, amelyek garantálják a kód auditálásának lehetőségét és a megadott metadátumok integritását. Feltételezhető, hogy az auditorok képesek tanúsítani a platformok megfelelőségét a szabványoknak.
- SLSA 4 — a legmagasabb szint, amely kiegészíti az előző szinteket a következő követelményekkel:
- Minden módosítás kötelező felülvizsgálata két különböző fejlesztő által.
- Minden gyártási lépés, kód és függőség teljes mértékben deklarálva kell legyen, minden függőséget külön kell kinyerni és ellenőrizni, és a gyártási folyamatnak hálózati hozzáférés nélkül kell végbe mennie.
- A megismételhető gyártási folyamat alkalmazása — lehetőség arra, hogy a gyártási folyamatot saját magunk ismételjük meg, és biztosítsuk, hogy az végrehajtható fájl a megadott forrástextusokból készült.
Forrás: opennet.ru
