De Log4j-kwetsbaarheid blijft een grote bedreiging vormen voor bedrijfsorganisaties, een jaar nadat de Apache Software Foundation het afgelopen november bekendmaakte - hoewel het aantal openbaar gemaakte aanvallen gericht op de fout zelf minder is dan velen aanvankelijk hadden verwacht.

Een hoog percentage systemen is nog steeds niet gepatcht tegen de fout, en organisaties staan ​​voor uitdagingen bij het vinden en oplossen van het probleem en vervolgens voorkomen dat de fout opnieuw in de omgeving wordt geïntroduceerd, zeggen beveiligingsonderzoekers.

"Het feit dat Log4j wordt gebruikt in [bijna] 64% van de Java-applicaties en slechts 50% daarvan is geüpdatet naar een volledig gefixeerde versie, betekent dat aanvallers het zullen blijven aanvallen", zegt David Lindner, CISO bij Contrast Security. "In ieder geval hebben aanvallers voorlopig nog een velddag om paden te vinden om via Log4j te misbruiken."

Meerdere aanvallen, maar minder dan verwacht

De Log4j-fout (CVE-2021-44228), gewoonlijk Log4Shell genoemd, bestaat in Log4j's Java Naming and Directory Interface (JNDI) -functie voor het opslaan en ophalen van gegevens. Het geeft aanvallers op afstand een triviaal gemakkelijke manier om de controle over kwetsbare systemen over te nemen - een probleem gezien het feit dat Log4J in vrijwel elke Java-toepassingsomgeving wordt gebruikt. Beveiligingsonderzoekers beschouwen het als een van de belangrijkste kwetsbaarheden van de afgelopen jaren vanwege de prevalentie en het relatieve gemak waarmee aanvallers het kunnen misbruiken.

In het afgelopen jaar zijn er talloze meldingen geweest over bedreigingsactoren die zich op de fout hebben gericht als een manier om initiële toegang tot een doelnetwerk te krijgen. Bij veel van deze aanvallen waren door de natiestaat gesteunde Advanced Persistent Threat (APT)-groepen uit China, Noord-Korea, Iran en andere landen betrokken. Zo waarschuwde de Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) in november voor een door de Iraanse regering gesteunde APT-groep die misbruik maakte van de Log4j-kwetsbaarheid in een niet-gepatchte VMware Horizon-server om implementeer cryptomining-software en credential-harvesters op een federaal netwerk.

De waarschuwing was vergelijkbaar met die van Fortinet in maart over de Chinese dreigingsactor Deep Panda die de identieke vector om een ​​achterdeur op doelsystemen in te zetten en een andere van Ahn Labs over de Lazarus Group in Noord-Korea het verspreiden van zijn eigen achterdeur dezelfde manier. Anderen, zoals Microsoft, hebben ook melding gemaakt van het observeren van statelijke actoren zoals de Iraanse Phosphorous-groep en de Chinese Hafnium-dreigingsacteur die Log4 gebruikt om drop reverse shells op geïnfecteerde systemen.

Ondanks dergelijke rapporten - en verschillende andere over financieel gemotiveerde cybercriminaliteitsgroepen die Log4j als doelwit hebben - is het werkelijke aantal openbaar gerapporteerde inbreuken waarbij Log4 betrokken was, relatief laag gebleven, vooral in vergelijking met incidenten met Exchange Server-kwetsbaarheden zoals ProxyAanmelding en ProxyShell. Bob Huber, chief security officer bij Tenable, zegt dat de schaal en reikwijdte van de gemelde aanvallen verrassend lager zijn dan verwacht, gezien de eenvoud van de kwetsbaarheid en het aanvalspad. "Pas onlangs hebben we enig significant bewijs van targeting gezien, zoals opgemerkt door recente nationale staatsactiviteiten van CISA", zegt Huber.

Onverminderde dreiging

Dat betekent echter niet dat de dreiging van Log4j het afgelopen jaar is afgenomen, merken beveiligingsonderzoekers op.

Ten eerste blijft een groot percentage van de organisaties even kwetsbaar voor de dreiging als een jaar geleden. Een analyse van telemetrie met betrekking tot de bug die Tenable onlangs heeft uitgevoerd, toonde aan 72% van de organisaties was kwetsbaar naar Log4j, vanaf 1 oktober. Tenable ontdekte dat 28% van de organisaties wereldwijd de bug volledig heeft verholpen. Maar Tenable ontdekte dat organisaties die hun systemen hadden hersteld, Log4j vaak keer op keer tegenkwamen wanneer ze nieuwe activa aan hun omgeving toevoegden.

