De eerste patch van Log4j is in sommige gevallen onvoldoende om misbruik via de Log4Shell-bug te voorkomen. Ook standaard-mitigaties schieten tekort.
Een tweede kwetsbaarheid in Log4j zorgt ervoor dat aanvallers de enorme Log4Shell-bug kunnen blijven misbruiken, ook wanneer er al een patch of mitigaties zijn uitgerold. Dat ontdekten onderzoekers van LunaSec, die ook mee de kat de bel aanbonden bij de initiële kwetsbaarheid. Log4Shell is een bug die hackers kunnen misbruiken om via de populaire Log4j-logtool eigen code uit te voeren.
lees ook
Wat is Log4Shell en waarom is de bug zo gevaarlijk?
Het nieuwe lek is een variatie op de eerste kwetsbaarheid waarop eerdere oplossingen geen vat hebben. LunaSec maakt een onderscheid in de impact van de bug al naargelang de versie van Log4j. Wie nog niets geüpdatet heeft, loopt het grootste risico. In dat geval krijgen aanvallers een nieuwe piste om eigen malafide code uit te voeren en kunnen ze toepassingen die Log4j gebruiken blokkeren via een DOS-aanval.
Ontoereikende patch
Apache probeerde Log4Shell op te lossen met een noodupdate voor Log4j naar versie 2.15.0. Toepassingen met de update lijken voorlopig niet kwetsbaar voor de DOS-aanval, aangezien die geen veelvoud aan resources gebruikt. In bepaalde configuraties blijft het echter wel mogelijk voor hackers om eigen code uit te voeren. De eerdere mitigatie, waarbij log4j2.noFormatMsgLookup naar true wordt gezet, helpt evenmin tegen de nieuwe bug.
Apache lanceerde intussen Log4j versie 2.16.0 die ook het nieuwe beveiligingsprobleem in rekening brengt. De beveiligingsonderzoekers raden aan om die zo snel mogelijk te installeren. Aangezien Log4j een component is in heel veel populaire software van derden, zijn organisaties daarvoor afhankelijk van patches van die externe softwareleveranciers.