Oppdatering med tekniske spørsmål og svar: Kritisk sårbarhet i Apache Log4j
NCSC ønsker å komme med en oppdatering til våre tidligere varsler knyttet til sårbarheten CVE-2021-44228 i Apache Log4j [1,2,3,4].
Se referanser nederst i saken.
Både NCSC og andre sikkerhetsmiljøer verden over har gjennom helgen jobbet intenst med å få oversikt over sårbarheten og hvilke konsekvenser den har. Sårbarheten har som kjent fått CVSS-score på 10.0 og det rapporteres om omfattende utnyttelsesforsøk både nasjonalt og internasjonalt [5].
NCSC har foreløpig ikke observert de store kompromitteringene nasjonalt. NCSCs vurdering er imidlertid at angrepskoden kommer til å forbedres og spisses i tiden fremover. Eksempler på dette inkluderer bl.a. følgende:
Meldinger om at det arbeides med å gjøre sårbarheten "wormable" [6].
Internasjonal rapportering om at sårbarhetsutnyttelse blant annet har resultert i kryptoutvinnere og Cobalt Strike [7].
Forsøk på å utnytte sårbarheten via e-poster som inneholder JNDI-lookups i eksempelvis headere, emnefelt og body [5].
På bakgrunn av disse, og et økende omfang lignende rapporteringer, er det kritisk at man iverksetter de anbefalte tiltakene som har vært kommunisert tidligere.
Anbefalte tiltak
- Oppdater berørte systemer til 2.16.0* eller senere. Dersom det av ulike grunner ikke er mulig å oppdatere, se punkt 3 og 4.
- Identifisering av Log4j-komponenter. For å være sikker på at ikke sårbare komponenter henger igjen, bør man gjøre gode undersøkelser i egen organisasjon og gå i dialog med eventuelle leverandører.
- Teknisk mitigering. Det er mulig å gjøre teknisk mitigering i Log4j dersom oppdatering ikke er mulig, se [9,10,11] for detaljer.
- Isolering av applikasjon/tjeneste. Virksomheter som ikke kan oppdatere eller innføre teknisk mitigering bør sterkt vurdere å ta applikasjonen av nett.
- Ettersom utnyttelse av sårbarheten krever en såkalt "callback" for å kunne gjøre en ondsinnet handling, så anbefales det som alltid å avgrense systemer til å bare kunne kommunisere med kjente og nødvendige ressurser. Dette kan gjøres f.eks gjennom brannmurregler.
Flere sikkerhetsleverandører har nå som standard oppdatert sine regelsett for å blokkere ondsinnet trafikk relatert til Log4j-utnyttelsesforsøk. Påse derfor at nødvendige regelsett er aktive.
NCSC understreker at disse tiltakene bare adresserer risikoen for fremtidige utnyttelser. Det er meldt om observasjoner av utnyttelse så tidlig som 1. desember 2021 [8]. Det er derfor et potensial for at trusselaktører kan ha utnyttet sårbarheten på et tidligere tidspunkt enn offentliggjøringen 9. desember. Virksomheter bør derfor undersøke om berørte applikasjoner har tegn på kompromittering tilbake i tid, i hvert fall til 1. desember [12].
Vi gjør oppmerksomme på at Apache har publisert ny oppdatering for Log4j, versjon 2.16.0. Med denne versjonen har utviklerne av Log4j skrudd av JNDI som standard. Både versjon 2.15.0 og 16.0 er derfor ikke sårbare for CVE-2021-44228** [17].
Det begynner etterhvert å bli veldig mange mitigeringsressurser tilgjengelig rundt denne sårbarheten og NCSC arbeider med publisering av oppdaterte tekniske råd på våre nettsider. Denne vil bli tilgjengeliggjort i løpet av morgendagen. Lenger ned i dette varselet inkluderer vi svar på noen av de spørsmålene vi har fått mest av siden fredag. NCSC-NL vedlikeholder en liste over berørte produkter som finnes her [14]. Vi kan også anbefale ressurser fra blant annet CISA GovCERT.CH, Cisco.[5,12,13].
NCSC oppfordrer fortsatt virksomheter til å kontakte NCSC eller sine egne sektorvise responsmiljøer dersom man observerer aktiv utnyttelse i sine tjenester eller applikasjoner.
* Oppdatert 15. desember 2021, 15:55. Opprinnelig tekst "2.15.0" er endret til "2.16.0
** Oppdatert 15. desember 2021, 18:00. Opprinnelig tekst "CVE-2201-44228" er endret til "CVE-2021-44228"
OFTE STILTE SPØRSMÅL
Q: Finnes det en oppklaring rundt Java-versjonen 8u121?
A: Det har vært usikkerhet vedrørende sårbarhet i Java-versjon 8u121 [15]. Java versjon 8u121 (lansert 2017-01-17) har ekstra sikkerhetsmekanismer som standard for å minske faren for fjerneksekvering av kode. Innstillingene som styrer dette er satt til `false` som standard i Java versjon 8u121 og senere:
com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase
Dette er ikke en fullgod løsning og NCSC anbefaler at virksomheter oppdaterer Log4j så raskt som mulig. Hvis dette er problematisk, se de andre ovennevnte tiltakene.
Q:Er det avklart om sårbarheten er gjeldende for versjoner pre 2.0 ? Altså 1.x versjoner?
A: Log4j 1.x er ikke berørt av CVE-2021-44228, ettersom den sårbare lookup-mekanismen ikke eksisterer på samme måte [16]. 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.
Q: Har NSM noen anbefaling for verktøy (gratis eller kommersielt), som kan skanne etter sårbarheten internt i organisasjonen?
A: Se NCSC-NL sin skanneoversikt her.
Q:Hvor effektiv vil en innstramming med GeoLocation Norway på innkommende trafikk fra internett være?
A: Såkalt Geofencing kan være et godt, generelt tiltak og vil sannsynligvis blokkere en del av utnyttelsesforsøkene for CVE-2021-44228. Dette regnes dog ikke som en fullgod løsning, ettersom utnyttelsesforsøk også vil kunne komme fra norske servere
Q: Kjenner dere til om callback kan bruke noen av de andre protokollene som støttes enn LDAP?
A: Ja, LDAP(S), RMI, DNS, NIS, IIOP, CORBAL, NDS og HTTP er observert av Cisco [5].
Q: Kan dere gi noen kommentarer til konsekvenser for norske virksomheter så langt?
A: Enkeltvise kompromitteringer, mye arbeid knyttet til kartlegging og konsekvensutredning.
Q: Deutsche Telecom twitret at flesteparten av forsøkene de observerte kom via TOR-nettverket. Er det sammenfallende med det NSCS observerer?
A: NCSC observerer mye ondsinnet trafikk fra hele internett, hvor mye kommer fra kjente TOR-noder.
Q: Kjenner man til IP-adresser til malware payload-siter? Kan disse blokkeres?
A: Det finnes mange gode ressurser på IOC-er her [14]. Merk at blokkering av enkeltindikatorer er ikke en fullgod løsning.
Q: Det finnes informasjon på Twitter om en ormbar versjon av skadevaren. Har NCSC noe informasjon om dette?
A: NCSC er kjent med meldinger publisert av bla. @Laughing_Mantis. NCSC har ingen yttligere informasjon og fortsetter å følge utviklingen.
Referanser
Referanser:
[1] [NCSC-NO#21375915] [TLP:HVIT][NCSC-varsel] Kritisk sårbarhet i Apache Log4j [2] [NCSC-NO#21551146] [TLP:HVIT][NCSC-Varsel] Oppdatert varsel for kritisk sårbarhet i Apache Log4j2 [3] [NCSC-NO#21429282] [TLP:GRØNN][NCSC-varsel] VIKTIG - Oppdatering: Kritisk sårbarhet i Apache Log4j [4] [NCSC-NO#21825943] [TLP:GRØNN][NCSC-Varsel] Utvidet oppdatering for Apache log4j CVE-2021-44228
[5] https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
[6] https://twitter.com/laughing_mantis/status/1470165580736987137
[8] https://twitter.com/eastdakota/status/1469800951351427073
[9] https://logging.apache.org/log4j/2.x/security.html
[10] https://access.redhat.com/security/cve/cve-2021-44228
[11] https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
[12] https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
[13] https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
[14] https://github.com/NCSC-NL/log4shell
[15] https://twitter.com/wdormann/status/1470505967196545025