Veileder - Kritisk sårbarhet i Apache Log4j (CVE-2021-44228)

NCSC oppfordrer virksomheter til å sette seg inn i forskjellene på de ulike Log4j-versjonene. Det er avdekket en ny sårbarhet i 2.15.0 som tidligere ble ansett som sikker.  Se detaljer for mer informasjon.

Apache Log4j er ett av flere programvarebiblioteker som brukes for logging i Java-baserte applikasjoner. Log4j er publisert som åpen kildekode av Apache Software Foundation og brukes av andre programvareprodusenter, og av utviklere generelt, i et stort antall applikasjoner. En sårbarhet i verktøyet Log4j kan dermed bli en sårbarhet i alle applikasjoner som bruker dette biblioteket.

Sårbare applikasjoner vil kunne tillate fjernkjøring av kode fra uautentiserte brukere dersom de tillater mottak av bruker-input, som deretter sendes videre til det sårbare Log4j-biblioteket. Ondsinnede aktører vil da kunne sende kode direkte til biblioteket gjennom for eksempel et søkefelt. 

[EDIT: 29.12.21, kl 13:00] Apache har sluppet en ny versjon 2.17.1 som fikser en nylig oppdaget "Remote Code Execution"-sårbarhet i versjon 2.17.0. Sårbarheten, CVE-2021-44832 har CVSS-score 6.6. Utnyttelse av sårbarheten er avhengig av at konfigurasjonsfilen til Log4j er satt opp på en ikke-standard måte. Den er derfor betraktelig vanskeligere å utnytte ettersom den krever at angriper allerede er inne i systemet og har tilgang til å endre konfigurasjonsfilen til Log4j.

[EDIT: 20.12.21, kl 12:30] Det har vært mange motstridende meldinger rundt hvilke Log4j-versjoner som er sårbare. Per 20. desember ansees versjon 2.15.0 og høyere som IKKE sårbare for utnyttelse av CVE-2021-44228. Versjon 2.15.0 er imidlertid sårbar for utnyttelse av CVE-2021-45046, en tjenestenektsårbarhet med CVSSv3-score på 9.0 som tillater fjernkjøring av vilkårlig kode. Versjon 2.16.0 ble sluppet forrige uke for å lukke denne sårbarheten. Imidlertid ble det raskt klart at denne er sårbar for utnyttelse av en ny tjenestenektsårbarhet (CVE-2021-45105) med CVSSv3-score 7.5.

[EDIT: 20.12.21, kl 12:30] På bakgrunn av dette ble versjon 2.17.0 sluppet 18. desember. Dette er den siste trygge versjonen, og NCSC anbefaler systemeiere å oppdatere til 2.17.0 så raskt det lar seg gjøre.

Dersom dette endrer seg eller det dukker opp omgåelser av sikkerhetsoppdateringene til disse versjonene vil denne nettsiden bli fortløpende oppdatert. 

Log4j 1.x  er en eldre utgave av dette biblioteket som ikke er berørt av CVE-2021-44228, ettersom den sårbare lookup-mekanismen ikke eksisterer på samme måte.  Log4j 1.x har imidlertid ikke vært vedlikeholdt siden 2015 og har således veldig mange andre sårbarheter. Det er også identifisert en tilsvarende sårbarhet i JMS Appender som kan resultere i RCE. Dette er noe man manuelt må ha skrudd på. Denne vurderes som mindre kritisk fordi den er vanskeligere å utnytte.  

Apache publiserte 16. desember versjon 2.12.2. Denne versjonen støtter Java 7, og skrur av JNDI som standard, samt fjerner lookups. Vår forståelse er dermed at denne er trygg for utnyttelse av CVE-2021-44228 for de som av ulike grunner ikke kan oppgradere til Java 8. Se Spørsmål og svar for mer informasjon rundt Java. 

Les mer om sårbarheten her:

https://logging.apache.org/log4j/2.x/security.html
https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

