Log4j: Situatie is nog steeds code rood voor ON2IT CIRT

Laatste update: 20 december, 15:00

Op donderdag 9 december werd een ernstige kwetsbaarheid ontdekt in de veelgebruikte Apache Log4j Java logging library (Log4j). Via deze route is een ongeauthentiseerde, ongeautoriseerde RCE (Remote Code Execution) mogelijk, waarmee een server kan worden overgenomen. Een oplossing was zeer snel beschikbaar, maar het uitrollen van deze oplossing is in de praktijk een tijdrovende operatie.

Inmiddels is de Log4j kwetsbaarheid acht dagen bekend. Wat is er sindsdien verder duidelijk, wat moet je zeker gedaan hebben en waar moet je nu mee bezig zijn? CTO Lieuwe Jan Koning en Lead Architect Rob Maas zijn sinds vrijdagavond onderdeel van het ON2IT Log4j CIRT (Cybersecurity Incident Response Team). Wat waren hun prioriteiten in de afgelopen dagen, en wat adviseren ze onze klanten?

“Wat Log4J bijzonder maakt is dat nagenoeg iedere organisatie een nog steeds groeiende lijst met kwetsbare applicaties heeft die gepatcht moeten worden”, zegt Rob Maas.

“Dat klinkt makkelijker gezegd dan gedaan. De uitdaging is dat de Log4j in bijna alle op Java-gebaseerde applicaties wordt toegepast. Dit betekent dat organisaties meerdere applicaties, en mogelijk ook kritieke business applicaties, zo snel als kan moeten patchen. Dit zorgt voor een grote impact, ook op beschikbaarheid voor gebruikers, maar patchen is de meest effectieve maatregel.”

ON2IT helpt organisaties desgevraagd bij het snel en efficiënt lokaliseren van applicaties die kwetsbaar zijn. In aanvulling daarop worden in overleg met klanten “spoed Zero Trust policies” uitgerold in firewalls, vooral om outbound verkeer te blokkeren.

Maar deze mitigerende maatregelen zijn niet de oplossing, er komen steeds nieuwe aanvallen bij waardoor deze blocklijsten continu moeten worden gewijzigd.

“Een groot probleem is dat niet alle leveranciers al naar buiten hebben gebracht of hun applicatie kwetsbaar is en wanneer een patch mag worden verwacht” vult Lieuwe Jan Koning, CTO bij ON2IT aan.

De Apache Log4j logging library moet naar tenminste versie 2.17.0 worden geüpdatet. Als aanvullende tegenmaatregel stelt ON2IT blocklijsten samen en werkt die continu bij, Die bevatten IP-adressen en hostnames die momenteel door hackers actief worden gebruikt om het lek uit te buiten.

Deze lijsten worden op firewalls geïmplementeerd, om het deze hackers zo moeilijk mogelijk te maken. Maar deze mitigerende maatregelen zijn niet de oplossing, er komen steeds nieuwe aanvallen bij waardoor deze blocklijsten continu moeten worden gewijzigd. Hetzelfde geldt voor andere mitigaties, zoals IPS signatures. Daarnaast kunnen deze blocklijsten tegen aanvallen van binnenuit weinig uitrichten.”

Koning adviseert dan ook om alle verkeer op uitgaande servers per direct te blokkeren en alleen zeer specifiek uitgaand verkeer toe te staan waar nodig. Dit werkt volgens hem grotendeels. Helaas niet afdoende, omdat informatie (zoals wachtwoorden) alsnog via het DNS protocol kan lekken. Omdat nagenoeg alle servers DNS nodig hebben om te kunnen functioneren, kan dit dus niet uitgezet worden.

Belangrijk is om van elke leverancier die de technologie als (half)fabricaat levert, een patch of een workaround te verkrijgen. Leveranciers zullen in de regel inmiddels de urgentie inzien, maar druk opvoeren om deze te leveren is hier op zijn plaats.

Is er al een patch beschikbaar? Installeer deze zo snel mogelijk. Zo niet, doe een risico analyse en bepaal wat er moet gebeuren.

