2min

Tags in dit artikel

, , ,

Ongeveer iets meer dan een derde van bedrijfsapplicaties die van Log4j-libraries afhankelijk zijn, gebruiken nog steeds een versie die kwetsbaar is voor Log4Shell.

Dat blijkt uit cijfers van Veracode. Veel bedrijven hebben nog steeds niet de al twee jaar bekende Log4j-kwetsbaarheid in hun applicaties aangepakt, ondanks het feit dat vaak met klem is opgeroepen deze te verhelpen en dat er oplossingen beschikbaar zijn.

De belangrijkste reden dat de kwetsbaarheden nog actief zijn, geeft Veracode in zijn onderzoek aan, is dat applicaties een verouderde niet-gepatchte versie van Log4j gebruiken. Dit zijn de versies 1.1 tot en met 3.0.0-alpha1.

Vooral versies Log4j 2.0-beta9 tot en met 2.15.0 zijn zeer kwetsbaar, aangezien deze direct gevoelig zijn voor de beruchte Log4Shell-kwetsbaarheid of CVE-2021-44228. Deze heeft de maximale kwetsbaarheidsrating en werd in december 2021 al ontdekt. Op het moment van ontdekking werd deze toen zero day-kwetsbaarheid al extreem vaak door hackers misbruikt.

Eerder dit jaar besprak Techzine in Techzine Talks hoe de Log4Shell-kwestie anno 2023 nog steeds een groot probleem is voor bedrijven. Luister hier de hele podcast:

Veel kwetsbare versies in gebruik

Veracode ontdekte dat twee jaar later bedrijven deze zeer kwetsbare versies nog steeds niet hebben aangepkt. Ongeveer 2,8 procent van alle onderzochte applicaties gebruikt de Log4j-varianten 2.0-beta9 tot en met 2.15.0.

Daarnaast gebruikt 3,8 procent nog steeds de Log4j 2.17.0-versie die weer ontvankelijk is voor een andere zware kwetsbaarheid. Verder gebruikt nog 32 procent van de onderzochte applicaties Log4j-versie 1.2.x waarvan de ondersteuning al sinds de maand augustus van 2015 is stopgezet. Voor deze laatste versies zijn vorig jaar een aantal belangrijke kwetsbaarheden aan het licht gebracht.

Patchtrajecten duren zeer lang

Wat mogelijk nog zorgwekkender is, concludeert Veracode verder, is dat ontwikkelaars zeer vaak, in 79 procent van de onderzochte gevallen, de libraries van derde partijen niet updaten wanneer zij deze in hun code voegen. Dit omdat zij willen voorkomen dat de functionaliteit problemen gaat opleveren.

Verder kost het bij 50 procent van de ontwikkeltrajecten ongeveer 65 dagen voordat security issues met een hoge kwetsbaarheid worden aangepakt. Ook duurt het 13,7 keer langer en meer dan 7 maanden om ongeveer de helft van de problemen in de backlog te fixen, door het gebrek aan personeel.

Lees ook: Log4Shell anno 2023: keiharde impact dreunt nog na