Gjennom tiltaksanbefalingene henviser vi til egen ressursside for one-linere og script, ment som forslag til virksomheter som trenger et sted å starte. Ingen av disse vil alene gjøre virksomheten din trygg - nødvendige sikkerhetsoppdateringer er det eneste fullverdige tiltaket i seg selv. NCSC tar forbehold om at ikke alle disse vil fungere likt på alle systemer i alle miljøer og konfigurasjoner. 

1. Identifiser sårbare tjenester

Første prioritet for alle virksomheter bør være å identifisere hvilke systemer og applikasjoner som benytter Log4j. Log4j-biblioteket brukes hyppig i mange større applikasjoner og følgende ressurser gir en ikke-uttømmende oversikt over sårbare produkter:
NCSC-NL
CISA
YfryTchsGD
MVN repository

Dersom programvaren du bruker ikke er nevnt i noen av listene, og du heller ikke har mottatt informasjon fra din programvareleverandør, anbefaler vi uansett å gjøre undersøkelser lokalt for å avdekke eventuelle forekomster av Log4j.  Det kan eksistere spesialsystemer som ikke er dekket av listene og NCSC anbefaler at virksomhetene går i dialog med sine leverandører for å avklare status. Det finnes verktøy som virksomheter kan bruke for å enklere lokalisere kodebiblioteker, dersom virksomheten har store kodebaser eller samlinger med programvare. Vi bemerker at  NCSC ikke har testet akkurat disse verktøyene selv.

Ettersom Java-applikasjoner kan inneholde alle nødvendige biblioteker lokalt i installasjonen anbefaler vi å gjøre undersøkelser i det lokale filsystemet. Denne typen undersøkelser inkluderer å lete i innsiden av EAR-, JAR- og WAR-filer. Dersom din virksomhet bruker et pakkesystem eller lignende kan en gjøre søk i disse. For et eksempel på hvordan du kan gjøre dette, se vår ressursside for onelinere og script.

2.  Oppdater til nyeste versjon av Log4j

Formål: Oppdater Log4j der det er mulig

Dersom din virksomhet bruker applikasjoner som har Log4j anbefaler vi at du oppdaterer så raskt det lar seg gjøre. 

Dersom du befinner deg i en situasjon hvor din virksomhet ikke kan oppdatere forekomster av Log4j, eller av ulike årsaker ikke får utført sikring av tjenesten, bør det sterkt vurderes å ta tjenesten av nett frem til en løsning foreligger, eventuelt referer til punkt 3 under.   

NCSC er kjent med at enkelte spesialverktøy knekker ved oppdatering. Se punkt 3 for alternative tiltak.

3.  Utfør sikkerhetstiltak

Formål: Redusere risiko for utnyttelse hvis man av ulike årsaker ikke kan oppdatere eller ta tjenester av nett

Det eneste fullverdige alternativet er å oppdatere Log4j til 2.15.0 eller senere. 

Det kan være mange forekomster av Log4j på et system og hver forekomst må håndteres individuelt.

Dersom det av ulike årsaker ikke er mulig å sikkerhetsoppdatere Log4j, og heller ikke ta aktuelle tjenester av nett, vil følgende tiltak kunne bidra til å redusere risiko for utnyttelse. 

• Blokkering av Log4j ved hjelp av brannmurer for webapplikasjoner (WAF) med nødvendige regelsett  
• Blokkere egress-trafikk, særlig for LDAP, LDAPS, RMI og DNS - selv om sårbarheten i prinsippet kan utnyttes over arbitrære porter og protokoller.
• Regelsett på interne brannmurer som stopper tilgang til ukjente eksterne noder for systemer som i utgangspunktet kun skal ha begrenset eller ingen tilgang til Internett.

Mer informasjon finner du på vår ressursside. Her finner du også anbefalte mitigeringer dersom du kjører versjon 2.7 til 2.14.1 eller 2.0-beta9 til 2.7.

Vær oppmerksom på at enkelte mitigerende tiltak kan føre til forstyrrelser i andre tjenester som avhenger av utgående trafikk.

4. Monitorer

Formål: Identifisere om du er forsøkt utnyttet eller  kompromittert

