Vierde lek 'op rij' in Apache Log4j2

Dit artikel delen:
lek

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.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-12-29T10:51:00.000Z Alfred Monterie
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.