In Log4j, een logging service voor Java-applicaties, is een zero-day vulnerability bekend gemaakt. De kwetsbaarheid is verholpen in versie 2.15.0, die sinds vrijdag 10 december beschikbaar is. True heeft haar klanten proactief op de hoogte gebracht en werkt samen met hen aan een oplossing. In deze blog antwoorden op de belangrijkste vragen over deze kwetsbaarheid en wat je kunt doen. Onderaan deze blog vind je updates.
Wat is er aan de hand?
Donderdag 9 december is er een zero-day kwetsbaarheid in Log4j gevonden. Dit maakt het mogelijk om op afstand willekeurige code uit te voeren met de rechten van de Log4j gebruiker. In veel gevallen is dat de webserver. Die zijn over het algemeen beperkt. Alle versies van Log4j tussen 2 en 2.14.1 zijn kwetsbaar.
Als een aanvaller log messages of log messages parameters kan besturen, en als message lookup substitution is geactiveerd, dan kan de aanvaller ook willekeurige code uitvoeren. Bijvoorbeeld in de vorm van het opstarten van een reverse shell, waardoor de aanvaller bij alle data kan waar de Log4j gebruiker toegang toe heeft.
Daarnaast is er een proof-of-concept, waaruit blijkt er daadwerkelijk misbruik van de kwetsbaarheid te maken is. Het Nationaal Cyber Security Centrum (NCSC) schaalt deze kwetsbaarheid dan ook hoog in. De organisatie heeft een lijst gemaakt met alle tot nu toe bekende getroffen software, waaronder Apache, Amazon en VMWare (de lijst is mogelijk niet volledig en wordt geüpdatet). De Duitse evenknie van het NCSC meldt dat er al succesvolle aanvallen met deze vulnerability zijn geweest.
Waar is het mee op te lossen?
De kwetsbaarheid is verholpen in Log4j versie 2.15.0, die sinds vrijdag 10 december uit is. Daarin staat message lookup substitution standaard uitgeschakeld.
Als updaten niet mogelijk is, is de applicatie opnieuw te starten met de directive “log4j2.formatMsgNoLookups=True”, met gebruik van “%m{nolookups}” in de PatternLayout configuratie en het verwijderen van JdniLookup en JdniManager classes uit log4j-core.jar
Er is een groot nadeel aan deze directive: is je applicatie afhankelijk van lookups bij verwerken en weergeven van data, dat heeft dit gevolgen voor de werking van je applicatie. Patchen zal met kennis van zowel de applicatie als de logging service moeten gebeuren.
Wat moet ik als klant van True doen?
Alle klanten van True zijn vrijdag 10 december direct geïnformeerd over de kwetsbaarheid. Onze engineers zijn alle services nagelopen die van Log4j gebruik maken. Klanten die daarvan gebruik maken, zijn verder geïnformeerd. Samen met hen zorgen we voor het patchen van deze vulnerability, passend bij hun applicatie en gebruikte hosting-oplossing.
Belangrijk is wel om je eigen applicatie op het gebruik van Log4j te controleren. Daarvoor zijn scripts voor Linux en Windows beschikbaar, waaronder Log4jcheck, Log4j powershell checker en Log4shell detector. Let wel op: deze scripts bieden geen 100% garantie dat je geen kwetsbare systemen draait.
Maak je als klant van True geen of maar gedeeltelijk gebruik van True SLA? Controleer dan vervolgens of de software-leverancier een update beschikbaar heeft en voer deze uit als het geen gevolgen heeft voor de werking van je applicatie. Sommige leveranciers kiezen voor mitigatie en geven aan hoe dat door te voeren. Controleer ook je systemen op mogelijk misbruik in de afgelopen weken.
Is het voor je systeem niet mogelijk om de versie te updaten óf om de aangegeven maatregelen door te voeren? Wellicht kun je dan overwegen om het systeem uit te schakelen tot er een update is of dat maatregelen wel mogelijk zijn.
Wat doet True om dit op te lossen?
“We zijn vrijdag eerst direct gaan kijken welke services hier gebruik van maken en gaan zoeken op de kwetsbare versies van Log4j. Ook zijn we direct aan de slag gegaan met kijken hoe we het kunnen patchen of andere maatregelen moeten doorvoeren. Denk daarbij aan het plaatsen van WAF-regels in ons Advanced Security Platform. Daardoor kon er direct geen misbruik worden gemaakt van systemen van klanten die achter dat platform zitten”, zegt Ron Ursem, Automation Engineer bij True. “Sommige services, waaronder ElasticSearch, zullen wanneer we een update uitvoeren, in tussenstappen moeten worden geüpdatet naar een Log4j versie waar deze specifieke vulnerability niet in zit.”
Ron: “Daarnaast helpen we ook klanten bij vragen hierover. Bijvoorbeeld als er gedacht wordt dat Apache webserver, MongoDB, Redis of Nginx kwetsbaar zijn. Dat is alleen het geval als een product binnen deze services gebruik maakt van Log4j versie 2.0 of hoger.”
Update 19 december: ook versie 2.15.0 kwetsbaar
Op woensdag 15 december bleek dat ook versie 2.15.0 nog kwetsbaar is als deze gebruik maakt van non-default configuraties. Waar die kwetsbaarheid eerder nog op een lagere severity werd ingeschat, is deze inmiddels ook naar het bijna hoogste niveau gegaan. Deze vulnerability is verholpen in versie 2.16.0, waarin de JNDI functionaliteit standaard uit staat.
Voor klanten van True hebben engineers dit gat gedicht waar bekend, in de nacht van 17 op 18 december. De gehele JNDI lookup class is uitgezet, waarna services op de machines zijn herstart.