NCSC understreker at tiltakene ovenfor kun adresserer risikoen for fremtidige utnyttelser. Det er meldt om observasjoner av utnyttelse så tidlig som 1. desember 2021. Det er derfor et potensial for at trusselaktører kan ha utnyttet sårbarheten på et tidligere tidspunkt enn publiseringen 9. desember. Virksomheter bør derfor undersøke om berørte applikasjoner har tegn på kompromittering tilbake i tid, i hvert fall tilbake til 1. desember.

På NCSCs ressursside for Log4j, har vi beskrevet ulike måter dette kan utføres på. Dette er ikke en uttømmende liste, og virksomheter bør sørge for å holde seg oppdatert på hvilke nyttelaster som leveres i utnyttelsesforsøk, samt hvordan man søker etter disse.

Dersom virksomheten din lagrer netflow-data eller du har EDR-dekning på nettverksressurser bør du søke etter internt initierte LDAP, LDAPS, RMI og DNS-koblinger til eksterne destinasjoner som er uvanlige. Vi understreker her at det ikke vil være tilstrekkelig å gå etter portnummer. Dette vil kunne indikere utnyttelse, og i så fall bør den initierende verten undersøkes for forekomst av Log4j. DNS-forespørsler fra serveren rundt den mistenkelige tilkoblingen bør også undersøkes, ettersom sensitiv informasjon kan ha blitt eksfiltrert over DNS.

Loggfiler fra tjenester som bruker berørte versjoner av Log4j kan også inneholde strenger som er aktuelle å se etter, og flere av disse er beskrevet på ressursssiden. Vi gjør imidlertid her oppmerksomme på at flere aktører aktivt obfuskerer slike strenger i nyttelastene sine.

Dersom din virksomhet opplever en vellykket kompromittering gjennom Log4j-sårbarheten, oppfordrer NCSC til å ta kontakt direkte med oss eller med deres respektive responsmiljø. Hvis man trenger bistand til hendelseshåndtering oppfordrer vi virksomheten til å konsultere NSMs Kvalitetsordning for hendelseshåndtering.

NSM-ressurser

1. Ressursside for Log4j 
2. Generelle spørsmål og svar om Log4j
3. Tekniske spørsmål og svar om Log4j
4. Kvalitetsordningen for IKT-hendelseshåndtering 
5. Grunnprinsipper for IKT-sikkerhet
6. NSMs råd for digital utpressing og løsepengeangrep

Eksterne ressurser

• Apache
• CISA 
  [EDIT 23.12.21, kl 11:00 - ny versjon i samarbeid med UK, CAN, NZ og AUS]
• NCSC-NL 
• NCSC-UK
• GovCERT.ch 
• Cisco 
• Cloudflare
• Microsoft 

Berørte produkter og tjenester

NCSC anbefaler oversikten til amerikanske CISA og NCSC-NL. 

Råd til leverandører og utviklere

Det er ikke nødvendigvis lett for virksomheter å identifisere på egenhånd om de er berørt av denne sårbarheten. NCSC vil derfor oppfordre leverandører og utviklere som bruker Log4j til å kontakte kunder for å hjelpe dem med sikkerhetsoppdateringer og mitigering.

Status i Norge akkurat nå

NCSC har foreløpig ikke observert de store kompromitteringene nasjonalt. Vår vurdering er imidlertid at angrepskoden kommer til å forbedres og spisses i tiden fremover. Eksempler på dette inkluderer blant annet følgende:

• Meldinger om at det arbeides med å gjøre sårbarheten ormbar.
• Mitigerende tiltak som tidligere ble ansett som effektive, blir omgått.
• Internasjonal rapportering om at sårbarhetsutnyttelse blant annet har resultert i kryptoutvinnere, løsepengevirus og Cobalt Strike.
• Forsøk på å utnytte sårbarheten via e-poster som inneholder JNDI-lookups i eksempelvis headere, emnefelt og body.

For tilbakemelding på denne nettsiden:
[email protected]

For operative hendelser eller rapportering av kompromittering:
[email protected]
Telefon 24/7: 02497 (kun ved kritiske henvendelser)