Het grootste probleem is dat het een 0-day exploit is. Oftewel: er is nog geen waterdichte fix beschikbaar. Hoewel enkele uren later een update is geweest, is er nogal wat discussie of dit voldoende is. Want het is een feature in Log4j dat nu standaard uitgezet wordt, maar het blijft wel beschikbaar. Een andere uitdaging is dat het pakketje verweven zit in zeer veel commercial-of-the-shelf (COTS) software. Niet alles is dus zomaar zelf te repareren, maar moet er gewacht worden op de mitigatie instructies van de leverancier.

Is er dan niets tegen te doen? Ja, dat is er gelukkig wel. Ten eerste zijn er (rigoureuze) manieren om applicaties te scannen voor Log4j componenten. Deze applicaties deactiveren is een eerste maatregel. Daarna moet er per applicatie onderzocht worden wat het efficiëntste is. Dit kan bijvoorbeeld zijn: Log4j bijwerken naar de laatste versie, logging statements aanpassen zodat niet alles klakkeloos gelogd wordt, maar bijvoorbeeld eerst door een degelijke ‘sanitizer’ gaat. Ook een Log4j afgeleide pakket maken waar deze specifieke functionaliteit gewoonweg niet in zit, behoort tot de mogelijkheden. Tenslotte wordt ook als advies genoemd, om alle software op te schonen van deze specifieke functionaliteit door het component te verwijderen. Iets wat misschien tijdelijk kan werken, maar binnen no-time weer terug is als de applicatie opnieuw uitgerold wordt.

Er zijn ook maatregelen te bedenken op infrastructureel niveau. Leveranciers van Web Application Firewalls werken rond de klok om patronen te herkennen zodat de ‘payload’ al vroegtijdig afgevangen wordt. Dit blijft echter een kat en muis spel. Andere opties zijn om netwerkverkeer te blokkeren voor de zogeheten ‘lookups’ – de specifieke functionaliteit die Log4j gebruikt, en die een aanvaller in staat stelt een kwaadaardig stuk software in te laden vanuit een externe locatie. Dit kan uitdagend zijn in moderne applicatielandschappen waar er een veelvoud aan instanties van services draaien die Log4j gebruiken.

Onder de streep blijft staan: kwetsbaarheden in applicaties zullen alleen maar toenemen. Er is een toename te zien van 72% tussen 2019 en 2020, van cyber incidenten die te wijten zijn aan kwetsbare applicaties. Zit het niet in de eigen code, dan wel in de vele afhankelijkheden waaruit een applicatie bestaat. Het aanpakken van deze kwetsbaarheden lukt niet altijd met de modernste firewalls of intrusion detection systems – al bieden die zeker wel bescherming, iedere applicatie heeft een eigen unieke patroon van berichten en het kost tijd voor ‘self-learning’ en op AI gebaseerde appliances om succesvol aanvalspaden te mitigeren.

Dus wat is het meest effectief voor dit soort aanvallen? De applicatie zelf solide genoeg maken. Niet voor niets ‘injection’ uitgeroepen tot meest voorkomende kwetsbaarheid. Applicaties kunnen zich er tegen wapenen door ‘input validatie’ te bouwen volgens het principe: ‘never trust, always verify’. Maar ook waar random input verwacht kan worden, zoals chatberichten etc., is het noodzaak deze input te ontsmetten en een degelijke ‘encoding en escaping’ uit te voeren zodat schadelijke payloads onschadelijk gemaakt worden.

Tenslotte is het, zoals waar het in het artikel van Thomas om gaat, raadzaam om een CI-pipeline in te richten die volledig geautomatiseerd code changes, en patches van bouwstenen die ontwikkelaars zo omarmen, met lichtsnelheid kunnen doorvoeren naar productie toe. De combinatie van robuuste applicaties, bereikt door doorlopende security activiteiten in het bouwproces, én het supersnel kunnen herstellen als er toch een kwetsbaarheid gevonden wordt, zijn beveiligingsmaatregelen die organisaties moeten gaan nemen om veilige applicaties blijvend aan te kunnen bieden aan hun eindklanten.