De diverse kwetsbaarheden in de Log4J-software zijn inmiddels ruim twee maanden bekend. Onderzoekers van Barracuda hebben de aanvallen en payloads geanalyseerd die sinds 10 december 2021 door onze systemen zijn gedetecteerd. Daarbij kwamen ze tot de ontdekking dat het aantal aanvallen dat probeert misbruik te maken van deze kwetsbaarheden in deze periode relatief constant is gebleven, met slechts enkele pieken en dalen. Gezien de populariteit van deze software, de mogelijkheden om misbruik te maken van de kwetsbaarheid en de potentiële resultaat van een succesvolle aanval, is de verwachting dat dit patroon zich zal voortzetten, althans op de korte termijn.
Ook vanuit Nederland aanvallen op log4shell-kwetsbaarheden
Hoewel het aantal aanvallen op de kwetsbaarheden in log4shell stabiel blijft, is het interessant om te zien waar de aanvallen tot nu toe vandaan komen. De meeste aanvallen zijn afkomstig van IP-adressen in de VS, waarbij de helft van die IP-adressen geassocieerd was met AWS, Azure en andere datacenters. Maar er vonden ook aanvallen ook plaats vanuit Nederland, Duitsland, Japan en Rusland. Via deze IP-adressen zijn vooral scans en pogingen tot inbraak uitgevoerd. De daadwerkelijke payloads werden veelal geleverd via andere gecompromitteerde websites of VPS-hosts, als de aanval succesvol was. Deze IP-adressen die de payloads hadden, werden meestal verborgen met behulp van de Base64-codering, zoals hieronder beschreven
Één van de dreigingen
Log4j is een op Java gebaseerd logging-auditframework voor Apache. Apache JNDI-functies in log4j-versies ouder dan Log4j 2.14.1 die worden gebruikt voor configuratie, logberichten en parameters, bieden geen bescherming tegen LDAP- en andere JNDI-gerelateerde eindpoints waar een aanvaller de controle over heeft.
Dit betekent dat een aanvaller die logberichten of logberichtparameters kan beheren, willekeurige code kan uitvoeren die is gedownload vanaf LDAP-servers, wanneer de mogelijkheid is ingeschakeld om zoekopdrachten te vervangen. De kwetsbaarheid treft de standaardconfiguraties van verschillende Apache-frameworks, waaronder Apache Struts2, Apache Solr, Apache Druid en Apache Flink, die worden gebruikt door tal van organisaties, zoals Apple, Amazon, Cloudflare, Twitter, Steam en anderen.
Het beveiligingslek wordt geactiveerd door een specifieke characterstring naar de Log4j-software te sturen. Dit betekent dat dit lek eenvoudig te misbruiken is, terwijl het feit dat deze software zo breed wordt gebruikt ook betekent dat er veel mogelijke aanvalskanalen zijn.
Details
Hier zijn enkele voorbeelden van de payloads die de afgelopen maanden misbruik probeerden te maken van deze kwetsbaarheden.
De eerste is een relatief onschuldige (maar wel erg irritante) payload:
Dit leidt naar de volgende Java-payload:
Hiermee wordt een YouTube-video van Rick Astley’s jaren 80-hit ‘Never Gonna Give You Up’ afgespeeld. Deze payload is dus vrij onschuldig, maar wel zo vervelend dat je snel gaat patchen!
Payloads voor cryptomining
Het tweede voorbeeld zagen we vooral kort nadat deze kwetsbaarheden aan het licht kwamen: een payload van een Monero-miner. Deze was afkomstig van verschillende IP-adressen, waarbij de commando’s meestal waren versleuteld in base64:
Het decoderen van deze base64-string leverde het volgende op:
De daadwerkelijke payload van deze URL was dit script dat de miner configureerde:
Doelwit: VMware-installaties
Na verloop van tijd verschenen er berichten dat de beruchte Conti ransomware-bende met behulp van de Log4Shell-kwetsbaarheden probeerde om VMware-installaties te compromitteren. Tot dan toe werden er niet veel externe ransomware-aanvallen op VMware-installaties waargenomen en de verwachting was dit meer een insider-dreiging zou zijn. Bij het doorzoeken van logboeken zagen de onderzoekers echter andere pogingen om deze installaties te infecteren. Bijvoorbeeld:
Wanneer dit werd gedecodeerd, was dit het resultaat:
Deze payload is inmiddels verwijderd, maar URLhaus identificeert dit als een variant van de Mirai DDoS-botnet-malware. Een andere versie van deze schadelijke download is nog steeds actief en wordt op dezelfde manier geïnjecteerd in VMware-installaties.
DDoS-malware
Het laatste voorbeeld betreft een vorm van DDoS-malware:
Dit is het resultaat na decodering:
Hier gaat het om een variant van de BillGates-malware. Deze malware, die rond 2016 verscheen, was oorspronkelijk gericht op Linux-systemen. Dit voorbeeld is inmiddels al een enige tijd offline.
Afgezien van deze payloads, zagen de onderzoekers nog tal van andere pogingen. In de onderzochte logs bevonden zich Kinsing, XMRig en varianten van Mirai en Mushtik, afgaande op analyse van met base64 versleutelde commando’s die waren ingebed in de JNDI-connection strings. Daarbij werd ervan uitgegaan dat de LDAP-servers waarmee verbinding werd gemaakt, schadelijke payloads terugstuurden, waarna de base64-gecodeerde commando’s werden uitgevoerd. De meest voorkomende payload was Mirai in verschillende vormen en uit verschillende bronnen. Het feit dat er vooral veel DDoS botnet-malware wordt verspreid via de log4shell-kwetsbaarheden kan erop wijzen dat er wordt gebouwd aan een groot botnet voor toekomstig gebruik. We zouden in de nabije toekomst dan ook grootschalige DDoS-aanvallen moeten verwachten.
Wat kunnen organisaties doen om zich te beschermen?
De beste manier voor organisaties om zich te wapenen tegen misbruik van log4shell-kwetsbaarheden, is door te upgraden naar de nieuwste versie van log4j. Door software en libraries up-to-date te houden worden kwetsbaarheden tijdig gepatcht.
Vanwege het groeiende aantal kwetsbaarheden in webapplicaties, wordt het voor organisaties steeds moeilijker om zich te beschermen tegen aanvallen. Gelukkig zijn er nu complete oplossingen beschikbaar om webapplicaties te beschermen tegen dit soort dreigingen, zoals Web Application Firewall (WAF/WAF-as-a-Service) -oplossingen, ook wel bekend als Web Application and API Protection (WAAP)-services.
Stefan van der Wal is CSE Application Security bij Barracuda Benelux
