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
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.
“Het probleem doet zich voor wanneer een aanvaller erin slaagt de broncode en implementatieprocedures van een toepassing te beheren”
als de aanvaller al zover binnen is, waarom zou die dan nog behoefte hebben om een applicatie aan te passen ?
@dino,
omdat de aanvaller misschien de credit card data van klanten van je web winkel als werkelijke doel voor ogen heeft?
@swa
daar heb je punt.
Tjsa Dino, SWA heeft een goed punt over data want waarom moeilijk doen als het makkelijk kan met open source waarvan de betrouwbaarheid van de bron niet gecontroleerd is. Implementatieprocedure om malafide configuraties te voorkomen begint een dingetje te worden in modulaire stacks die als een slordig breiwerk zijn.
Het gaat maar door. De kosten die moeten worden gemaakt om dit probleem op te lossen blijven maar stijgen, en het einde lijkt nog (lang) niet in zicht.