Hoe (alweer) een beveiligingslek te duiden.

Afgelopen dagen is er weer groot nieuws in cybersecurityland. De populaire en veelgebruikte software Apache Log4j bevat een kritieke kwetsbaarheid die remote code execution mogelijk maakt. Deze zero day, aangeduid als CVE-2021-44228 of Log4Shell, heeft een CVSS score van 10 gekregen. Er is inmiddels al exploitcode online te vinden.
Oef, dat zijn een hoop vaktermen in een paar zinnen. Tijd voor een introductie- of opfriscursus in de wereld van de cybersecurity berichtgeving. In deze blog zullen we de recent ontdekte kwetsbaarheid als voorbeeld nemen om een aantal van deze termen te duiden.

Wie of wat is er nou precies kwetsbaar?

Welke systemen getroffen kunnen worden door een bepaalde kwetsbaarheid, hangt sterk af van de software die de kwetsbaarheid bevat. In dit geval gaat het om Apache Log4j, een populair logging framework dat veelvuldig door softwareontwikkelaars wordt gebruikt voor het wegschrijven van logbestanden. En dat is slecht nieuws, want dit betekent dat je van elk gebruikt systeem kunt gaan controleren of Log4j gebruikt wordt. De fabrikant kan dit het snelst bevestigen, maar dan is het nog steeds een hele klus.
Log4j is in dit geval software die beschikbaar is voor op Java gebaseerde applicaties. Dat sluit in ieder geval een groot deel van de applicaties ook uit. Echter, Java zelf wordt ontzettend veel gebruikt, met name in vele enterprise applicaties. Denk daarbij aan Jira van Atlassian of VMWare VCenter server.
Ook andere (web-)applicaties gaan wellicht niet geheel vrijuit. Zo wordt bijvoorbeeld voor het aanbieden van op PHP gebaseerde software ook vaak andere software gebruikt, zoals een webserver. Is deze in Java geschreven? Dan bestaat de kans nog steeds dat het gebruikte product kwetsbaar is.

Hoe worden die kwetsbaarheden gevonden?

Er is veel geld te verdienen met cybercrime. Er zijn allerlei mensen continu op zoek naar kwetsbaarheden in bestaande software. Sommigen doen dit in de rol van beveiligingsonderzoeker, of ethische hacker en waarschuwen fabrikanten voor de gevonden kwetsbaarheden, soms in ruil voor een beloning. Anderen hebben minder goede bedoelingen en zoeken naar manieren om cyberaanvallen uit te voeren om deze methoden vervolgens zelf te gebruiken, of door te verkopen aan andere criminelen. Tot slot zijn ook natiestaten vaak op zoek naar kwetsbaarheden, bijvoorbeeld om rivalen te kunnen bespioneren.

Wanneer zo’n kwetsbaarheid voor de eerste keer gevonden is, spreekt men van een zero-day, of 0-day. Een term die het aantal dagen aanduidt dat een fabrikant heeft gehad om de kwetsbaarheid op te lossen. Als een ethische hacker een (zero-day) kwetsbaarheid vindt, brengt hij vaak de fabrikant op de hoogte. Deze probeert dan een aanpassing aan de software door te voeren, die de kwetsbaarheid oplost, een zogenaamde patch. De kwetsbaarheid wordt openbaar gemaakt nadat de patch beschikbaar is. Soms reageren fabrikanten echter niet, of duurt het uitbrengen van een patch erg lang. In zo’n geval wordt de kwetsbaarheid nog wel eens bekend gemaakt voordat er een oplossing is. Dat klinkt niet heel erg ethisch, maar wordt bijvoorbeeld gedaan als er een vermoeden is dat de kwetsbaarheid al actief wordt misbruikt.

Wat kan een aanvaller dan met zo’n zero-day Remote Code Execution?

