Computable.be
  • Thema’s
    • Security & Awareness
    • Cloud & Infrastructuur
    • Data & AI
    • Software Innovation
  • Computable Awards
    • Nieuws Computable Awards
    • Hall of Fame
  • Cybersec e-Magazine
  • Kennisbank
  • Inlog
  • Nieuwsbrief
lek

Vierde lek ‘op rij’ in Apache Log4j2

29 december 2021 - 09:52ActueelCloud & Infrastructuur
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

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.

Meer over

ApacheExploitsJavaOpensource

Deel

Fout: Contact formulier niet gevonden.

Meer lezen

helikopter Belgisch leger defensie
ActueelOverheid

Ministerie van Defensie aangevallen via Log4j-lek

ActueelSecurity & Awareness

Ook patch voor Log4j blijkt lek te zijn

ActueelSecurity & Awareness

NCSC deelt kwetsbare Log4j-applicaties op Github

alarm
ActueelOverheid

NCSC slaat alarm om kwetsbaarheid in Apache Log4j

ActueelSecurity & Awareness

Log4j-exploitatie ettert door

OpinieCloud & Infrastructuur

Zo beschermt bedrijf zich tegen Log4Shell

Geef een reactie Reactie annuleren

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Populaire berichten

Meer artikelen

Footer

Direct naar

  • Kennisbank
  • Computable Awards
  • Colofon
  • Cybersec e-Magazine

Producten

  • Adverteren en meer…
  • Persberichten

Contact

  • Contact
  • Nieuwsbrief

Social

  • Facebook
  • X
  • LinkedIn
  • YouTube
  • Instagram
© 2025 Jaarbeurs
  • Disclaimer
  • Gebruikersvoorwaarden
  • Privacy statement
Computable.be is een product van Jaarbeurs