Log4j 2.16 sårbar för DoS-attacker, brådskande patch 2.17 rekommenderas

Effekten av den ökända sårbarheten i Java-biblioteket Log4j drar ut på tiden. Även om det största problemet löstes med brådskande patch 2.16, verkar även denna version vara mottaglig för missbruk. Säkerhetsforskare hittade en ingång för Denial of Service (DoS)-attacker. Log4j 2.17 har publicerats för att stänga posten.

Apache, utvecklare av Java-biblioteket, råder organisationer att använda nödpatchen. Det rådet gäller för tredje gången sedan biblioteket konstaterades vara sårbart.

För en och en halv vecka sedan, säkerhetsforskare från Alibabas cloud säkerhetsteam avslöjade en metod för att missbruka applikationer med Log4j. Log4j används i applikationer för att logga händelser. Det visade sig vara möjligt att komma åt applikationer med biblioteket utifrån med instruktioner för att exekvera skadlig programvara. Missbruk tar inte mycket mer än ett ögonblick. Lägg därtill den uppskattade förekomsten av biblioteket i de flesta företagsmiljöer så förstår du omfattningen av den katastrof som det globala IT-landskapet står inför.

Mjukvaruutvecklare som Fortinet, Cisco, IBM och dussintals andra använder biblioteket i sin programvara. Deras utvecklare arbetade övertid under helgen den 11 december för att bearbeta den första nödpatchen för sårbarheten och leverera den till användarorganisationer. Exakt samma drift förväntades från IT-teamen inom dessa organisationer. Hundratusentals attackförsök ägde rum över hela världen. Alla var tvungna att byta till 2.15 så snart som möjligt – tills 2.15 också visade sig vara sårbara.

Vissa konfigurationer av biblioteket förblev möjliga i version 2.15. Att använda dessa konfigurationer vidmakthöll sårbarheten. Version 2.16 gjorde konfigurationerna omöjliga, vilket garanterar en ny patch. Ofta till förtret för redan överarbetade IT-team. Det kan dock alltid vara värre, eftersom 2.16 också har en åkomma.

Tillbaka till början

Den massiva globala uppmärksamheten på problemet föranledde en omfattande världsomspännande undersökning. Apache, utvecklare av biblioteket, verkar inte kunna hämta andan på två dagar utan att ett säkerhetsföretag påpekar ett nytt, akut problem.

Kortfattat visar det sig att det är möjligt att köra dussintals versioner av log4j – inklusive 2.16 – med en rad (sträng) för att starta en evig loop som kraschar applikationen. Villkoren som en miljö måste uppfylla för att bli misshandlad är omfattande. Så omfattande att problemets praktiska allvar bestrids. Plåstret rekommenderas officiellt, men alla är inte övertygade.

Återigen, inte alla instanser av Log4j är sårbara, utan bara fall där biblioteket körs på anpassade inställningar. En potentiell angripare behöver också detaljerad insikt i hur Log4j fungerar. En kontrast till den initiala, lättillgängliga sårbarheten.