Veel klanten maken de overweging om de test en ontwikkelomgevingen geheel af te sluiten van het internet en de rest van de IT-omgeving, dan wel geheel uit te zetten, en eerst te focussen op de kritieke systemen. Zeker in een niet-gesegmenteerde omgeving, waarbij productie- en testomgeving “door elkaar” lopen, is dit aan te raden.

Volgens Koning is het bij deze kwetsbaarheid van belang om alle servers en applicaties na te lopen en te bepalen wat er moet gebeuren.

“Is er al een patch beschikbaar? Installeer deze zo snel mogelijk. Zo niet, doe een risico analyse en bepaal wat er moet gebeuren. Moeten er andere mitigerende maatregelen worden toegepast, zoals een configuratiewijzing van de applicatie, of het uitzetten van de betreffende servers? Door deze oefening zorgvuldig, gestructureerd en gedocumenteerd te doen, kan de impact worden verkleind. Denk ook aan toezichthouders of auditors die mogelijk “after the fact” handelingen willen kunnen volgen”.

High/High beveiligingsadvies

Rob Maas wijst op de lijst van het NCSC die bijhoudt welke applicaties een risico vormen. Deze lijst van kwetsbare applicaties biedt een goed startpunt, maar de lijst is nog lang niet volledig en zal de komende dagen worden aangevuld met informatie over applicaties die nog niet op de lijst staan. Deze NCSC-pagina wordt ook gebruikt om scan- en detectiemogelijkheden (scripts) en Indicators of Compromise bekend te maken.

Het NCSC heeft ook hele duidelijke instructies uitgevaardigd en een stappenplan opgesteld. Het NCSC kan niet voor iedere applicatie die gebruik maakt van Log4j het beveiligingsadvies updaten. Een vermelding van een applicatie op deze lijst mag daarom worden gezien als een update van het HIGH/HIGH beveiligingsadvies (hoge kans op grote schade).

Ons advies

Vanuit risicobeheersing adviseren wij in ieder geval uitputtend te inventariseren of Log4j v2 in jouw technologielandschap wordt gebruikt. Denk ook aan derde partijen die software voor jou ontwikkelen en ook aan externe libraries die worden gebruikt, zoals in content managementsystemen. Ook die leveranciers moeten die systemen namelijk updaten. Denk hierbij zeker ook aan je cloud-assets!

Wees je ervan bewust dat ook systemen zonder internetverbinding risico kunnen lopen.

Om de inventarisatie uit te voeren kan gebruik worden gemaakt van applicatielijsten of CMDB’s om vervolgens verschillende scripts te draaien om te identificeren of Log4j gebruikt wordt. Dit kan zicht geven op waar en welke versie gebruikt wordt.

Ook verschillende kwetsbaarheidsscanners hebben updates of plugins uitgebracht om te controleren of systemen kwetsbaar zijn. Ook deze zijn te vinden op de NCSC-site. Omdat deze scanners nooit 100% garantie geven adviseren we om dubbel te controleren. ON2IT kan eventueel assisteren bij dergelijke diepgaander onderzoeken.

Wees je ervan bewust dat ook systemen zonder internetverbinding risico kunnen lopen. Aanvallen van binnenuit zijn ook waarschijnlijk. Een “landscape check” waarbij alle systemen worden beoordeeld op mogelijke gevoeligheid voor misbruik door deze kwetsbaarheid, maar ook een toetsing of er mogelijk al misbruik is gemaakt van deze kwetsbaarheid is aan te raden.

Maas en Koning geven aan dat klanten die hun cybersecuritymaatregelen volgens de strategische principes van Zero Trust inrichten een kleinere impact kennen, omdat er dan actiever gebruik gemaakt wordt van segmentatie, waardoor de blast ratio kleiner is, inspectie van verkeer actiever plaatsvindt en updates op securityproducten beter worden bewaakt.

Nu het huis in brand staat, is het nog veel te vroeg voor vragen als “hoe hadden we dit kunnen voorkomen?” en “hoe richten we on patchbeleid beter in?”.

Ook de rol van bijvoorbeeld compliance en leveranciersbeheer zijn belangrijk. Never waste a good crisis, is een veel gehoorde wijsheid. Dit is hier zeker aan de orde. Hier zullen we de komende weken uitgebreid aandacht aan geven.