Log4j kwetsbaarheid | Wat, hoe en waarom?

Wat is log4j? Misschien wel de meest gegoogelde vraag deze week. De Log4j kwetsbaarheid, ook wel bekend als Log4shell en CVE-2021-44228, houdt de gemoederen de laatste tijd flink bezig. Niet zo gek wanneer je je bedenkt dat deze kwetsbaarheid enorm veel bedrijven (potentieel) erg kwetsbaar maakt. Voeg daaraan toe dat deze kwetsbaarheid enorm simplistisch is en je hebt een gevaarlijke combinatie. Maar zoals altijd wordt het weer onnodig moeilijk en complex gemaakt. Daarom leggen wij het gewoon uit op een manier die iedereen begrijpt. Zonder onnodig moeilijk te doen.

Log4J kwetsbaarheid | wat is het?

Laten we bij het begin beginnen. Recentelijk is de kwetsbaarheid publiekelijk ‘log4shell’ aan het licht gekomen. Deze naam dankt de kwetsbaarheid aan het Java framework log4j waar deze kwetsbaarheid in verbogen zit. En wat het doet? Log4shell staat een aanvaller toe om zijn of haar eigen code uit te voeren en uiteindelijk een systeem in zijn geheel over te nemen. Foute boel dus.

En het is al geruime tijd foute boel maar niemand had dat (gelukkig) echt door. Zo werd de kwetsbaarheid in november van dit jaar ontdekt. Op 6 december j.l. werd er vervolgens een update uitgebracht door de ontwikkelaar (Apache) om de kwetsbaarheid te repareren. Helemaal top. De kwetsbaarheid zat er echter al in sinds versie 2.0-beta9. Deze stamt uit 2013! En hoewel de kwetsbaarheid pas sinds 5 december publiekelijk bekend is, zijn er al aanvallen bekend sinds 1 december. Wat de gevolgen van deze aanvallen (zullen) zijn is tot op heden nog onbekend.

En hoe werkt het?..

Ok, nu dat we bekend zijn met de tijdslijn is het tijd om wat dieper in de werking van de kwetsbaarheid te duiken. Dit is waar het technisch wordt maar we zullen ons best doen het simpel te houden. Log4j is een open source logging framework en wordt enorm veel gebruikt overal ter wereld. Het is namelijk de standaard voor logging in Java-applicaties. En heel veel applicaties draaien nou eenmaal op Java. De kwetsbaarheid maakt gebruik van de JNDI-feature van Log4j. De wat? De Java Naming and Directory Interface. Deze functie wordt door Java tijdens het gebruik van de applicatie gebruikt om gegevens in te laden.

Volgt u het tot zover nog? Mooi! We gaan nog even door. Wanneer Log4j een string naar de log schrijft, kijkt het of er nog bepaalde delen moeten worden vervangen. Door de kwetsbaarheid is het echter mogelijk om op dit punt arbitraire java-code in te laden. Dus code van een door de aanvaller gehoste URL. Deze code heeft vervolgens de privileges van de applicatie die wordt misbruikt. En dit stelt de aanvaller in staat om een lijn te openen waarmee de aanvaller op elk moment zijn eigen commando’s kan uitvoeren.

Hoe ga ik dit verhelpen?

Tot zover het technische gedeelte. Belangrijker voor u is natuurlijk de reikwijdte van deze kwetsbaarheid. Met als hamvraag natuurlijk ‘ ben ik kwetsbaar?’. Dat kunnen we niet hier voor u beantwoorden. Wat we wel kunnen zeggen is dat de reikwijdte zeer groot is. Heel veel software draait nou eenmaal op Java. Voeg daaraan toe dat Log4J het standaard logging Framework is en je hebt een flink raakvlak. Zo zijn o.a. applicaties van Amazon AWS, Cloudfare, iCloud, Minecraft, Steam en Tencent getroffen.

De verwachting is dat dit slechts het topje van de ijsberg is. Omdat de kwetsbaarheid zo enorm simpel uit te buiten is zullen er nog (veel) meer slachtoffers volgen vrezen wij. Daarnaast is het opsporen van een aanval zeer lastig omdat het niet in de logs voorkomt. Op firewall niveau is het ook lastig om echt iets te blokeren. Tuurlijk, je kunt zoeken naar bepaalde strings zoals “{jndi:ldap” maar met een beetje technische kennis kan ook deze gemakkelijk verborgen worden.

Wat de oplossing is? Het aanpakken van de oorzaak zelf. Inmiddels is er dus een update vrijgegeven welke de kwetsbaarheid flink limiteert. Deze dient per direct te worden geïnstalleerd. Doet u dit niet dan zet u de deur echt wagenwijd open. Inmiddels is er zelfs al een tweede update vrijgegeven omdat de originele update nog steeds te omzeilen was.