Vierde lek 'op rij' in Apache Log4j2

29 december 2021 10:51 | Alfred Monterie

Het houdt maar niet op. Apache Log4j2 ontpopt zich als ‘een gebed zonder einde’. It-beheerders die toch al geen gemakkelijk jaar hadden, kunnen weer aan de slag. Opnieuw is er een beveiligingslek in Log4j, een veelgebruikte logbibliotheek. 2021 eindigt daarmee zoals het was begonnen. De afgelopen jaarwisseling stond in het teken van Solarwinds, ditmaal verstoort Log4j de rust waar ook security-mensen recht op hebben.

Het nieuwe lek dat gisterenavond door Apache werd bevestigd, maakt het mogelijk om in bepaalde gevallen zonder toestemming malafide code op een systeem toe te passen. Aanvallers kunnen daardoor de volledige server van een bedrijf of instelling overnemen. De impact van het nieuwe lek is iets minder groot dan bij twee van de drie vorige lekken. Maar een score van 6,6 op een schaal van 10 is nog steeds vrij ernstig. Er zit dus niets anders op dan wederom te patchen.

Apache heeft een beveiligingsupdate uitgebracht (Log4j 2.17.1) om het probleem dat de boeken ingaat als CVE-2021-44832 te verhelpen. Ook nu is het devies weer: meteen doen. Ook als je de afgelopen dagen alle updates hebt doorgevoerd, is het zaak om deze update snel te regelen.

Nog geen grote rampen

Lees ook

Log4j2: de perfecte supply chain attack?

Het beveiligingslek bevindt zich in de Log4j2 versies 2.0-beta7 tot en met 2.17.0. Alleen de ‘security fix’-versies 2.3.2 en 2.12.4 zijn uitgezonderd. Het probleem doet zich voor wanneer een aanvaller erin slaagt de broncode en implementatieprocedures van een toepassing te beheren. Hij moet dus eerst het logging-configuratiebestand aanpassen. Het gaat mis als deze vervolgens een malafide configuratie aanmaakt waarbij wordt verwezen naar een Java Naming and Directory Interface (JNDI) URI die code op afstand kan uitvoeren. Doordat een aanvaller eerst het configuratiebestand moet aanpassen is de impact van de kwetsbaarheid lager beoordeeld dan eerdere RCE-kwetsbaarheden (remote execution) in Log4j.

Het probleem is verholpen door de JDDI data-bron-namen te beperken tot het Java protocol in de Log4j2 versies 2.3.2 (voor Java 6), 2.12.4 (voor Java 7) of 2.17.1 (voor Java 8 en nieuwer). Sinds 9 december zijn vier verschillende lekken gevonden.

Tot grote rampen heeft Log4j nog niet geleid. Maar beveiligingsexperts vrezen dat het ergste nog moet komen. Cyberexpert Eddy Willems betoogde onlangs in Computable dat Log4j2 tot op zekere hoogte vergelijkbaar is met de Solarwinds supply-chain-aanval. Alleen moet bij de opensourcesoftware van Apache nog worden afgewacht wat de volledige impact zal zijn. Willems voorspelde dat we de komende maanden hier nog de handen vol aan gaan hebben.