Log4j kwetsbaarheid

12 december 2021

Afgelopen vrijdag maakte security onderzoeksbureau LunaSec bekend dat er een '0-day' kwetsbaarheid was ontdekt in Log4j. Deze kwetsbaarheid maakt het voor aanvallers eenvoudig mogelijk om een 'Remote Code Execution' (RCE) aanval uit te voeren op applicaties die deze Java logging library gebruiken.

Wat wordt er geraakt?

Log4j is een softwarecomponent die veelal wordt ingezet in applicaties die zijn geschreven in de programmeertaal Java. Op servers die wij voor onze klanten beheren betreft dat bijvoorbeeld Java maatwerk applicaties, maar we zien Log4j ook terug in applicaties als Elasticsearch, Solr, SonarQube en Jitsi. Het gaat specifiek om Log4j versie 2.0 tot en met 2.14. Log4j versies 1.x zijn niet kwetsbaar, de kwetsbaarheid is geintroduceerd in Log4j 2.0. 

In onze loggingsystemen zagen we de eerste pogingen om de kwetsbaarheid te misbruiken op de vroege zaterdagochtend binnenkomen. Deze pogingen zijn gericht op willekeurige applicaties, ook applicaties die log4j helemaal niet gebruiken.

Wat is de oplossing?

De oplossing is het updaten van Log4j naar de gisteren uitgebrachte nieuwe 2.15.0 release. In deze release is de kwetsbaarheid opgelost. Omdat leveranciers van software die Log4j gebruikt zelf enige dagen werk zullen hebben om een nieuwe release uit te brengen, zijn er in de tussentijd andere maatregelen mogelijk:

• een recente Java versie gebruiken: de aanvalsvector die momenteel wordt gebruikt is niet te misbruiken op de laatste versies van Java. Op de servers die wij beheren is de Java versie in de meeste gevallen actueel. Dit wordt tijdens de maandelijkse security audits gecontroleerd en in de server rapportages wordt melding gemaakt als er oude Java versies gevonden zijn met een voorstel om deze te updaten;
• de verwerking van code instructies in Log4j uitzetten: er is een instelling beschikbaar waarmee de verwerking van de code instructies voor een aantal Log4j versies (2.10 t/m 2.14) kan worden uitgezet. Waar mogelijk hebben we dit reeds toegepast.

Er zijn nog uitgebreidere mogelijkheden om de aanval te stoppen, maar met de bovenstaande maatregelen zou de kwetsbaarheid niet meer misbruikt kunnen worden

Acties uitgevoerd door Opserve

Opserve heeft de afgelopen dagen gezocht op servers naar kwetsbare log4j versies en waar deze gevonden werden support tickets aangemaakt en aangegeven wat de oplossing is om de kwetsbaarheid te verhelpen.

Het zoeken naar log4j gebruik kan in sommige gevallen lastig zijn. Als log4j wordt gebruikt in een Docker container, dan kan het zijn dat we deze met onze zoekacties niet kunnen vinden. Ook kan de Java versie in een Docker container niet up to date zijn. De developers die de Docker container beheren bepalen welke Java versie er wordt gebruikt. Als er Docker containers op de server van een klant in gebruik zijn waarvan we vermoeden dat er Log4j in gebruikt wordt, dan hebben we daar melding van gemaakt bij onze klant.

Verwarring over de Apache webserver

In sommige berichten wordt aangegeven dat de Apache webserver ook kwetsbaar zou zijn. Dit is niet juist. De verwarring ontstaat doordat Log4j wordt onderhouden binnen de Apache open source community, die tevens het onderhoud uitvoert aan de Apache httpd webserver. Maar de Apache httpd webserver gebruikt Log4j niet en is dus niet kwetsbaar.