De spoedpatch voor de beruchte kwetsbaarheid in Java library Log4j is niet waterdicht. De Apache Software Foundation publiceert een nieuwe versie om de kwetsbaarheid voor eens en altijd uit de wereld te helpen.
Een kwetsbaarheid in een razendpopulaire library voor Java zet het wereldwijde IT-landschap op scherp. Naar schatting komt de library in de meeste bedrijfsomgevingen voor.
Log4j wordt hoofdzakelijk gebruikt om te loggen. Gebeurtenissen in applicaties zijn te registreren met notities. Denk aan een uitdraai van de inloggegevens na een inlogpoging. Of, in het geval van een webapplicatie in Java, de naam van de browser waarmee een gebruiker probeert te verbinden.
Lees ook: Log4Shell: wat is Log4j, wie raakt het en hoe patch je het?
De laatstgenoemde voorbeelden zijn veelvoorkomend. In beide gevallen heeft een externe gebruiker invloed op de log die Log4j uitdraait. Het is mogelijk om die invloed te misbruiken. De logs van elke Log4j-versie tussen 13 september 2013 en 5 december 2021 zijn in staat om Java-applicaties te instrueren om de code van een externe server op een lokaal apparaat uit te voeren.
Sinds 2013 verwerkt Log4j een API: JNDI, ofwel Java Naming and Directory Interface. De toevoeging van JNDI stelt een Java-applicatie in staat om de code van een externe server op een lokaal apparaat uit te voeren. Programmeurs geven opdracht door een enkele regel met details over de externe server in een applicatie toe te voegen.
Het probleem is dat niet alleen programmeurs in staat blijken om de regel aan applicaties toe te voegen. Stel dat Log4j de gebruikersnamen van inlogpogingen logt. Vult iemand de eerdergenoemde regel in het veld voor een gebruikersnaam in, dan draait Log4j de regel uit en interpreteert de Java-applicatie een opdracht om de code op de gespecificeerde server uit te voeren. Hetzelfde geldt voor gevallen waar Log4j een HTTPS request logt. Verander je een browsernaam naar de regel, dan draait Log4j de regel uit, en geeft het indirect opdracht om code naar wens uit te voeren.
Ook spoedpatch kan onveilig zijn
Op 9 december kwam de kwetsbaarheid grootschalig aan het licht. De Apache Software Foundation, ontwikkelaar van Log4j, publiceerde een spoedpatch (2.15) om de kwetsbaarheid op te lossen. Sindsdien is het voor softwareleveranciers een topprioriteit om versie 2.15 te verwerken en een patch voor organisaties aan te bieden.
Securityorganisatie LunaSec stelt echter dat de patch niet volledig waterdicht is. Het blijft mogelijk om een setting aan te passen en gelogde JNDI-opdrachten uit te laten voeren.
Let wel: de betreffende setting moet handmatig aangepast worden, waardoor onaangepaste varianten van 2.15 wel degelijk veilig zijn. Desondanks raadt Luna Sec leveranciers en organisaties aan om naar Log4j 2.16 te updaten. 2.16 werd in reactie op LunaSec door Apache Software Foundation gepubliceerd. De nieuwe versie werkt de kwetsbare setting volledig weg, waardoor het onmogelijk is om de voorwaarden voor misbruik te scheppen.
8 uur geleden