In veel gevallen - in feite 29% - werden servers, webapplicaties, containers en andere activa kort na het eerste herstel kwetsbaar voor Log4j.

"Ervan uitgaande dat organisaties de fix aan de linkerkant van de vergelijking bouwen - tijdens de build-pijplijn voor software - zou het aantal herintroducties moeten afnemen", zegt Huber. "Een groot deel van de snelheid van herintroductie en verandering hangt sterk af van de softwarereleasecyclus van een organisatie."

Ondanks het bijna alomtegenwoordige bewustzijn van de fout binnen de cyberbeveiligingsgemeenschap, blijven kwetsbare versies van Log4j bij veel organisaties irritant moeilijk te vinden vanwege de manier waarop applicaties deze gebruiken. Sommige applicaties kunnen de open source logging-component gebruiken als een directe afhankelijkheid in hun applicaties, en in andere gevallen kan een applicatie Log4j gebruiken als een transitieve afhankelijkheid - of een afhankelijkheid van een andere afhankelijkheid, zegt Brian Fox, CTO bij Sonatype.

"Aangezien transitieve afhankelijkheden worden geïntroduceerd vanuit uw directe afhankelijkheidskeuzes, zijn ze mogelijk niet altijd bekend of direct zichtbaar voor uw ontwikkelaars", zegt Fox.

Toen de Apache Foundation Log4Shell voor het eerst bekendmaakte, moesten bedrijven in veel gevallen duizenden interne e-mails versturen, resultaten in spreadsheets verzamelen en bestandssystemen recursief scannen, zegt Fox. "Dit kostte bedrijven kostbare tijd en middelen om het onderdeel te patchen en verlengde de omvang van het schadelijke effect van de kwetsbaarheid", zegt hij.

Dat blijkt uit gegevens uit de Maven Central Java-repository die Sonatype onderhoudt 35% van de Log4-downloads momenteel nog steeds van kwetsbare versies van de software. "Veel bedrijven proberen nog steeds hun software-inventaris op te bouwen voordat ze zelfs maar met een reactie kunnen beginnen en zijn zich niet bewust van de implicaties van transitieve afhankelijkheden", zegt Fox.

Vanwege alle problemen concludeerde de beoordelingscommissie van het Amerikaanse Department of Homeland Security eerder dit jaar dat Log4 een endemisch veiligheidsrisico waar organisaties jarenlang mee te kampen zullen hebben. Leden van de raad van bestuur waren van mening dat kwetsbare exemplaren van Log4j nog vele jaren in systemen zullen blijven en organisaties in de nabije toekomst het risico zullen lopen om aangevallen te worden.

Het enige positieve resultaat

Beveiligingsonderzoekers die de bug volgen, zeggen dat de positieve gevolgen van Log4j de verhoogde aandacht zijn die het heeft getrokken voor praktijken zoals analyse van softwaresamenstelling en software-stuklijsten (SBOM). De uitdagingen waarmee organisaties te maken hebben gehad, alleen al om te bepalen of ze kwetsbaar zijn of waar de kwetsbaarheid in hun omgeving zou kunnen bestaan, hebben geleid tot een beter begrip van de behoefte aan inzicht in alle componenten in hun codebase, vooral die van open source en bronnen van derden.

"Het onderzoek naar het Log4J-probleem heeft opnieuw bevestigd dat er behoefte is aan betere attestering van de softwaretoeleveringsketen, naast SBOM's die de snelheid van DevOps bijhouden", zegt Matthew Rose, CISO bij ReversingLabs. “Applicatiebeveiligings- en architectuurteams hebben zich gerealiseerd dat alleen het zoeken naar risico's in delen van de applicatie, zoals broncode, API's of open source-pakketten, niet voldoende is. Ze realiseren zich nu dat een volledig begrip van de architectuur van de applicatie net zo belangrijk is als het vinden van SQLI of cross-site scripting bugs (XSS)”, zegt hij.

• Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.Klik Hier
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://www.darkreading.com/application-security/one-year-later-log4shell-exposed-attack