Log4J zwakheid met score 10/10

En neen, in deze context is 10/10 geen goede score! Het is de meest slechte en gevaarlijke score die gegeven kan worden aan een zwakheid.

Wat is Log4J

Log4J is een essentiële component die gebruikt wordt in heel wat Java gebaseerde toepassingen. Op zich zegt deze component u niet veel, maar indien u een Java toepassing draait, is er een grote kans dat deze component eveneens bij u in uw bedrijfswebserver of applicatie geïnstalleerd staat.

Recentelijk is er een zwakheid uitgekomen die een volledige Remote Code Execution (RCE) kan triggeren.

Wat is een RCE?

RCE is de mogelijkheid om een zwakheid uit te buiten waardoor de hacker in staat is om code uit te voeren op jouw server.

Dit is zowat het ergste wat een bedrijf kan overkomen, want dan kan de aanvaller geljik wat uitvoeren op uw server, inclusief het lezen van de informatie die door deze server toegankelijk is.

Een voorbeeld van exploitatie kan zijn dat alle informatie zoals bestellingen, contactgegveens, betalingen, … van uw webshop gestolen kunnen worden!

Een ander geval wat vaak voorkomt, is dat door het uitbuiten van een dergelijke zwakheid, ze toegang krijgen tot uw bedrijfsnetwerk en dan alle informatie en systemen gaan versleutelen.

Wat kunt u hiertegen doen?

In de meeste gevallen indien er een zwakheid gevonden en vaak gepubliceerd wordt, is het aan de leverancier om hiervoor een patch uit te brengen.

Het is dan natuurlijk de bedoeling om:

1. Uitzoeken of uw systemen onderhevig zijn aan de zwakheid.
2. De patch zo snel mogelijk te valideren in een testomgeving, dat met de patch de toepassing blijft draaien.
3. De patch uitrollen in productie om de exploitatie van de zwakheid te voorkomen.

Dit zijn in feite de basisstappen van patch management.

Wie dient deze uit te voeren?

Elke verantwoordelijke voor het goed beheer van de componenten van uw systemen, vaak de persoon of instantie die de systemen onderhoud, is verantwoordelijk om een gedegen patch management op te stellen.

Indien u een externe leverancier of consultent hiervoor gebruikt, zorg er dan voor dat de verwachte interventie tijden alsook patch tijden contractueel vastgelegd worden. Op deze manier dgeeft u als verantwoordelijke een duidelijker beeld van de verwachtingen dat u hebt van jouw leverancier.

Historiek LOG4Jv2

• December 13/12/2021: versie 2.16.0 is uit, deze verhelpt een Remote Code Execution zwakheid
• December 17/12/2021: versie 2.17.0 is uit, deze verhelpt een Denial Of Service zwakheid
• December 28/12/2021: versie 2.17.1 is uit, deze verhelpt een Remote Code Execution zwakheid

Oef, ik draai nog LOG4Jv1, ik ben niet vatbaar voor deze zwakheden!

FOUT! u bent vatbaar aan een nog veel ruimer arsenaal aan zwakheden. De v1 is ook al jarenlang niet meer gesuporteerd. Gelieve uw verantwoordelijke zo spoedig mogelijk te informeren en instrueren dat hij moet upgraden naar de laatste gesupporteerde versie!

Stelt u vast dat dergelijke oude software op uw systemen draait, dan kunt u ervan op aangaan dat de patching van uw verantwoordelijke voor veel verbetering vatbaar is!

GDPR

Dergelijke zwakheden vormen eveneens een ernstig GDPR-risico.

Met dergelijke zwakheden in uw systemen, kan een aanvaller of hacker toegang krijgen tot de systemen. Dit betekent dat de confidentialiteit (bv. een datalek), integriteit (bv. het stelen van geld) of de beschikbaarheid (bv. versleutelen van de systemen) in het gedrang kan komen.

In het geval van een datalek is er sowieso sprake van een GDPR incident, en waarschijnlijk ook van een inbreuk die gemeld dient te worden aan de GegevensBeschermingsAutoriteit (GBA).

Hebt u zo een incident voor, gebruik dan de inbreukprocedure van Co-Dex.eu om te bepalen of deze ernstig genoeg is om gemeld te dienen te worden aan de GBA.