A Google bemutatta az OSS Rebuild projektet, amely a közzétett csomagokban rejlő rejtett változások azonosítására szolgál, a tárolókban. Az OSS Rebuild működése a reprodukálható build koncepcióján alapul, és arra összpontosít, hogy ellenőrizze a tárolókban található csomag megfelelőségét a referencia forráskód alapján újraépített csomaggal, amely a csomag nyilvánosan meghirdetett verziójának felel meg. Az eszközkészlet kódja Go nyelven készült, és Apache 2.0 licenc alatt érhető el.
Jelenleg az OSS Rebuild támogatja az NPM (JavaScript/TypeScript), PyPI (Python) és Crates.io (Rust) tárolókból származó csomagok ellenőrzését. A jövőben terveik között szerepel a támogatott tárolók számának bővítése. A gyakorlatban az eszközkészlet lehetővé teszi a „supply chain” típusú támadások azonosítását, amelyek során kompromittált kísérő fiókok vagy a projekten belüli diverzió után a tárolóban rosszindulatú frissítéseket tesznek közzé. Ilyenkor a fő projekt forráskódjában lévő kód helyes marad, a rosszindulatú változtatások csak a kész csomagokba kerülnek beépítésre.
A rendszer lehetőségeihez mérten automatikusan létrehoz egy forgatókönyvet a kiválasztott csomag reprodukálható buildjéhez, heuristikákat használva, és paramétereket összeállítva, amelyek lehetővé teszik az aritfaktumok azonosságának elérését, amelyeket a csomagban biztosítanak. Ha automatikusan nem sikerül a tárolóban található csomagot reprodukálni, lehetőség van a build specifikáció kézi hozzáadására. Miután a csomag reprodukálását sikerült végrehajtani, az OSS Rebuild eszközkészlet menti a build folyamatának leírását az új csomagverziók későbbi ellenőrzéséhez. Emellett kiadásra kerül egy információ az SLSA keretrendszert felhasználó ellenőrzéshez.
A konkrét csomagverzió ellenőrzése után igazoló adatokat generálnak, amelyeket mások felhasználhatnak már ellenőrzött csomagok értékelésére. Az ellenőrzés elvégezhető parancssori eszköz futtatásával vagy egy külön felhőtárolóban tárolt hash összehasonlításával. A csomagok ellenőrzésére szolgáló infrastruktúra felállítható a saját szerveren. Használhatjuk a Google által több ezer csomagon végzett ellenőrzések információit is.
Az OSS Rebuild által védett támadási módszerek példái között szerepel a hátsó ajtó hozzáadása az XZ-hez, rosszindulatú kód beillesztése a Solana kriptovaluta hivatalos JavaScript-ügyfélbe, és változtatások behelyezése a changed-files műveletkezelőn keresztül.
- Az XZ projekt esetében a tárolóban lévő kód nem tartalmazott gyanús módosításokat, miközben a hátsó ajtót létrehozó rosszindulatú komponensek a XZ kibővítésének teszteléséhez használt fájlokban voltak jelen. A hátsó ajtó a build rendszeren aktiválódott, és az XZ forráskódja megegyezett a tárolóban található kóddal. A hátsó ajtó aktiváló m4 makrói az Automake eszközkészletéhez csak a kód kész archivált változatában voltak benne, és hiányoztak a tárolóból. Az ilyen típusú támadások észlelésére az OSS Rebuild dinamikus elemzést alkalmaz a csomagban található artefaktumok, végrehajtási útvonalak és gyanús műveletek vonatkozásában.
- A @solana/web3.js könyvtárba történő rosszindulatú változások beillesztése a fenntartó fiókjának kompromittálásából adódott, társadalmi manipulációs és adathalászati módszerek alkalmazásával. A NPM tárolóban új kiadás készült, amely a rosszindulatú módosításokat tartalmazta. A projekt Git-tárolójában ez a kiadás nem készült el, és a rosszindulatú módosítások csak az eredménycsomagban voltak jelen. Ilyen esetben a védelem arra összpontosít, hogy a csomagban észleljék a fő tárolóból hiányzó kódot.
- A changed-files kezelő tárolójának kompromittálása lehetővé tette a támadást olyan projektek ellen, amelyek a files és könyvtárak változásainak nyomon követésére használják a GitHub Actions alapú folyamatos integrációs infrastruktúrát. A változtatások behelyezésének megakadályozására a build környezet kompromittálása után az OSS Rebuild nyomon követi a változásokat és a gyanús aktivitást a standardizált minimalizált build környezetekben.
Forrás: opennet.ru
