Log4Shell is er een die de komende tien jaar zal verschijnen bij datalekken
Deze laatste maand van het jaar 2023 markeerde de tweede verjaardag van de ontdekking van de Log4j/Log4Shell-kwetsbaarheid, Dit is een kwetsbaarheid die vandaag de dag nog steeds veel projecten treft en een veiligheidsrisico met zich meebrengt.
En Log4j blijft een belangrijk doelwit voor cyberaanvallen, volgens Cloudflare's jaarlijkse "Year in Review"-rapport en ook de resultaten van een onderzoek naar de relevantie van kritieke kwetsbaarheden in de Log4j Java-bibliotheek, vrijgegeven door beveiligingsonderzoekers door Veracode.
De Dat melden Veracode-onderzoekers na bestudering van 38.278 aanvragen gebruikt door 3.866 organisaties, ontdekten zij dat twee op de vijf applicaties gebruiken nog steeds kwetsbare versies van de Apache Log4j-bibliotheek, twee jaar nadat een kritieke kwetsbaarheid openbaar werd gemaakt.
Het rapport benadrukt dat ongeveer een derde van de applicaties Log4j2 1.2.x draait (dat in augustus 2015 het einde van zijn levensduur bereikte en geen patchupdates meer ontvangt), wat neerkomt op 38%. De belangrijkste reden om verouderde code te blijven gebruiken is de integratie van oude bibliotheken in projecten of de moeizaamheid van het migreren van niet-ondersteunde branches naar nieuwe branches die achterwaarts compatibel zijn. Bovendien maakt 2.8% van de applicaties nog steeds gebruik van versies die kwetsbaar zijn voor de bekende Log4Shell-kwetsbaarheid.
Daarnaast Er wordt vermeld dat er drie hoofdcategorieën zijn van de applicaties die nog steeds kwetsbare versies van Log4j gebruiken, volgens het Veracode-rapport:
- Log4Shell-kwetsbaarheid (CVE-2021-44228):
2.8% van de applicaties blijft Log4j-versies van 2.0-beta9 tot 2.15.0 gebruiken, die de bekende kwetsbaarheid bevatten. - Beveiligingslek met betrekking tot uitvoering van externe code (RCE) (CVE-2021-44832):
3.8% van de applicaties gebruikt de versie Log4j2 2.17.0, die de Log4Shell-kwetsbaarheid verhelpt, maar de RCE-kwetsbaarheid (Remote Code Execution) geïdentificeerd als CVE-2021-44832 niet oplost. - Log4j2 1.2.x Branch (ondersteuning voltooid in 2015):
32% van de applicaties maakt nog steeds gebruik van de Log4j2 1.2.x-tak, waarvan de ondersteuning in 2015 eindigde. Deze tak is getroffen door kritieke kwetsbaarheden, zoals CVE-2022-23307, CVE-2022-23305 en CVE-2022-23302, geïdentificeerd in 2022, zeven jaar nadat het onderhoud eindigde.
Deze gegevens benadrukken de diversiteit aan situaties waarin applicaties verouderde en kwetsbare versies van Log4j blijven gebruiken, wat aanleiding geeft tot grote bezorgdheid bij onderzoekers.
En een zorgwekkend feit is dat 3.8% van de applicaties Log4j2 2.17.0 gebruikt, dat is gepatcht tegen Log4Shell, maar CVE-2021-44832 bevat, een andere ernstige kwetsbaarheid voor het uitvoeren van externe code.
Het rapport benadrukt dat, ondanks de geleverde inspanningen de afgelopen jaren om de beveiligingspraktijken bij de softwareontwikkeling en het gebruik van open source te verbeteren, er is werk aan de winkel.
Chris Eng, onderzoeksdirecteur bij Veracode, benadrukt dat:
Ontwikkelaars hebben een cruciale verantwoordelijkheid en er is ruimte voor verbetering als het gaat om de beveiliging van open source software.
Hoewel veel ontwikkelaars aanvankelijk adequaat op de Log4j-crisis reageerden door versie 2.17.0 te installeren, suggereert het rapport dat sommigen terugkeerden naar eerdere patronen door geen patches toe te passen na de release van 2.17.1.
De Apache Software Foundation (ASF) heeft downstream-projecten actief op de hoogte gebracht van de urgentie om te updaten, maar de bevindingen van het rapport geven aan dat er nog steeds applicaties zijn die de noodzakelijke oplossingen niet hebben geïmplementeerd.
Het rapport van Veracode was gebaseerd op gegevens van softwarescans van meer dan 38,000 apps gedurende een periode van 90 dagen tussen 15 augustus en 15 november. Op de applicaties draaiden Log4j-versies van 1.1 tot 3.0.0 alpha 1 in 3,866 verschillende organisaties.
Uit ons onderzoek is ook gebleken dat zodra ontwikkelaars via een scan op een kwetsbare bibliotheek worden gewezen, ze deze relatief snel repareren: 50 procent van de kwetsbaarheden wordt in totaal binnen 89 dagen opgelost, in 65 dagen voor kwetsbaarheden met een hoge ernst en in 107 dagen voor kwetsbaarheden met een gemiddelde ernst.
Deze resultaten komen overeen met eerdere waarschuwingen, zoals het rapport van de Federal Cybersecurity Review Board uit 2022, waarin werd aangegeven dat het jaren zou duren voordat de Log4j-crisis volledig zou zijn opgelost.
eindelijk als je bent geïnteresseerd om er meer over te weten, nodig ik je uit om het originele artikel op de veracode blog te bezoeken. De link is dit.