Kritieke kwetsbaarheden bevatten vaak een vorm van remote code execution (RCE). Dit stelt een aanvaller in staat om van afstand ‘code’ uit te voeren op het systeem dat wordt aangevallen. Normaal installeer je als gebruiker software die je wilt gaan gebruiken. Download je ‘per ongeluk’ software met kwaadaardige code, dan moet je die vaak eerst nog uitvoeren, in Windows bijvoorbeeld door dubbel te klikken op een .exe-bestand.
Het zou erg onveilig zijn als willekeurige buitenstaanders dit voor je kunnen doen, zonder dat jij het doorhebt. En dat is precies wat er met RCE gebeurt. De aanvaller is niet ingelogd op jouw computer, maar is toch in staat om een dergelijk ‘.exe-bestand’ (of een variant daarop) uit te voeren op jouw pc, of op een server die met het internet is verbonden.

Wat is het gevolg van RCE?

Dat kan van alles zijn. De aanvaller kan een cryptolocker binnen het netwerk brengen om een ransomwareaanval uit te voeren. Of een programmaatje installeren om op afstand mee te kijken wat er zoal op het systeem gebeurt. Zo kan er perfect gespioneerd worden zonder dat dit opvalt.
Bij een website of cloud-applicatie kan de aanvaller ervoor kiezen om iedere bezoeker een aangepaste website voor te schotelen, of bijvoorbeeld de downloads die via de website beschikbaar zijn te besmetten met malware. In zo’n laatste geval kan een vertrouwde applicatie misbruikt worden om heel veel nietsvermoedende gebruikers slachtoffer te laten worden.

Hoe erg zo’n kwetsbaarheid nu precies is wordt aangegeven met een zogenaamde CVSS score, wat staat voor Common Vulnerability Scoring System. Een 1 is de laagste score, een 10 de hoogste.
Wat de impact op jouw eigen IT omgeving kan zijn, hangt sterk af van het systeem waarin de kwetsbaarheid wordt ontdekt en of deze systemen onderdeel zijn van de IT infrastructuur. Wordt het systeem uberhaupt gebruikt, en zo ja, hoe makkelijk kan een aanvaller deze op afstand bereiken? Bij hoge scores, moet je dit echter altijd zo snel mogelijk nagaan.

Een manier om dit te doen is door alle gebruikte software na te lopen, waarbij de versienummers vaak dienen te worden gecontroleerd. Een up-to-date inventaris kan hier enorm bij helpen.
Een andere methode, is om de exploit uit te proberen. Voor Log4Shell zijn bijvoorbeeld een aantal scripts vrijgegeven die een aanval simuleren, waarbij je direct ziet of je systeem kwetsbaar is. Garanties geeft deze aanpak echter niet, omdat de kwetsbaarheid op vele manier uit te buiten is, afhankelijk van de getroffen applicatie. StackSecure heeft een van deze scripts in een meer gebruiksvriendelijke vorm gegoten en maakt deze Log4j Checker gratis beschikbaar.

Hoe nu verder?

Zolang het niet duidelijk is of je systeem kwetsbaar is of bevestigd is dat een systeem de kwetsbaarheid bevat, is het aan te raden deze uit te schakelen of (deels) off-line te halen totdat er een patch beschikbaar komt. Dit kan een kwestie van dagen zijn, maar soms duurt het veel langer. Je bent afhankelijk van de leverancier. Soms zijn er ook workarounds beschikbaar. De configuratie van een applicatie kan dan zodanig worden aangepast dat de kwetsbaarheid niet meer te misbruiken is. Heb je de kwetsbaarheid opgelost? Dan is het nog steeds aan te raden om je hele systeem te (laten) controleren.
Het is namelijk niet te zeggen wie er al voor de bekendmaking op de hoogte was van de kwetsbaarheid, en of deze actief is misbruikt. Volgens Cisco werd de kwetsbaarheid in Log4j al op 2 december misbruikt. Cloudflare rept over 1 december.
Dit kan door het zoeken naar zogenaamde indicators of compromise, vaak malafide scripts en bestanden die door aanvallers worden achtergelaten, of bijvoorbeeld gegevens in bepaalde logbestanden.
Is het onderzoek afgerond en ben je de dans ontsprongen? Dan is het wachten op de volgende grote kwetsbaarheid die aan het licht komt...