Log4j 2-library kwetsbaarheid is een groot probleem

Weakness in the Java-application Log4j 2-libraryFoto: ┬ę MJB Events PR

Log4j 2-library kwetsbaarheid is een groot probleem

Vrijdag 10 december 2021 kwam het nieuws naar buiten. Een kwetsbaarheid dat gevonden was in de Apache Log4j 2-library, waardoor er gebruik gemaakt kan worden van de remote code execution tool. Maar wat betekend dit eigenlijk voor ons als burgers en systeemeigenaren? In dit artikel geef ik daar meer uitleg over.

Wat is het Log4j?

Log4j, de volledige naam Apache Log4j 2-library, heeft een kwetsbaarheid in haar systeem en bibliotheek. Deze bibliotheek kan toegevoegd worden aan een Java-applicatie (of applicaties) waarmee je kunt loggen (logbestanden mee kunt maken). Hierdoor ben je in staat om problemen of fouten op te sporen in applicaties. Deze fouten kan je vervolgens oplossen of verhelpen, waardoor je gebruikers optimaal gebruik kunnen maken van de applicatie.

Doordat deze bibliotheek een kwetsbaarheid heeft, zou een hacker een willekeurige code toe kunnen voegen aan deze bibliotheek door middel van de zogeheten remote code execution tool. Op deze manier kan de hacker op afstand toegang krijgen tot de betreffende applicatieserver, waardoor de schade groot kan worden.

Wie zijn er getroffen?

Eigenlijk iedereen die de Log4j 2-library gebruikt in zijn of haar Java-applicatie(s) is getroffen door deze kwetsbaarheid. Dit betekend niet dat je dan ook meteen getroffen hoeft te zijn, maar de kans op een aanval door een hacker is wel groter doordat er een weg naar binnen aanwezig is.

Deze bibliotheek is onder meer gebruikt in applicaties zoals Steam, Apple iCloud en bijvoorbeeld Minecraft, aldus LunaSec. Dergelijke systemen draaien vaak op Apache-projecten zoals Apache Struts2, Solr, Druid en Flink. Deze projecten zijn daardoor ook (erg) kwetsbaar.

Echter is dit niet de eerste keer dat systemen getroffen worden door een kwetsbaarheid in de Log4j 2-library. In 2017 was er een datalek van het Equifax, waarbij op een dergelijke manier hackers binnen wisten te komen. Deze datalekken moeten, in overeenstemming met de nieuwe wetgeving van de Autoriteit Persoonsgegevens (AP), binnen 72 uur gemeld worden.

Het is volgens Randori niet te zeggen hoe groot de omvang van dit lek zal zijn. Deze bibliotheek is een veel gebruikte tool die door vele bedrijven ingezet worden. Net zoals de eerdere kwetsbaarheden, zoals het Heartbleed en Shellshock zal het nog wel even duren voordat de omvang van de schade bekend is.

Hoe ziet die kwetsbaarheid eruit?

Deze kwetsbaarheid heeft de kenmerk CVE-2021-44228 en Log4Shell gekregen. Naast deze benamingen heeft het Nationaal Cyber Security Centrum ook de kenmerken CVE-2021-45046, CVE-2021-4104 en CVE-2021-45105 toegevoegd aan de Log4Shell kwetsbaarheid.

Met deze kwetsbaarheid kunnen hackers toegang krijgen tot de applicatieservers als er gebruik gemaakt word van de remote code execution. Zoals gezegd is dit vooral van toepassing binnen Java-applicatie(s) op het internet, maar ook in software voor op de Windows en Apple computers. Een complete lijst van getroffen software, tools, detectie en migratie, iocs (Indicators of Compromise), hunting en scanningmogelijkheden kunnen gevonden worden op de NCSC GitHub pagina.

Inmiddels heeft het beveiligingsbedrijf Barracuda een onderzoeksrapport gepubliceerd waarbij het misbruik van deze kwetsbaarheid gebruikt word. Volgens het beveiligingsbedrijf word de kwetsbaarheid vooral gebruikt voor botnet- en cryptominingaanvallen. Hierdoor worden zogeheten Monero-miners geïnstalleerd waardoor een aangevallen systeem zal worden opgenomen in een botnet.

Deze botnet, waaronder de Mirai-botnet, Kinsing-botnet en XMRig-botnet, zullen worden gebruikt om botnetaanvallen uit te voeren. Met andere woorden DDoS-aanvallen, waar ik eerder al een artikel over schreef. Ondanks dat het voor nu mee lijkt te vallen met de getroffen systemen, dringt het beveiligingsbedrijf Barracuda erop aan om extra waakzaam te zijn. Er zijn bij hen gevallen bekend waarbij er serieuze misbruiken hebben plaatsgevonden door cybercriminelen.

Hoe kan je deze kwetsbaarheid dichten?

Om deze kwetsbaarheid te dichten zijn er twee mogelijkheden. De eerste mogelijkheid is om de parameter log4j2.formatMsgNoLookups op true te zetten. Dit gebeurd dan bij het starten van de Java Virtual Machine. Echter kan dit nog steeds onveilig zijn om uit te voeren.

Daarom gaat de voorkeur vooral naar de tweede mogelijkheid. Dit is het updaten van de Apache Log4j 2-library. Deze update je dan naar Apache Log4j 2 versie 2.17.2 of nieuwer (raadpleeg de website van Log4j voor de laatste versie). Hiermee is de kwetsbaarheid gedicht en kan er door dit kwetsbaarheid geen gebruik meer worden gemaakt van buitenstaanders die via de remote code execution binnen kunnen komen.

Ondanks deze twee mogelijkheden is het advies om de applicatieserver nog enige tijd goed te monitoren en te observeren. Het kan namelijk zijn dat hackers al toegang hebben gekregen tot de applicatieserver. Op deze manier zouden zij kwaadwillende software kunnen installeren die voor de gebruikers schadelijk zijn. Ook zou de mogelijkheid op datalekken groot zijn, zeker wanneer je digitaal klantdata verwerkt.

Het NCSC heeft een lijst gepubliceerd van applicaties die kwetsbaar zijn door de kwetsbaarheid in de Log4j bibliotheek. Daarnaast kan je ook de handleiding voor de te nemen stappen raadplegen die de NCSC heeft gepubliceerd op haar website.

Conclusie

Ondanks dat het misschien erna uit ziet dat het misbruik van de Apache Log4j 2-libary oogwaarschijnlijk mee lijkt te vallen, moeten we deze dreiging en kwetsbaarheid met grote serieuze professionaliteit benaderen. Het is daarom niks voor niks dat het NCSC de hoogste beveiliging issue prioriteit (10/10) geeft aan deze kwetsbaarheid. Bedrijven, groot of klein, zouden daarom deze kwetsbaarheid zo snel mogelijk moeten updaten naar de laatste versie en de systemen goed blijven observeren en monitoren. Want uiteindelijk hebben we het hier wel over vele (mogelijke) slachtoffers van deze kwetsbaarheid. Het is daarom dan ook beter voorkomen dan genezen, zeker wanneer je bedrijf (en systeem) nog geen slachtoffer is geworden van deze kwetsbaarheid. Want ieder systeem zou, met een sterke wil van de hacker, slachtoffer kunnen worden.

Bronnen: Dit artikel is geschreven op basis van mijn eigen kennis en ervaring, maar ook met de aanvullende informatie van Lunasec, Randori, NCSC-NL GitHub en Barracuda.