Derde spoedpatch voor wijdverspreid Log4j

De Apache Software Foundation (ASF) heeft dus afgelopen zaterdag de derde update voor Log4j uitgebracht. Die opensourcetool komt daarmee op versie 2.17.0 en dat betekent wéér updatewerk voor beheerders maar ook voor ontwikkelaars en leveranciers. Een flink deel van het grote probleem met Log4j is namelijk dat het zit verwerkt in tools, applicaties, serversoftware en ook hardwareproducten van derden.

Nieuwste update níet topprioiriteit

Het tempo waarin patches uitkomen voor Log4j is nu wat opgevoerd: update 2.16.0 is afgelopen week uitgebracht. De kritische en internationale aandacht voor de code van deze Java-loggingsoftware is sinds eervorige week vrijdag dan ook flink opgeschaald. Toen werd publiekelijk bekend dat de tool aanvallers de mogelijkheid geeft om op vele verschillende manieren input af te vuren die ervoor zorgt dat eigen, kwaadaardige code op afstand kan worden uitgevoerd (RCE) op kwetsbare systemen.

De nieuwste DoS-kwetsbaarheid is minder ernstig dan de RCE-kwetsbaarheid die oorspronkelijk in Log4j zit. Toch is de situatie ernstig. Het Nationaal Cyber Security Centrum (NCSC) van de Nederlandse overheid raadt echter aan om éérst oudere Log4j-installaties op te sporen en te patchen, om het RCE-gevaar in 2.15.0 eerder aan te pakken. Gebruikers die al naar 2.16.0 zijn gegaan, moeten 2.17.0 dus iets minder prioriteit geven dan eventuele resterende - al dan niet nog niet 'gevonden' - versies die ouder zijn. De Nederlandse scantool van DIVD en DTAC is al bijgewerkt om de nieuwste kwetsbaarheden en patch mee te nemen.

Lopende en slapende aanvallen

De eerste spoedpatch (2.15.0) die het grote RCE-gevaar moest bezweren, is daar namelijk niet geheel succesvol in. Dit is afgelopen week al gebleken. Bepaalde configuraties van Log4j zijn dan namelijk toch nog vatbaar. De voorspelde aanvalsgolven, zowel van statelijke actoren als van opportunistische cybercriminelen, zijn al op gang gekomen.

De sombere verwachting van security-experts en beveiligingsleveranciers is dat deze security-inbreuken mogelijk over enige tijd nog een opleving kunnen krijgen. Dat zou dan gebeuren doordat snelle aanvallers al gelijk binnen zijn gekomen bij organisaties en bedrijven waar Log4j draait. Vervolgens hebben die succesvolle indringers zich koest gehouden. Een eerste geval van misbruik van de zogeheten Log4Shell-zeroday blijkt nu na analyse met kennis van de kritieke kwetsbaarheid al op 1 december te zijn gepleegd. Dat is grofweg een week vóór de publieke onthulling en het begin van het lopende Log4j-securitydrama.