De Log4-shitstorm: alles wat je moet weten

(Hoe) halen we de Kerst?

Zo tijdens de donkeredagen voor Kerst en nog omringd door maatregelen van de voortdurende pandemie, steekt nu wederom een kwaadaardige kwetsbaarheid in wereldwijde ICT-omgevingen de kop op. Het NCSC heeft deze nieuwe kwetsbaarheid (CVE-2021-44228 of kortweg Log4Shell) direct de hoogste kwalificatie gegeven: met een 10 op de schaal van 1 tot 10 of HIGH/HIGH, oftewel er is een serieuze grote kans op grote schade. De kwetsbaarheid zit ingesloten in de Apache Log4j software die breed wordt ingezet door heel veel software ontwikkelaars vanwege de vele voordelen en het gebruiksgemak die het biedt. Hierdoor is helaas ook de kans heel groot dat ongeautoriseerde gebruikers (hackers) zonder al te veel moeite zich toegang weten te verschaffen tot uiteenlopende systemen, omdat niet altijd bekend is waar de Log4j software is toegepast en welke versie actief is.

Direct na de ontdekking is er wereldwijd groot alarm geslagen, zowel vanwege het schijnbare gemak om deze kwetsbaarheid te misbruiken, de brede beschikbaarheid van de kwetsbaarheid, het feit dat er al direct gebruik van is gemaakt en het feit dat de impact op bedrijven en de samenleving enorm kan zijn. Naast de 10 van het NCSC heeft Duitsland inmiddels hiervoor een code Rood afgegeven, “ontploft” het internet van de waarschuwingen en melden alle grote software ontwikkelaars hun reacties en adviezen. Grote namen als Microsoft, Oracle, RedHat, ElasticSearch, VMware, maar ook Twitter, Amazon, Apple (iCloud) en Minecraft hebben al aangegeven kwetsbaar te (kunnen) zijn en zijn alert.

Plan van aanpak

Paniek is nooit een goede raadgever en er zijn middels ook (iets) geruststellender berichten. Voorop staat dat een planmatige aanpak nodig is waarin als eerste binnen de eigen organisatie de mogelijke aanwezigheid van de kwetsbaarheid in kaart moet worden gebracht. Er zijn al meldingen van de aanwezigheid van acties op deze kwetsbaarheid die teruggaan tot begin december 2021, dus de controles dienen verder te gaan dan alleen een actuele scan. Het NCSC biedt als voorbeeld voor zo’n planmatige aanpak een duidelijk stappenplan met ook enkele handvatten en tools van derden, maar inmiddels hebben ook verschillende cybersecurity ontwikkelaar hiervoor tools of add-ons op hun toepassingen ontwikkeld die organisaties hierbij kunnen helpen.

Better safe than sorry

Direct actie ondernemen is in deze situatie een eerste vereiste. Gezien het concrete gevaar op inbraak met alle gevolgen van dien, kan het afsluiten van alle externe toegang tot (mogelijk) kwetsbare systemen een goede eerste stap zijn; ook wanneer dit leidt tot productiviteitsverlies of vermindering van dienstverlening. Met een inventarisatie van de mogelijke probleemsystemen kan daarna stapsgewijs weer worden opgeschaald. Veel software ontwikkelaars hebben inmiddels ofwel een oplossing in de vorm van een update of upgrade of bieden een ‘workaround’.

Sluipmoordenaar

Inmiddels heeft men wereldwijd ontdekt dat op veel plaatsen hackers deze Apache Log4j kwetsbaarheid al snel hebben benut om zich toegang te verschaffen tot uiteenlopende systemen, maar tot echte uitval of kaping van systemen of datadiefstal heeft dit vooralsnog niet geleid. Experts verwachten daarom dat deze toegang vooral is gebruikt voor het plaatsen van malware en ransomware die zich voorlopig op de achtergrond zal houden en later kan (en zal) worden geactiveerd. Het is daarom van cruciaal belang dat ook hierop wordt gecontroleerd en dat iedere afwijking van standaarden of van normaal systeemgedrag direct worden gedetecteerd en acties ter voorkoming van erger worden genomen. Antimalware and anti-ransomware oplossingen zijn meer dan ooit nu van groot belang. Ook dienen de recente systeem- en databackups te worden gecontroleerd, aangezien zij ook al geïnfecteerd zouden kunnen zijn en veilige terugvalbasis zouden kunnen garanderen.

