De noodpatch voor de beruchte kwetsbaarheid in Java-bibliotheek Log4j is niet waterdicht. De Apache Software Foundation brengt een nieuwe versie uit om de kwetsbaarheid voor eens en voor altijd te verhelpen.
Een kwetsbaarheid in een razend populaire bibliotheek voor Java schudt het wereldwijde IT-landschap door elkaar. Naar schatting bestaat de bibliotheek in de meeste bedrijfsomgevingen.
Log4j wordt voornamelijk gebruikt voor logging. Gebeurtenissen in applicaties kunnen worden geregistreerd met notities. Denk aan een afdruk van de inloggegevens na een inlogpoging. Of, in het geval van een webtoepassing in Java, de naam van de browser waarmee een gebruiker verbinding probeert te maken.
De laatste voorbeelden komen veel voor. In beide gevallen beïnvloedt een externe gebruiker het logboek dat Log4j uitvoert. Het is mogelijk om die invloed te misbruiken. De logs van elke Log4j-versie tussen 13 september 2013 en 5 december 2021 kunnen Java-applicaties instrueren om de code uit te voeren vanaf een externe server op een lokaal apparaat.
Sinds 2013 verwerkt Log4j een API: JNDI, oftewel Java Naming and Directory Interface. Door de toevoeging van JNDI kan een Java-toepassing code uitvoeren vanaf een externe server op een lokaal apparaat. Programmeurs geven instructies door een enkele regel met details over de externe server in een toepassing toe te voegen.
Het probleem is dat niet alleen programmeurs de regel aan applicaties kunnen toevoegen. Stel dat Log4j de gebruikersnamen van inlogpogingen logt. Wanneer iemand de bovengenoemde regel in het gebruikersnaamveld invoert, voert Log4j de regel uit en interpreteert de Java-toepassing een opdracht om de code op de opgegeven server uit te voeren. Hetzelfde geldt voor gevallen waarin Log4j een HTTPS-verzoek logt. Als u een browsernaam in de regel wijzigt, voert Log4j de regel uit en geeft deze indirect opdracht om de code naar wens uit te voeren.
Noodpatch kan ook onveilig zijn
Op 9 december kwam de kwetsbaarheid op grote schaal aan het licht. De Apache Software Foundation, ontwikkelaar van Log4j, heeft een noodpatch (2.15) uitgebracht om de kwetsbaarheid te verhelpen. Sindsdien is het een topprioriteit voor softwareleveranciers om versie 2.15 te verwerken en een patch voor organisaties te leveren.
Beveiligingsorganisatie LunaSec stelt echter dat de patch niet helemaal waterdicht is. Het blijft mogelijk om een instelling aan te passen en gelogde JNDI-commando's te laten uitvoeren.
Let op: de betreffende instelling moet handmatig worden aangepast, zodat ongewijzigde varianten van 2.15 inderdaad veilig zijn. Desalniettemin raadt Luna Sec leveranciers en organisaties aan om te updaten naar Log4j 2.16. 2.16 is gepubliceerd door Apache Software Foundation als reactie op LunaSec. De nieuwe versie verwijdert de kwetsbare instelling volledig, waardoor het onmogelijk is om de voorwaarden voor misbruik te creëren.