Log4j zero-day krijgt beveiligingsoplossing, net zoals scans voor kwetsbare systemen toenemen

Log4j zero-day krijgt beveiligingsoplossing, net zoals scans voor kwetsbare systemen toenemen

Log4j zero-day krijgt beveiligingsoplossing, net zoals scans voor kwetsbare systemen toenemen

De Apache Software Foundation heeft vandaag een noodbeveiligingsupdate uitgebracht om een zero-day kwetsbaarheid te patchen in Log4j, een Java-bibliotheek die logging-mogelijkheden biedt.

De patch, onderdeel van de 2.15.0-release, verhelpt een kwetsbaarheid voor het uitvoeren van externe code (CVE-2021-44228) die gisteren op Twitter werd bekendgemaakt, compleet met proof-of-concept-code.

De kwetsbaarheid, ook wel Log4Shell genoemd, kan worden misbruikt door op Java gebaseerde apps en servers, waar de Log4j-bibliotheek werd gebruikt, te dwingen een specifieke string in hun interne systemen in te loggen.

Wanneer de app of server de logs verwerkt, kan deze string het kwetsbare systeem dwingen een kwaadaardig script te downloaden en uit te voeren vanuit een door een aanvaller gecontroleerd domein, waardoor de kwetsbare applicatie/server effectief wordt overgenomen, volgens een technische storing die gisteren is gepubliceerd door beveiligingsbedrijf LunaSec.

Met een score van 10/10 op de CVSSv3-ernstschaal, is Log4Shell zo slecht als het kan in termen van beveiligingsfouten, omdat het zowel op afstand kan worden misbruikt als weinig technische vaardigheden vereist om uit te voeren.

Enorme impact
Ontdekt tijdens een bug bounty-actie tegen Minecraft-servers, is de kwetsbaarheid veel groter dan sommigen zouden verwachten, voornamelijk vanwege de bijna alomtegenwoordige aanwezigheid van Log4j in bijna alle grote op Java gebaseerde zakelijke apps en servers.

Log4j wordt bijvoorbeeld meegeleverd met bijna alle enterprise-producten die zijn uitgebracht door de Apache Software Foundation, zoals Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo en mogelijk nog veel meer.

Bovendien gebruiken andere open-sourceprojecten zoals Redis, ElasticSearch, Elastic Logstash, de Ghidra van de NSA en anderen het ook in een of andere hoedanigheid.

Natuurlijk zijn alle bedrijven die een van deze producten gebruiken ook indirect kwetsbaar voor de Log4Shell-exploitatie, zelfs als sommigen zich hiervan bewust zijn of niet.

Volgens een gisteren gepubliceerd onderzoek zijn bedrijven met servers waarvan is bevestigd dat ze kwetsbaar zijn voor Log4Shell-aanvallen, zoals Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase en mogelijk nog duizenden meer.

Aanvallen kunnen worden geblokkeerd met een configuratiewijziging
Volgens p0rz9, de Chinese beveiligingsonderzoeker die de exploitcode voor het eerst online plaatste, kan CVE-2021-44228 alleen worden misbruikt als de optie log4j2.formatMsgNoLookups in de bibliotheekconfiguratie is ingesteld op false.

In een gesprek vandaag vertelde Heige, de oprichter en CEO van het Chinese beveiligingsbedrijf KnownSec 404 Team en een van de eerste onderzoekers die de impact van de kwetsbaarheid begrepen, aan The Record dat de Log4j 2.15.0-release van vandaag deze optie in feite op true zet om te blokkeren aanvallen.

Log4j-gebruikers die updaten naar versie 2.15.0 maar deze vlag vervolgens weer op false zetten, blijven kwetsbaar voor aanvallen. Evenzo kunnen Log4j-gebruikers die niet kunnen updaten maar de vlag op true zetten, aanvallen zelfs op oudere versies blokkeren.

Helaas is deze optie standaard ingesteld op false in oude releases, wat betekent dat alle eerdere Log4j-releases sinds 2.10.0, toen deze optie werd toegevoegd, standaard kwetsbaar zijn.

Volgens rapporten van beveiligingsbedrijven Bad Packets en Greynoise scannen meerdere dreigingsactoren al naar apps die mogelijk kwetsbaar zijn voor de Log4Shell-aanval, wat betekent dat servereigenaren hoogstwaarschijnlijk een heel klein patchvenster tot hun beschikking hebben voordat servers aangevallen worden via het achterdeurtje, als dat in iedergeval nog niet het geval is.