De alvorlige og omfattende sikkerhetsproblemene som i det siste har blitt oppdaget i det Java-baserte loggbiblioteket Apache Log4j, har satt IT-avdelinger over hele verden i alarmberedskap. Svært mange virksomheter er berørt – trolig langt flere enn dem som er klar over det – siden mange programvareprodukter er avhengige av Log4j, enten direkte eller indirekte.
Bare i den store Java-pakkesamlingen Maven Central Repository er det 36 tusen ulike pakker som er avhengige av Log4j. Bare en brøkdel av disse har så langt blitt patchet.
Fare for DoS-angrep
Som tidligere omtalt har det allerede kommet to sikkerhetsoppdatering som fjerner sårbarheter i Log4j. I helgen kom den tredje sikkerhetsoppdateringen til Log4j på halvannen uke, nemlig versjon 2.17.0 (for Java 8). Denne fjerner en sårbarhet som angripere kan utnytte ved hjelp av en spesielt utformet streng til å utnytte tjenestenektangrep (Denial of Service). Årsaken til sårbarheten skal være at berørte versjoner av Log4j ikke beskytter mot ukontrollert rekursjon av selvrefererende oppslag.
Apache Foundation oppgir at denne hittil siste sårbarheten bare berører JAR-filen log4j-core. Applikasjoner som bare benytter JAR-filen log4japi, uten log4j-core, er ikke berørt.
Selv om denne sårbarheten anses som noe mindre alvorlig enn de øvrige som nylig har blitt fjernet, da den ikke åpner for kjøring av vilkårlig kode, vil angrep som utnytter den, potensielt kunne forårsake betydelige problemer for berørte systemer. Derfor bør også denne sårbarheten fjernes eller avvæpnes så raskt som mulig.
Apache Foundation oppgir på denne siden et par konfigurasjonsendringer som kan gjøres for å forhindre at den hittil siste av sårbarhetene kan utnyttes.
OpenAI starter butikk: Snart kan du kjøpe dine egne snakkeroboter
Angrep via nettleseren?
Så langt har det blitt antatt at den første av de aktuelle sårbarhetene bare har hatt kunnet utnyttes på sårbare, eksponerte servere. Nå har sikkerhetsforskere i selskapet Blumira oppdaget at sårbarheten også kan utnyttes via websider. Det kan da være nok at en bruker – som enten har en sårbar versjon av Log4j installert på PC-en eller på annen datamaskin i det tilknyttede lokalnettet – besøker en ondsinnet eller modifisert webside. Dette er omtalt av ZDNet.
Utnyttelsen kan gjøres ved hjelp av webteknologien Websockets, som kan kjøres med mer begrenset sikkerhet i nettleseren enn det som er vanlig for webteknologier. Blumira forklarer detaljene på denne siden.
Lange avhengighetskjeder
Som nevnt er mye Java-basert programvare avhengig av Log4j-bibliotektet, men ofte er det slik at avhengigheten ikke er direkte. I stedet baseres en programvare på ett eller flere biblioteker eller pakker, som på sin side er avhengige av Log4j, eller avhengige av andre biblioteker og pakker som har en slik avhengighet.
Google har analysert disse avhengighetene og funnet ut at mer enn 80 prosent av de berørte pakkene i den tidligere nevnte Maven-samlingen er indirekte avhengige av Log4j. I mange pakker er denne avhengigheten minst fem nivåer dyp. I de mest ekstreme tilfellene er det snakk om ni nivåer. Da må pakkene på alle de ni nivåene fikses, nedenfra og opp.
Basert på hvor lang tid det tidligere har tatt å løse lignende tilstander, antar Google at det vil kunne ta flere år før alt er rettet, til tross for at det nå gjøres en iherdig innsats når det gjelder akkurat Log4j.
Simulerer angrep mot IKT-infrastruktur: – Du er ofte satt sjakk matt fra start
