Log4j logoOpnieuw lijkt de securitywereld in brand te staan door een ernstige kwetsbaarheid. Op vrijdag werden systeembeheerders en securitywerknemers ruw van de vrijmibo weggesleurd om een bug in een wijdverspreide Java-library te patchen. Maar 'Log4Shell' is misschien wel te groot geworden om snel even te fixen. Wat weten we na een hectisch weekend precies over de bug?

Wat is Log4Shell?

Log4Shell is de onofficiële naam voor de kwetsbaarheid CVE-2021-44228. Als kwetsbaarheden groot genoeg zijn en lang genoeg rondgaan, krijgen ze vanzelf een merknaam. Log4Shell is vernoemd naar log4j, de Java-feature waar de kwetsbaarheid in zit. De bug werd afgelopen donderdag naar buiten gebracht, en vrijdag, zaterdag en zondag raakte het internet ineens in rep en roer. Dat heeft met name te maken met drie dingen: met Log4Shell kan een aanvaller veel schade veroorzaken en de kwetsbaarheid komt op heel veel plekken voor. Ook speelt mee dat het relatief simpel is om een aanval uit te voeren. Niet alleen beveiligingsexperts, maar ook nationale overheden en grote techbedrijven waarschuwen voor de kwetsbaarheid. Op het moment zou de kwetsbaarheid ook al actief worden uitgebuit, maar desondanks lijken er nog geen grote diensten te zijn geïnfiltreerd of omgevallen.

Log4j-aanval

Hoe werkt de bug?

CVE-2021-44228 is een kwetsbaarheid in de Java-library log4j. Die valt onder de paraplu van de Apache Foundation, die vooral bekend is van de populaire webserversoftware, maar de kwetsbaarheid zit niet specifiek in die server. De log4j-library wordt veel in Java ontwikkelde applicaties gebruikt voor het loggen van informatie, zoals welk apparaat een server aanspreekt en vanaf welke locatie zodat dat later terug te vinden is door systeembeheerders. Log4j is niet zomaar een logginglibrary; het is dé logginglibrary. Er zijn veel andere libraries en loggingtools, maar log4j is de populairste en wordt dan ook in veel stukken software standaard meegenomen. De bug kan worden uitgebuit door simpelweg te zorgen dat een bepaalde string in de log4j-logs terechtkomt. Dat is het enige dat nodig is om van een afstand een systeem over te nemen. Dat kan remote en zonder dat er authenticatie nodig is op een systeem.