• Onderzoek binnen uw organisatie waar Apache Log4j wordt gebruikt en waar dus de mogelijke kwetsbaarheden zich kunnen bevinden (oa vulnerability scan)
• Upgrade naar versie 2.16.x (Java 8 benodigd). (Nb; 2.15.0-rc1 is niet voldoende) of upgrade de software c.q. de appliance. Voor oudere log4j kunt u de JndiLookup.class hernoemen/verwijderen. Merk op dat elk project dat nog steeds log4x 1.x gebruikt, een verouderde en niet-ondersteunde versie heeft met andere bekende kwetsbaarheden – CVE-2019-17571 is CVSS 9.8(!)
• Als u log4j niet kunt upgraden, kunt u de RCE-kwetsbaarheid impact verkleinen door log4j2.formatMsgNoLookups in te stellen op True -Dlog4j2.formatMsgNoLookups=true in JVM-opdrachtregel) (maar alleen voor >= 2.10.0). Gebruikers van Log4j 2.10 of hoger kunnen -Dlog4j2.formatMsgNoLookups=true als opdrachtregeloptie toevoegen of log4j2.formatMsgNoLookups=true toevoegen aan een log4j2.component.properties-bestand op het klassenpad om lookups in het loggebeurtenisbericht te voorkomen. Gebruikers van Log4j 2.7 kunnen %m{nolookups} specificeren in de PatternLayout-configuratie om lookups in het loggebeurtenisbericht te voorkomen. Verwijder de klassen JndiLookup en JndiManager uit de log4j-core jar. Als de JndiManager wordt verwijderd, werken de JndiContextSelector en JMSAppender niet meer.
• Gebruik in uw onderzoek en scans de NCSC Log4j GitHub als bron voor IOC’s, Links naar scanmogelijkheden en lijst met vendoren en producten / software die wel of niet kwetsbaar zijn. Zie https://github.com/NCSC-NL/log4shell voor de lijsten
• Pas op de aanwezig installaties direct de meest actuele versie (2.16.0) toe waarmee de problemen worden voorkomen. Is die toepassing om bepaalde reden niet mogelijk, volg dan de adviezen van de Apache Foundation https://logging.apache.org/log4j/2.x/security.html (patching)
• Controleer (of installeer) afdoende beveiliging op alle betrokken serversystemen op bescherming tegen oa. ransomware (secure)
• Monitor alle serversystemen op afwijkend gedrag (threathunting); met name op uitgaande verbindingen

Context (Wie en Wat)

• Impact: Uitvoering van willekeurige code (arbitrary code execution). Code kan worden opgehaald van het openbare internet, of lolbins die al op het systeem aanwezig zijn, of gewoon ‘shared secrets’ of omgevingsvariabelen ophalen en teruggeven aan de aanvaller
• Doelen: servers en clients die Java uitvoeren en ook alles loggen met behulp van het log4j-framework – in de eerste plaats een probleem aan de serverzijde, maar elk kwetsbaar eindpunt kan een doel of een draaipunt zijn
• Downstream-projecten: totdat het tegendeel is bewezen, ga ervan uit dat alles dat log4j bevat, of afhankelijk is van iets dat dat wel doet, wordt beïnvloed op een manier die mitigatie vereist; zie onder
• Betreffende versies: log4j 2.x bevestigd – log4j 1.x alleen indirect (vorige kwetsbaarheden bij het vrijgeven van informatie, moeilijker te misbruiken). Ook is de aanwezigheid van 1.x niet goed – 1.x ging EOL in augustus 2015!
• Apparaten: vergeet apparaten en andere systemen of systemen van derden niet, die mogelijk Java-servercomponenten gebruiken, maar niet zullen worden gedetecteerd door niet-gelegitimeerde kwetsbaarheidsscans of eenvoudige exploitatietests (geen toegang tot etc.)
• Doorsturen van logbestanden: loginfrastructuur heeft vaak veel “noordelijke” (stuur mijn logs naar iemand) en “zuidelijke” (logs van iemand ontvangen) doorstuur-/relaytopologieën. Er moet ook worden overwogen om ze aan elkaar te koppelen voor uitbuiting.
• Cloud: ook meerdere grote providers getroffen

Scope / Ernst

• “mensen vergelijken #log4shell “zo erg als heartbleed” – dat is niet juist, is het veel, veel erger. Afgezien van het hebben van RCE als de impact, is het aantal onderlinge afhankelijkheden rond log4j (en vooral de leeftijd ervan) orden van grootte hoger” – @caseyjohnellis
• “Wat mensen lijken te missen: de #Log4Shell-kwetsbaarheid is niet zomaar een RCE 0day. Het is een kwetsbaarheid die honderden en duizenden 0days veroorzaakt in allerlei softwareproducten. Het is een 0day clusterbom.” –@cyb3rops (Florian Roth)
• “Een project met een footprint als Log4j is niet te vermijden als een tijdelijke afhankelijkheid, zelfs als je het niet rechtstreeks importeert. Log4j is een canoniek hulpprogramma voor het loggen van een enorm ecosysteem. De huidige reikwijdte ervan gaat verder dan due diligence doen.” – @rakyll (AWS)
• Het Wikipedia-artikel over log4j is informatief om het gebruik en de reikwijdte te begrijpen (https://en.wikipedia.org/wiki/Log4j)
• Vroegste detectie bekend: 2021-12-01 04:36:50 UTC
• Verkeerde benamingen: Nee, het wordt ook niet LogJam genoemd. Die naam is al in gebruik. (De eerste LunaSec-post gebruikte die naam en koos vervolgens een nieuwe zodra ze erachter kwamen.)
• Uitspraak: de hoofdauteur spreekt het uit als “log 4 jay”, niet “logforge”

Belangrijke informatie en handvatten:

• NCSC: https://www.ncsc.nl/actueel/nieuws/2021/december/12/kwetsbare-log4j-applicaties-en-te-nemen-stappen
• NCSC: https://www.ncsc.nl/actueel/advisory?id=NCSC-2021-1052
• CVE Mitre: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• NIST: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• GovCERT: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/