Afgelopen week is er een critical vulnerability bekend gemaakt in log4j (CVE-2021-44228) [1][2]. Log4j is een zeer populair logging library voor Java en wordt daarom in veel Java libraries, frameworks en applicaties gebruikt. Zelfs Ingenuity, de Helikopter op Mars gebruikt Log4j!
Omdat Log4j zo populair is, betekent dit dat de hoeveelheid applicaties die vatbaar zijn voor de security vulnerability waarschijnlijk ook erg groot is. Op het moment heeft niemand nog een goed beeld welke applicaties nu vatbaar zijn, maar het Nationaal Cyber Security Centrum van de Nederlandse Overheid is bezig met een inventarisatie [3].
HET SECURITY PROBLEEM
Het security probleem betreft het op afstand uitvoeren van willekeurige code (ook wel Remote Code Execution genoemd). Met een simpele string (b.v “${jndi:ldap://127.0.0.1:1389/a}”) kan een persoon al de aanval uitvoeren met behulp van template injection [4]. De impact van dit security probleem is erg groot, omdat het vaak een kwaadwillende de mogelijkheid geeft de server over te nemen (om daar bijvoorbeeld ransomware te installeren, of informatie op te vragen waar je niet bij hoort te komen). Omdat log4j per applicatie anders gebruikt kan worden, zal het per applicatie ook verschillen hoe deze misbruikt kan worden. Op het moment bestaan er al proof of concepts die demonstreren hoe je het security probleem kan misbruiken (voor producten van o.a. Elastic, Apache, VMWare, RedHat etc.).
HET PROBLEEM OPLOSSEN
Aangezien veel software leveranciers nog geen update hebben uitgebracht van hun software, is het nu de vraag wat je tegen deze security vulnerability kan doen. Er bestaan een paar patch mogelijkheden die de impact kunnen beperken totdat er updates uit komen voor deze producten. Hierbij heeft het updaten naar de laatste versie altijd de voorkeur, maar indien dit niet direct mogelijk is bestaan er nog de volgende manieren:
UPGRADEN NAAR LOG4J 2.17.0
Hierin is het probleem opgelost
LOG4J 2.10.0 – 2.14.2
System Property log4j2.formatMsgNoLookups op true zetten
Environment variabele LOG4J_FORMAT_MSG_NO_LOOKUPS op true zetten
LOG4J 2.0-BETA9 – 2.10.0
org/apache/logging/log4j/core/lookup/JndiLookup.class verwijderen van het classpath. Dit is mogelijk met deze handige one-liner:
Het instellen van de log4j2.formatMsgNoLookups property wordt ook als tijdelijke mitigatie geadviseerd door het NCSC [2]. Hiernaast kan het updaten naar Java JDK 6u211, 7u201, 8u191, en 11.0.1 of hoger (>=12) ook gedeeltelijk helpen, maar dit beschermt niet in alle gevallen [1]. Bij het updaten naar de laatste JDK versie wordt namelijk de property com.sun.jndi.ldap.object.trustURLCodebase standaard op false gezet, maar het is in sommige gevallen nog steeds mogelijk om remote code execution te krijgen via Log4j. Overigens bevat Log4j versie 1 deze specifieke security vulnerability niet, maar daar zijn andere security vulnerabilities bekend, en wordt ook geadviseerd om te updaten.
De voorkeur gaat nog altijd uit naar het updaten, de mitigaties zijn een tijdelijke oplossing. Voor Java applicaties die in-house worden ontwikkeld, wordt aangeraden zo snel mogelijk te upgraden naar Log4j versie >= 2.17.0.
[1] https://www.lunasec.io/docs/blog/log4j-zero-day/
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-44228
[3] https://ncsc.nl/actueel/nieuws/2021/december/12/kwetsbare-log4j-applicaties-en-te-nemen-stappen
[4] https://issues.apache.org/jira/browse/LOG4J2-3202
