Så skyddar du dig mot säkerhetshålet i Log4j

I dagarna blev en kritisk sårbarhet i Java-modulen Apache Log4j publik för allmänheten. Det utsatta Java-biblioteket används för loggning i miljontals appar och tjänster från diverse olika leverantörer. Eftersom Log4j är så pass frekvent använt är risken för exponering hög och sårbarheten extra kritisk.

– Det är en relativt liten komponent men som används i väldigt mycket it-infrastruktur och Java-applikationer, vilket gör problemet oerhört utspritt, säger Per Bergman, teknisk chef på Atea. 

Vidden går att jämföra lite med millenniebuggen. Då handlade det om en brist i utformningen av datumformat i program och system som innebar att de skulle kunna sluta fungera den 1:a januari år 2000. 

– Millenniebuggen var en jättesnackis. Som tur var kunde vi jobba med den flera år i förväg, så när millennieskiftet väl var ett faktum blev inte problemen så stora. Dock var spridningen väldigt bred. Här ser vi en liknande omfattning men skillnaden är att vi fick reda på problemet i fredags, så framförhållningen är icke existerande och här kan också it-miljöer bli hackade.

Endast en kodsträng krävs

Sårbarhetstypen kallas Remote Code Execution och gör att obehöriga kan exekvera skadlig kod i infrastrukturen eller applikationen som kör Log4j. Läget anses extra allvarligt eftersom angripare enkelt kan få tillgång till system genom att använda en enda speciell kodsträng som vem som helst kan hitta på internet. 

– Den som attackerar kan ta över det berörda systemet och få tillgång till dess information. Detta kan också användas som brohuvud till att attackera flera andra delar i den berörda it-miljön. Där kan angriparen få tag i information, plantera in skadlig kod och så vidare. 

Hur ska jag göra om jag är drabbad, eller misstänker att jag är drabbad?

– Följ dina leverantörers säkerhetsbulletiner. Kontrollera och inför säkerhetsuppdateringar, börja med it-infrastruktur och Java-applikationer som har öppningar mot internet. Anta att du är sårbar tills du har verifierat motsatsen.

– Om ett system du misstänker är sårbart inte är kritiskt för din verksamhet bör du överväga att stänga av det tills du får kontroll. 

– För egenutvecklade applikationer behöver källkoden inspekteras för att se om Log4j används och kan behöva uppdateras för att mitigera sårbarheten.

Kan enskilda företag och organisationer motverka liknande incidenter i framtiden?

– Egentligen inte. För verksamheter är det viktigaste att ha kontroll på sin it-infrastruktur och sina applikationer, att de vet vilka som är leverantörer, vilka versioner de använder, vilka serviceavtal de sitter på, och så vidare. Har man denna kontroll kan man agera mycket snabbare vid liknande hot. 

Sårbarheten i Log4j kommer att vara något som vi får leva med under en tid framöver, menar Per Bergman. 

– I första vågen kommer angriparna att söka efter it-infrastruktur och applikationer hos stora verksamheter. I nästa våg fiskar de på fler ställen men efter lite mindre verksamheter. Och i tredje vågen kommer angriparna, via infekterade datorer och annat, att söka internt i kundens nät, inte bara via internet. 

– Sårbarheten är inbyggd på så många ställen vilket gör att angripare kommer söka under lång tid. Vi kommer få leva med den, så det gäller verkligen för verksamheter att scanna igenom alla sina system, ned till varje applikation.