En alvorlig digital sårbarhet ryster en hel verden

9. desember ble en av de mest alvorlige digitale sårbarhetene noensinne offentliggjort. Hvorfor er Log4j-sårbarheten så alvorlig?

Publisert: 03.01.2022

9. desember ble en av de mest alvorlige digitale sårbarhetene noensinne, offentliggjort - inkludert et såkalt Proof of Concept som viser hvordan sårbarheten kan utnyttes. Sårbarheten finnes i en Java-modul, Log4J, som brukes til å loggføre det som skjer i applikasjonen, og forekommer når noen fra utsiden lager en spesiell hendelse som logges og hvor selve innholdet det som logges forårsaker at sårbarheten utnyttes. Selve sårbarheten kalles også Log4jShell. Applikasjonene her er som oftest det vi kaller server-applikasjoner, f.eks. mottakere av bruker-søk (eks. web), journaler, registreringssystemer, sikkerhetslogger osv. Forutsetningen for at sårbarheten er til stede, er at serverapplikasjonen er laget i Java og benytter Log4j2, versjon lavere enn 2.17.0. Da kan en angriper for eksempel skrive inn en kode i et søkefelt, når dette logges fører det til at skadelig kode blir lastet ned og kjørt på serveren.

Hvorfor er Log4j-sårbarheten så alvorlig? Log4j inngår i utrolig mange produkter, både web-applikasjoner og underliggende funksjoner. Mange av disse systemene er bundlet (tett sammenvevd leveranse) eller levert i en container/docker. I begge disse tilfellene vil ikke Log4j fremstå som en egen tjenestedel, og det kan være vanskelig å finne selve kodefilene. Modulen brukes også i systemnære produkter og verktøy som vmware (virutaliseringssystem for servere) og Dell EMC produkter til sluttbrukerprodukter som Cisco Webex Meeting Server. Når Log4j er i bruk i hundrevis av populære produkter spredt over hele verden – og sårbarheten er enkel å utnytte – blir faren ekstra stor. Med fjerneksekvering av kode kan svært mye skje, fra informasjons-innsanking/-stjeling til full kompromittering og nedstenging grunnet ransomware.

Figur 1 Teknisk illustrasjon av Log4j-sårbarhetsutnyttelse med mulige tiltak (Kilde: GovCERT.ch)


Det er allerede påvist at statssponsede aktører har utnyttet den, ransomware aktører («Konshari» ransomware) har tatt den med i sin verktøykasse, og bitcoinminere (Kinsing) er også observert i å utnytte denne muligheten for skaffe nye ressurser til sin virksomhet. Botnettet Mirai har visstnok også skaffet seg nye «bot’er» ved å bruke Log4j-sårbarheten.

Et eksempel fra den norske virkeligheten er den statlige portalen eInnsyn, som var sårbar på grunn av Log4j. eInnsyn har sendt beskjed om at klientinstallasjoner må gjøre endringer på sitt oppsett for å hindre utnyttelse.

https://samarbeid.digdir.no/eformidling/status-pa-felleslosningene-etter-sarbarhet-i-apache-log4j/1064

Serveren må ikke være eksponert på internett for å være et mulig angrepsobjekt. Hvis en bruker surfer på en ondsinnet nettside, kan nettsiden inneholde kode som bruker WebSockets til å scanne den lokale maskinen eller det lokale nettverket etter tjenester med sårbar Log4j versjon, uten at disse tjenestene er eksponert direkte på internett. Det der derfor viktig at også disse tjenestene patches, og brannmur-regler kontrollers for tjenester/maskiner som ikke trenger å kunne kommunisere ut på internett.

En annen grunn til at man også kan være sårbar på innsiden av nettverket, er at logging i mange tilfeller utføres på indre sone eller i en egen ‘management’ sone, også for applikasjoner som er eksponert mot internett.

Cisco Talos har også observert e-postbaserte angrep som forsøker å utnytte sårbarheten ved å legge inn sårbar kode i forskjellige elementer som headere, emnefelt og inne i selve meldingsteksten.

https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html

Hva gjør sikkerhetsmiljøet? Fra 9. desember har sikkerhetsanalytikere og IT-drift jobbet intenst med kartlegging av løsningers mulige sårbarheter både fra innsiden og fra utsiden av eget og CERT-medlemmers nettverk. NSM har egen artikkel på nettsiden deres, og det har vært hektisk daglig møtevirksomhet (inkludert helgen) i SRM-nettverket som består av CERT-er for de fleste sektorene i Norge, og hvor NSM er vertskap.

https://nsm.no/fagomrader/digital-sikkerhet/nasjonalt-cybersikkerhetssenter/nyheter-fra-ncsc/samleside-for-log4j/

Det har i alt kommer 3 oppdateringer til modulen Log4j 2.

2.15 Retting av feilen. Viste seg dessverre å ikke dekke alle eventualiteter

2.16 Dekket alle feil, men introduserte mulighet for DoS-angrep

2.17 Ser ut til å være OK.