Het internet wordt door elkaar geschud door een bug in Log4j. Het lek kreeg de naam Log4Shell en treft duizenden bedrijven wereldwijd. Wat is er precies aan de hand?
Kom jij als beheerder of ontwikkelaar in aanraking met een Java-gebaseerd systeem dat op Log4j vertrouwt om logs bij te houden? Dan moeten we je de ernst van de Log4Shell-bug vermoedelijk niet meer uitleggen. Wie geen Java-diploma op zak heeft, krabt zich misschien wel in het haar. Wat gebeurt er precies?
Wat is Log4j?
We beginnen bij het begin. Log4j is een opensource tool die momenteel ontwikkeld wordt door de Apache Software Foundation. De tool is een framework dat ontwikkelaars kunnen gebruiken om logs te genereren voor toepassingen gebouwd op Java. Logs zijn een essentieel onderdeel van ieder platform, iedere dienst of oplossing. Ze houden bij wat er precies gebeurt: welke acties voert een toepassing uit, wie meldt zich wanneer aan, welke processen genereren foutmeldingen…
Log4j gaat al 20 jaar mee. De logtool maakt standaard deel uit van populaire Java-frameworks zoals Apache Struts, Apache Druid en Apache Flink. Java is één van de populairste programmeertalen ter wereld. Ontwikkelaars die toepassingen bouwen met Java, grijpen al snel naar Log4j om de logfunctionaliteit te integreren. Ook heel wat commerciële software zoals die van VMware gebruikt Log4j.
SQL-injectie voor Java
Log4j is dus best alomtegenwoordig. Een kwetsbaarheid die de tool treft, heeft het potentieel duizenden oplossingen en diensten wereldwijd te beïnvloeden. Dat is precies wat er gaande is met Log4Shell. De kwetsbaarheid wordt veroorzaakt door een bug onder de categorie inproper input validation. Dat impliceert dat de Log4j in sommige gevallen te losjes omspringt met input die van buitenaf komt.
Als logtool moet Log4j bijhouden wat er allemaal gebeurt wanneer een gebruiker via het internet bij een toepassing komt aankloppen. Die gebruiker kan op verschillende manieren input naar een toepassing zenden, bijvoorbeeld via een aanmeldformulier of rechtstreeks via de browser. Normaal wordt dergelijke input netjes opgeschoond. Een veld dat om een gebruikersnaam vraagt, zal er op de achtergrond voor zorgen dat de input puur als tekst wordt behandeld. Af en toe loopt er daar iets mis.
Zodra de crimineel een dienst kan benaderen die input van buitenaf vastlegt in een logbestand met Log4j, kan hij of zij code laten uitvoeren.
In het geval van de Log4Shell-bug wordt de input niet opgeschoond. Daar kunnen hackers gebruik van maken door malafide code te injecteren. Door een programmeerfout wordt die code niet omgezet naar tekst, maar voert Log4j ze uit. Wanneer een hacker Log4Shell op de juiste manier misbruikt, kan hij Log4j naar zijn pijpen laten dansen. Concreet is het daarom mogelijk om Log4j op te dragen om eigen malafide code uit te voeren of zelfs verbinding te maken met een externe server, om van daaruit malware binnen te halen. De aanpak doet een beetje denken aan een SQL-injectie.
Kritiek
Een aanvaller heeft hiervoor geen extra hulp nodig. Zodra de crimineel een dienst kan benaderen die input van buitenaf vastlegt in een logbestand met Log4j, kan hij of zij code laten uitvoeren. Het zero day-lek krijgt zo terecht het label ‘kritiek’ en een gevaarscore van 10 op 10. De aanval in kwestie berust niet op andere kwetsbaarheden, gestolen inloggegevens, een succesvolle phishing-aanval of andere vormen van initiële toegang. Het hack biedt zowel een achterpoortje als een manier om dat achterpoortje ten volle uit te buiten.
Log4Shell is dus een kwetsbaarheid in een enorm populaire tool die onderdeel is van miljoenen toepassingen en diensten van duizenden bedrijven groot en klein, en die hackers vanop iedere laptop met een internetverbinding kunnen uitbuiten. Niemand is immuun. Onder andere iCloud van Apple, diensten van Cloudflare, Amazon, VMware en IBM, Twitter en spelletjesdienst Steam zijn onderhevig aan de bug. Let wel: met bijkomende beveiliging kunnen aanvallen gelukkig nog worden gestopt.
Stevig uitgebuit
Log4Shell is een zero-day, wat impliceert dat het lek tot voor kort onbekend was. Helaas waren hackers er eerder van op de hoogte dan het grote publiek. Cisco Talos zegt een blogpost dat het al sinds zeker 2 december sporen van misbruik ziet.
Tussen vrijdag en maandagochtend zag Check Point meer dan 820.000 pogingen om te scannen naar de kwetsbaarheid.
Intussen is het hek van de dam. Check Point liet al aan de redactie weten dat het meer dan 60 nieuwe varianten van exploits detecteerde in minder dan 24 uur tijd. Tussen vrijdag en maandagochtend zag de beveiligingsspecialist meer dan 820.000 pogingen om te scannen naar de kwetsbaarheid. Bijna de helft van die gedetecteerde scans was afkomstig van gekende kwaadaardige actoren. Ook Sophos detecteerde al honderdduizenden pogingen om vanop afstand code uit te voeren via de kwetsbaarheid.
Niet zomaar patchen
Patchen is een huzarenstukje. Apache introduceerde in allerijl al wel een noodpatch met Log4j versie 2.15.0, maar daarmee is het euvel niet verholpen. Wie zelf het volledige beheer heeft over de Java-oplossing waar het kwetsbare Log4j-component deel van uitmaakt, kan de update wel uitrollen. Heel veel organisaties gebruiken echter software van derden waarin Log4j zit ingebakken. Zij moeten wachten tot hun softwareleveranciers te patch van Apache implementeren en vervolgens zelf uitrollen als update.
VMware werkt bijvoorbeeld naarstig aan patches voor zowat zijn hele portfolio, maar op het moment van dit schrijven zijn de meeste producten nog aangewezen op een tijdelijke workaround.
In de praktijk zal het heel wat tijd en moeite kosten voor de meeste organisaties om het probleem te verhelpen. Log4Shell speelt in dezelfde klasse als andere kritieke lekken zoals EternelBlue, dat uitgebuit werd door WannaCry, of de ShellShock-kwetsbaarheid. Die bugs brachten heel wat schade met zich mee en waren in tegenstelling tot Log4Shell wel oplosbaar via een enkele patch van één softwarebouwer.
Tot slot kan het zomaar dat een organisatie al getroffen is nog voor de uitrol van een patch. Bedrijven moeten in hun logbestanden tot begin september teruggaan om te ontdekken of een crimineel al niet ergens anders een achterpoortje heeft geopend.
Kwetsbaarheid die zal nazinderen
Het is aan klanten en beheerders om de beschikbaarheid van patches in het oog te houden en systemen in tussentijd veilig te houden De praktijk leert dat heel wat ondernemingen wereldwijd daar niet in zullen slagen. Kijk maar naar het notoire Exchange-hack van begin 2021, waarvoor tal van organisaties ondanks het gevaar en de ruchtbaarheid toch laakten om tijdig te patchen.
De Log4Shell-kwetsbaarheid in Log4j zit zeker en vast in de top vijf van meest ernstige kwetsbaarheden van het laatste decennium
Candid Wuest, VP van Cyber Protection Research bij Acronis
“De Log4Shell-kwetsbaarheid in Log4j zit zeker en vast in de top vijf van meest ernstige kwetsbaarheden van het laatste decennium”, zegt Candid Wuest, VP van Cyber Protection Research bij Acronis over de situatie. Etay Maor, Senior Director of Security Strategy bij Cato Networks gaat verder: “Deze kwetsbaarheid werd eerst uitgebuit door low-level aanvallers voor snelle winst, maar er waren ook aanvallen die in lijn liggen met de acties van gesofisticeerde actoren met gevaarlijkere doelen voor ogen dan gewoon wat data stelen.”
“De Log4Shell-kwetsbaarheid vormt een ander soort uitdaging voor IT-teams”, bevestigt Sean Gallagher, Senior Threat Researcher bij Sophos. “Veel softwarekwetsbaarheden zijn beperkt tot een specifiek product of platform. Log4Shell is echter een bibliotheek die door veel producten wordt gebruikt en kan daarom aanwezig zijn in alle uithoeken van de infrastructuur van een organisatie.”
De potentiële impact van Log4shell is immens. De komende dagen en weken zullen uitwijzen hoeveel schade aanvallers ook daadwerkelijk kunnen aanrichten.