Die eenvoud is wat de aanval zo gevaarlijk maakt. Dat werkt als volgt. De log4j-functie kan berichten loggen met daarin format-strings om externe informatie op te halen. Dat wordt gedaan door de Java Naming and Directory Interface-functie, ofwel JNDI. Die kan informatie remote ophalen via meerdere protocollen, waaronder het veelgebruikte LDAP. Log4j voert Java-classes uit waar een LDAP-server naar verwijst. Met andere woorden: als een aanvaller een bepaalde string, ${jndi:ldap://LINK/a}, in een log kan krijgen, kan die daarmee een url inladen. Van daaruit is het mogelijk Java-code uit te voeren op een systeem. Vanaf dat moment is er heel veel mogelijk: door een netwerk bewegen, authenticaties omzeilen, of malwarepayloads inladen vanuit een externe bron.

Het is een fluitje van een cent om apparaten te infecterenDie Java-code in de logs krijgen, is vaak een fluitje van een cent. Het enige echte vereiste voor een aanvaller is dat het systeem op internet is aangesloten. Een e-mail met de string in de header kan bijvoorbeeld al genoeg zijn, of zorgen dat iemand op een server op een pagina komt waar de string in is geladen. Sommige hackers filosofeerden op Twitter bijvoorbeeld al over manieren om een user agent van de browser aan te passen naar de exploit-string. In dat geval hoef je alleen nog maar een server aan te spreken vanuit de browser. Volgens Tweakers-bofh Kees Hoekzema gebeurt dat op dit moment ook op Tweakers.net. "Dat gebeurt op talloze manieren: van de simpele 'ik verander zoveel mogelijk in '${jndi' tot volledige exploits in een url."

Als een aanvaller eenmaal binnen is in een netwerk kan log4j ook nog verder misbruikt worden. In dat geval kan een aanvaller de exploit gebruiken om door een netwerk heen te bewegen, zelfs als dat netwerk alleen intern benaderbaar is. Het is niet voldoende om een string te blokkeren in een firewall, maar dat lijkt een zinloze aanpak. De string kan namelijk op tientallen manieren geobfusceerd worden en zo door die filters heen komen. Patchen is de enige manier om een exploit te voorkomen.

Nieuwe en oude versies
De kwetsbaarheden zitten specifiek in log4j2. Dat zijn versies 2.0 tot en met 2.14.1. Aanvankelijk was er discussie over de vraag of log4j 1.x-versies ook kwetsbaar waren voor Log4Shell. Het leek in eerste instantie alsof ook oudere versies konden worden getroffen, maar dat werd later ontkracht door de ontdekkers. De feature die praktische uitbuiting mogelijk maakt, namelijk ondersteuning voor JNDI, werd pas in log4j 2.0-beta9 toegevoegd. Wel is het mogelijk om die ondersteuning later toe te voegen in een netwerk, waardoor specifieke, oudere log4j-configuraties alsnog kwetsbaar kunnen zijn. Apache heeft de kwetsbaarheid gerepareerd in log4j 2.15.0. Daarin is het niet meer mogelijk om code vanaf een LDAP-server op te halen via de JNDI-parser. Daarnaast is er een mitigatie beschikbaar voor releases onder 2.10. Beheerders die log4j2.formatMsgNoLookups op true zetten, zouden voorlopig niet kwetsbaar zijn. Experts raden hen wel aan alsnog de update door te voeren zodra dat mogelijk is. Inmiddels is er ook een nog recentere update uit, namelijk log4j 2.16.0. Daarin is JNDI standaard uitgeschakeld. Beheerders kunnen nog wel via log4j2.enableJndi de functie inschakelen als ze die nodig hebben.

Responsible disclosure
De kwetsbaarheid werd eerder dit jaar ontdekt door beveiligingsonderzoeker Chen Zhaojun van Alibaba's interne Cloud Security Team. Die gaf dat op 24 november door aan de hoofdontwikkelaars. Release log4j 2.15.0 met daarin een patch vond plaats op 6 december. Opvallend is dat sommige onderzoekers zeggen dat er al vóór die tijd actieve exploitatie plaatsvond. Zowel Talos als Matthew Prince van Cloudflare bevestigen dat. De eerste exploits zouden al op 1 december hebben plaatsgevonden, maar nog niet op grote schaal. Het is niet bekend om wat voor aanvallen dat ging.

Waar zit dit allemaal in?

Wat de situatie van dit weekend zo ingewikkeld maakt, is dat het niet makkelijk is om log4j op te sporen. In de eerste plaats is het geen applicatie die ontwikkelaars bewust in een systeem implementeren, omdat het beter is dan anderen; het is de de facto standaardapplicatie om in Java logs aan te maken en de meeste ontwikkelaars die een Java-app beheren, staan er niet bij stil dat die specifiek log4j bevat. Ook maakt de manier waarop Java-packages werken het moeilijk de specifieke library te vinden. Die worden als Java Archive-files of jar-files verpakt. Jar-files kunnen ook weer andere jar-files bevatten om dependencies te laten werken. Dat maakt dat log4j misschien wel meerdere lagen diep in een app wordt gebruikt en een systeem er onbewust gebruik van kan maken. Sommige experts zeggen dan ook dat geen enkele organisatie er nog vanuit kan gaan níét kwetsbaar te zijn.

Volgens onderzoekers van Sonatype zou log4j de afgelopen vier maanden al 28,6 miljoen keer zijn gedownload. Log4j komt zelfs buiten de aarde voor: volgens de Apache Software Foundation wordt het pakket gebruikt in de Mars-helikopter Ingenuity.

Sonatype Log4J

De software is niet alleen moeilijk te vinden vanwege de wijdverspreidheid. Daar komt bij dat het moeilijk is om een actieve exploitatie op te sporen in het systeem. Dat komt uitgerekend door de manier waarop JNDI werkt. Als de string geparset wordt door JNDI wordt die juist niet gelogd. Dus ironisch genoeg heb je er niks aan om je logs te checken als je wilt weten of je systeem geïnfecteerd is.

De crisis kent ook lichtpuntjes. Er zijn inmiddels veel securityonderzoekers en -bedrijven mee bezig die hun eigen detectie- en mitigatietools beschikbaar stellen aan anderen. Zo zijn er tools zoals die van Huntress of Trend Micro waarmee het mogelijk is applicaties te testen op de Log4Shell-kwetsbaarheid.

Hoe groot is het probleem nu

Dave Maasland van securitybedrijf ESET noemt Log4Shell 'digitale asbest': "Men weet niet precies waar het allemaal is gebruikt, maar wel dat het potentieel zeer schadelijk is en waarschijnlijk duurt het nog wel even voor we de echte impact weten." Dat lijkt een goede beschrijving van de situatie. Log4j zit ingebakken in zoveel libraries en sublibraries dat het heel moeilijk zal zijn om ze ooit allemaal op te sporen in een netwerk. Inmiddels zijn er veel lijsten online beschikbaar die diensten verzamelen die gebruikmaken van log4j en daarmee in potentie kwetsbaar zijn. Die lijsten lijken angstaanjagend lang. Kijk maar eens naar deze gecrowdsourcete lijst, of naar de lijst die het Nationaal Cyber Security Centrum bijhoudt. Veel verschillende bedrijven hebben inmiddels al gezegd dat ze log4j hebben gevonden in hun software en dat ze werken aan oplossingen. Daaronder vallen bijvoorbeeld IBMOracleAWS en Microsoft. De kwetsbaarheid blijkt in veel van hun softwarepakketten te zitten en daarom ook bij veel andere bedrijven te worden gebruikt.

Dat maakt dat de alarmbellen van securityexperts hevig afgaan, maar op dit moment lijkt de schade nog mee te vallen. Er zijn vooralsnog geen grote bedrijven die plotseling tot stilstand kwamen door ransomware, of zoals SolarWinds geïnfiltreerd blijken te zijn door spionagemalware. Sommige bedrijven en instituten waarschuwen voor 'actief misbruik'. Hoewel dat eng klinkt, zijn er wel wat nuances bij te plaatsen. Neem de waarschuwing van het Digital Trust Center, dat zich weer baseert op informatie van het Nationaal Cyber Security Centrum. Dat zegt 'meldingen te ontvangen dat de kwetsbaarheid actief wordt misbruikt'. Het NCSC heeft zelf geen honeypots draaien en het eigen onderzoek is voornamelijk op openbare bronnen gebaseerd. De meeste informatie die de overheidsinstellingen krijgen, komt van externe beveiligingsonderzoekers. Als die het hebben over 'actief misbruik' is daar wel wat op aan te merken.

Er zijn verschillende beveiligingsonderzoekers die zeggen dat hun honeypots vooral scanningsverkeer zien van andere securitybedrijven. Dat is niet gek, want die bedrijven willen weten hoe groot de omvang van Log4Shell is en dat begint bij het aantal kwetsbare systemen. Maar in hun blogposts wordt weinig onderscheid gemaakt tussen echte aanvallen op een honeypot, of een simpele scan. Bij sommige securitybedrijven gaat het dan wel weer om echte aanvalspogingen. ESET zegt bijvoorbeeld dat het bedrijf 'honderdduizenden uitbuitingspogingen' ziet, waaronder veel in Nederland. Die pogingen komen niet binnen op honeypots, zegt ceo Dave Maasland, maar van klanten van het bedrijf.

De vraag is dus hoe wijdverspreid de aanvallen zijn en hoe vaak ze voorkomen. Talos, de beveiligingstak van Cisco, schrijft bijvoorbeeld in een blogpost dat het bedrijf 'het gebruik van bedreigingen via e-mail heeft gezien' waarmee de kwetsbaarheid wordt getriggerd. Maar of dat nou toevallig een keer is voorgekomen, tegenover hoeveel accounts, en of het op honeypots gebeurde of bij klanten; al die zaken zijn niet bekend. Ook securitybedrijf Greynoise, dat als een van de eerste bedrijven melding maakte van Log4Shell-activiteit, meldt dat het voornamelijk gaat om scans die criminelen uitvoeren. Een algemeen beeld over de ernst ontbreekt dus, al zijn er wel veel aanwijzingen dat criminelen zich klaarmaken om later toe te slaan op grotere schaal.

Log4shell

Exploits en wat er dan gebeurt

Wat in ieder geval duidelijk is, is dat op het internet exploits voor de bug circuleren. Daarmee kan de kwetsbaarheid meteen worden uitgevoerd. Er zijn proofs-of-concept opgedoken waarmee bijvoorbeeld Minecraft kan worden aangevallen, of meer algemeen webservers.

Vooralsnog lijken er vooral twee soorten malware te bestaan die misbruik van Log4Shell maken. Cryptominers en botnets zijn het populairst, zeggen onderzoekers. Het SANS Instituut zegt dat het malware heeft gevonden die via PowerShell een cryptominer installeert op Windows. Ook Sophos zegt dat het zulke cryptominers heeft gezien. Volgens Trend Micro zou het gaan om de Kinsing-cryptominer.

Volgens het Chinese Netlab van Qihoo 360 zijn er ook twee botnets gevonden die Log4Shell uitbuiten. Het Mirai-botnet doet dat, maar ook Muhstik, dat code heeft dat grotendeels op Mirai is gebaseerd. Muhstik zou via ssh een achterdeur in servers openen om zo apparaten op te nemen in het botnet. Ook andere, minder bekende securitybedrijven zoals Cado Security zeggen activiteit in Mirai en Muhstik te zien. Autoriteiten zoals het Zwitserse CERT zeggen daar bewijs voor te hebben gezien.

Ransomware

Vooralsnog zijn er geen actieve aanvallen met ransomware te zien. Je zou misschien verwachten dat dat sneller zou gebeuren, maar eigenlijk is het best logisch. Zowel cryptominers als botnets zijn namelijk grotendeels geautomatiseerd. Ze komen op een systeem en doen waarvoor ze geprogrammeerd zijn. Daarom kan Mirai redelijk snel worden aangepast en weer worden losgelaten op kwetsbare systemen. Voor die malware is voornamelijk de aanvalsvector belangrijk en daar is Log4Shell goed in. Voor ransomware is de aanvalsvector slechts een eerste stap van velen. Voor de rest van een infectie is een meer handmatige aanpak nodig, met hackers die zich eerst door een netwerk heen bewegen en bepaalde functies uitschakelen of authenticatie omzeilen. De kans is volgens experts groot dat Log4Shell op termijn zal worden gebruikt om op netwerken in te breken. Misschien is dat ook al wel gebeurd, maar gaat het nog lang duren voordat daarvan de resultaten in de vorm van ransomware te zien zijn.

Eerder al tijdens BlackHat?

De afgelopen dagen ging een hardnekkig gerucht rond dat Log4Shell al jaren bekend was. De kwetsbaarheid zou al in 2016 zijn gepresenteerd tijdens hackersconferentie BlackHat. Inderdaad werd daar een presentatie gegeven over iets soortgelijks, maar de praktijk was anders. De presentatie van Alvaro Munoz en Oleksandr Mirosh behandelde weliswaar JDNI- en LDAP-injecties, maar ging niet specifiek over hoe dat ging in log4j. Hun bijdrage ging over JNDI als aanvalsvector, maar niet specifiek over hoe dat in log4j werd gebruikt. Het is mogelijk dat de ontdekkers van Log4Shell nu de link hebben gelegd tussen log4j en JNDI, maar het is niet zo alsof log4j al sinds 2016 lek was.

Log4Shell

Conclusie

Log4j lijkt nu vooral nog een stilte voor een grote storm. Misschien is het wel geen storm die hard toeslaat, ravage aanricht en dan doorgaat. Misschien is log4j wel beter vergelijkbaar met klimaatverandering: een langzame realisatie dat er in de toekomst nog veel problemen gaan voorkomen, maar dat het moeilijk te voorspellen is waar, wanneer en in welke mate. Het is een probleem waarvan de oplossing bekend is, maar daar moet wel heel veel voor gebeuren: patchen, op tijd, en overal.

Bron: Tweakers.net