Log4j: hoe staat het er nu voor?

Dit soort kwetsbaarheden in zo'n veelgebruikte library mogen niet worden onderschat: met miljoenen kwetsbare apparaten zullen de aanvallen waarschijnlijk doorgaan zolang dergelijke apparaten met ongepatchte software kunnen worden gevonden door kwaadwillenden.

In dit bericht zetten we alle activiteit rond Log4Shell-exploits op een rijtje om te onderstrepen hoe belangrijk het is om getroffen systemen tijdig te ontdekken en te patchen.

Initiële impact van Log4j: criminelen en onderzoekers zijn beide alert

Zoals hier in meer detail wordt beschreven, zijn er twee nieuwe kenmerken van een Log4j-aanval:

1. De aanvalsstring kan worden geïnjecteerd in elke gebruikersinput die wordt gelogd, zoals een http-header, een gebruikersnaam of een bestandsnaam.
2. De server waarmee de aanvaller communiceert en de server die wordt aangevallen kunnen totaal verschillend zijn en zich zelfs binnen verschillende netwerken bevinden. In dit geval kunnen interne loggingservers die zich binnen vertrouwde netwerken bevinden plotseling communiceren met aanvallers op het internet.

Deze kenmerken zorgen voor een eenvoudige en krachtige tool . Aanvallers hadden minder dan 24 uur na de bekendmaking van de CVE nodig om meer dan 60 permutations van de aanvalsstring te genereren. Binnen enkele uren na de openbaarmaking ontstond er discussie over dit issue binnen bekende ondergrondse Russische misdaadfora. Onderzoekers in de Chinese hackersgemeenschap beweerden ook bewijzen te hebben gezien van snel geautomatiseerde exploit-tools Log4j_RCE_Tool, ReverseShell PoC's en een toenemend aantal artikelen over de uitbuiting van extra JNDI-kwetsbaarheden in IBM WebLogic-servers. Ondertussen ontdekten onderzoekers dat hun Log4j-honeypots binnen 24 uur na de eerste onthulling alarmerend snel oplichtten.

December 2021: Log4Shell-aanvallen ‘in-the-wild’
De eerste golf van aanvallen met de Log4Shell-exploit bestond uit relatief eenvoudige actoren die verschillende cryptominers dropten bij slachtoffers. De meest gedurfde was een 8 dagen durende hack van HP-servers die werd gebruikt om ongeveer 3,4 miljoen Raptoreum-munten te minen, met een geschatte waarde van $ 110.000. Men denkt dat de aanvallers in staat waren om ongeveer de helft van de geminede munten te gelde te maken voordat de operatie werd stilgelegd.

Mineraanvallen werden snel gevolgd door een aantal nieuwe ransomware-families die Log4j als een middel voor initiële toegang gebruiken, zoals Khonsari ransomware. Aanvallers gebruikten Log4j om een kwaadaardige Java class file te downloaden en te lanceren, die vervolgens de Khonsari ransomware payload inzamelde van een C2.

Andere ransomware-varianten volgden al snel, waaronder TellYouThePass die enigszins sluimerde voor de onthulling van het Log4j-kwetsbaarheid. TellYouThePass bestaat uit zowel Windows- als Linux-varianten, waardoor de meeste servers met een kwetsbaarheid voor Log4j-exploits binnen aanvalsbereik liggen.

Conti valt Log4j-kwetsbare apparaten aan die niet zijn blootgesteld aan het publieke internet
Binnen enkele dagen nadat de fout bekend werd gemaakt, werden er naar verluidt Conti ransomware-campagnes waargenomen die de kwetsbaarheid benutten, waarvan meerdere campagnes gericht waren op hoogwaardige vCenter-omgevingen. Deze ontwikkeling is opmerkelijk omdat de doelmachines niet noodzakelijkerwijs aan het publieke internet waren blootgesteld. In plaats daarvan werd Log4j gebruikt om kwetsbare vCenter-servers binnen het netwerk te compromitteren en te versleutelen.

Uiteraard heeft de crew achter Emotet ook van Log4j geprofiteerd. Kwetsbare servers werden bijvoorbeeld snel gecompromitteerd en gebruikt voor staging en payload hosting binnen het grotere Emotet-netwerk. Hoewel we verwachten dat Emotet Log4j zal omarmen, hebben we dit nog niet waargenomen. Wel zien we dat Log4j momenteel gebruikt wordt om Cobalt Strike Beacons te leveren, die daarna gevolgd kunnen worden door een willekeurig aantal payloads.

Medio december werd de Vietnamese cryptobeurs ONUS aangevallen via uitbuiting van Log4j. De aanval vond waarschijnlijk plaats binnen twee tot drie dagen na de eerste bekendmaking van Log4j. Het bedrijf patchte de kwetsbare servers ergens na 13 december, toen het bedrijf al was aangevallen. De aanvallers probeerden het bedrijf later 5 miljoen dollar af te persen. Voor dat bedrag boden de aanvallers aan om een cache met gestolen gegevens, waaronder PII, niet te lekken. Nadat het fintechbedrijf weigerde te betalen, probeerden de aanvallers de gegevens op 25 december te verkopen op een bekend hackingforum.

Ransomware-operators en afpersers zijn niet de enigen die meedoen aan de actie. De actoren achter Dridex hebben ook handig gebruik gemaakt van deze exploit voor hun eigen listige doeleinden. Van midden tot eind december zagen we een massale verspreiding van Dridex via Log4j. In de meeste gevallen werd de exploit gebruikt om een kwaadaardige Java class te laden, gevolgd door een VBScript bevattend .HTA-bestand. Vanaf dat moment zien we een toename van varianten die op DLL zijn gebaseerd.

20 januari: Toezichthouders en CISA voeren de druk op om Log4j te beschermen
Op 4 januari heeft de Federal Trade Commission (FTC) de druk op bedrijven nog verder opgevoerd om ervoor te zorgen dat de nodige stappen worden ondernomen om assets met kwetsbare Log4j-libraries te beschermen.

De FTC merkte op dat Log4j “een ernstig risico vormt voor miljoenen consumentenproducten” en dat de kwetsbaarheid op grote schaal wordt misbruikt door een groeiende groep kwaadwillenden, en zei op 4 januari dat zij haar “volledige wettelijke bevoegdheid” zal “aanwenden om bedrijven te vervolgen die het nalaten om stappen te ondernemen om consumentengegevens te beschermen tegen blootstelling als gevolg van Log4j”.

Ondertussen merkte CISA op 6 januari 2022 op dat, op basis van inzendingen bij het agentschap, er ten minste 2800 verschillende producten zijn die Log4j bevatten. Het agentschap schat dat, ondanks de vastberadenheid van veel beheerders en beveiligingsteams in december 2021, er waarschijnlijk nog steeds “honderden miljoenen” individuele apparaten zijn die door de Log4j-kwetsbaarheden zijn getroffen.

Wat komt er na Log4j?
Log4j zou slechts het begin kunnen zijn van een hele nieuwe klasse van bugs. Het blijkt dat de JNDI API zeer aantrekkelijk is als middel voor misbruik, omdat het eenvoudige ongeauthenticeerde remote code execution mogelijk maakt. Een nieuw JNDI-gebaseerd ‘Log4j-achtig’ kritisch lek werd onthuld op 7 januari 2022. Deze RCE-fout, opgespoord als CVE-2021-42392, werd ontdekt in H2 databaseconsoles, een open-source databasemanagementsysteem geschreven in Java. Hoewel deze kwetsbaarheid lang niet zo wijdverspreid is als de Log4j-kwetsbaarheid, wordt geschat dat ze bijna 7.000 onderdelen treft, waaronder populaire frameworks als JHipster, Play framework en Spring Boot.

Conclusie
Helaas betekent een nieuw jaar voor overwerkte beheerders en beveiligingsteams niet het einde van oude problemen, en de uitbuiting van Log4j en gerelateerde JNDI-kwetsbaarheden zal veel beheerders nog wel een tijdje blijven achtervolgen. Nogmaals: we dringen er bij iedereen op aan om ervoor te zorgen dat kwetsbare software wordt gepatcht naar de nieuwste versie of wordt verwijderd als dat niet mogelijk is.

Als er dan iets positiefs te melden is, dan is het wel dat bedreigers alleen van kwetsbaarheden kunnen profiteren als ze zich schuldig maken aan kwaadaardig gedrag, en dat is waar AI-ondersteunde endpointbeveiliging tot zijn recht komt. Of het nu gaat om cryptominers of malware-loaders, ransomware of banking trojans: de inzet van een autonome detectie- en mitigatie-oplossing is een essentieel onderdeel van de verdediging van de moderne organisatie.