Log4j-sårbarheten utgjør en av de mest alvorlige truslene mot sikkerheten i moderne datasystemer.
Loggføring er en fundamental komponent i moderne applikasjoner, og loggbiblioteket Log4j har etablert seg som en sentral aktør på dette feltet.
Dette biblioteket er implementert i et overveldende flertall av applikasjoner, tjenester og systemer. Som en konsekvens er alle applikasjoner som benytter seg av Log4j, potensielt sårbare for denne sårbarheten som ble avdekket i fjor.
Med en global økning i bekymringen for cybersikkerhet, iverksetter både organisasjoner og privatpersoner tiltak for å beskytte sine applikasjoner, systemer og sensitive data.
Oppdagelsen av denne sårbarheten har ytterligere økt stressnivået blant fagfolk og bedrifter.
Det er derfor avgjørende å identifisere og adressere Log4j-sårbarheten for å sikre beskyttelse av data, nettverk, omdømme og kundenes tillit.
I denne artikkelen skal vi utforske hva Log4j-sårbarheten innebærer, samt de nødvendige skritt for å oppdage og utbedre den.
La oss begynne med å forstå hva Log4j er og hvorfor det er så viktig.
Hva er Log4j?
Log4j er et åpen kildekode-verktøy for loggføring, utviklet i Java. Det primære formålet er å lagre, formatere og publisere loggmeldinger generert av applikasjoner og systemer, med et spesielt fokus på feilsøking. Loggdataene kan omfatte alt fra nettsted- og nettleserinformasjon til tekniske detaljer om systemet der Log4j opererer.
I stedet for å skrive kode fra grunnen av, kan utviklere integrere Log4j-biblioteket direkte i sine applikasjoner.
Med Log4j kan utviklere spore hendelser knyttet til applikasjonene sine med nøyaktig logginformasjon. Dette bidrar til å overvåke applikasjoner, identifisere problemer i tide og fikse dem før de eskalerer til større ytelses- eller sikkerhetsproblemer.
Dette Java-baserte biblioteket ble skrevet av Ceki Gülcü og lansert i 2001 under Apache License 2.0. Det benytter Java Naming and Directory Interface (JNDI)-tjenester for å la applikasjoner kommunisere med andre applikasjoner som LDAP, DNS og CORBA. Log4j har tre hovedkomponenter for å utføre sine oppgaver:
- Loggere: For å registrere loggmeldinger.
- Konfigurasjoner: For å formatere loggmeldinger på ulike måter.
- Vedlegg: For å publisere loggmeldinger til forskjellige destinasjoner.
Log4j er et av de mest brukte loggbibliotekene på nettet og benyttes av organisasjoner fra et bredt spekter av bransjer og land. Det er integrert i et stort antall applikasjoner, inkludert ledende skytjenester fra Google, Microsoft, Apple, Cloudflare og Twitter.
Utvikleren, Apache Software Foundation, lanserte Log4j 2 som en oppgradering for å adressere svakheter i tidligere versjoner. I fjor ble det oppdaget en sårbarhet i Log4j, som, dersom den ikke håndteres, kan gi angripere tilgang til applikasjoner og systemer, stjele data, infiltrere nettverk og utføre andre skadelige aktiviteter.
La oss se nærmere på dette.
Hva er Log4Shell – Log4j-sårbarheten?
Log4Shell er en kritisk sårbarhet i Log4j-biblioteket som påvirker bibliotekets kjernefunksjonalitet. Den muliggjør fjernstyrt kodeutførelse, slik at angripere kan ta kontroll over enheter eller applikasjoner som er koblet til internett. Ved en vellykket utnyttelse kan de:
- Utføre vilkårlig kode på enheten eller systemet.
- Få tilgang til nettverk og data.
- Endre eller kryptere filer på den berørte applikasjonen eller enheten.
Denne sårbarheten ble først rapportert 24. november 2021 av Chen Zhaojun, en sikkerhetsforsker hos Alibaba. Sårbarheten påvirket Minecraft-serverne deres, og Alibabas skysikkerhetsteam oppdaget den 9. desember.
NIST publiserte deretter denne sikkerhetssårbarheten i National Vulnerability Database, der den fikk navnet CVE-2021-44228. Apache Software Foundation klassifiserte sårbarheten med en CVSS-alvorlighetsgrad på 10. Dette er en ekstremt høy score, sjelden gitt, og reflekterer potensialet for utbredt og enkel utnyttelse med betydelige konsekvenser for organisasjoner og enkeltpersoner.
Apache publiserte en oppdatering for å løse sårbarheten, men den var ikke fullstendig, noe som førte til andre sårbarheter:
- CVE-2021-45046, som åpnet for Denial of Service (DoS)-angrep via JNDI-oppslag.
- CVE-2021-45105, som ga hackere mulighet til å manipulere trådkontekstkartinformasjon og forårsake DoS-angrep ved å tolke en skreddersydd streng.
- CVE-2021-44832, som påvirker alle Log4j 2-versjoner via Remote Code Injection (RCE).
Hvordan fungerer Log4Shell?
For å forstå alvorlighetsgraden og omfanget av skaden Log4Shell kan forårsake, er det viktig å se nærmere på hvordan denne Log4j-sårbarheten fungerer.
Log4Shell-sårbarheten gjør det mulig for en angriper å eksternt injisere vilkårlig kode i et nettverk og oppnå full kontroll over det.
Denne angrepssekvensen begynner med et loggbibliotek, som Log4j, som samler inn og lagrer logginformasjon. Uten et loggbibliotek vil data fra serveren bli arkivert umiddelbart etter innsamling.
Men dersom dataene skal analyseres eller om det kreves handlinger basert på logginformasjonen, behøves et loggbibliotek som analyserer data før arkivering.
Som en konsekvens av Log4j-sårbarheten, er alle systemer eller applikasjoner som bruker Log4j, sårbare for cyberangrep. Loggbiblioteket utfører kode basert på inndata. En hacker kan manipulere inndataene og tvinge loggbiblioteket til å utføre skadelig kode.
Dette involverer en rekke prosesser i bakgrunnen. Når Log4j mottar en spesiallaget streng, vil den kalle en LDAP-server og laste ned kode for å utføre handlinger. På denne måten kan angripere opprette en LDAP-server som inneholder skadelig kode og bruke den til å kontrollere servere der koden utføres. De kan deretter sende en streng som dirigerer den ondsinnede koden til en målrettet applikasjon eller et system og overta full kontroll.
Slik kan Log4j-sårbarheten utnyttes:
- En angriper lokaliserer en server med en sårbar versjon av Log4j.
- De sender en GET-forespørsel til den målrettede serveren med en kobling til sin ondsinnede LDAP-server.
- Målserveren, istedenfor å bekrefte forespørselen, kobler seg direkte til LDAP-serveren.
- Angriperen sender et svar fra LDAP-serveren som inneholder skadelig kode. På grunn av Log4js sårbarhet, som tillater koden å bli mottatt og utført uten verifisering, kan hackeren utnytte denne svakheten til å infiltrere målserveren og de tilkoblede systemene, nettverkene og enhetene.
Hvordan kan Log4j-sårbarheten skade brukere?
Log4j-sårbarheten er alvorlig bekymringsfull på grunn av sin utbredelse i et bredt spekter av programvareapplikasjoner og systemer.
Loggføring er en essensiell funksjon i de fleste applikasjoner, og Log4j er en ledende aktør i dette feltet. Derfor finnes Log4j i en rekke programvaresystemer.
Noen av de mest populære tjenestene og applikasjonene som benytter Log4j, er Minecraft, AWS, iCloud, Microsoft, Twitter, internettrutere, programvareutviklingsverktøy og sikkerhetsverktøy. Dette betyr at et stort antall applikasjoner, tjenester og systemer er potensielle mål for angrep, inkludert hjemmebrukere, utviklere, tjenesteleverandører og andre fagfolk og privatpersoner.
I tillegg er Log4j-sårbarheten ekstremt lett for angripere å utnytte. Prosessen krever ikke avanserte ferdigheter, noe som har ført til en økning i antall angrep som utnytter denne sårbarheten.
Virkningene av Log4j-sårbarheten kan være:
- DoS-angrep.
- Angrep på leverandørkjeden.
- Kryptovalutamining.
- Injeksjon av skadelig programvare, inkludert løsepengevirus og trojanere.
- Vilkårlig kodeinjeksjon.
- Fjernstyrt kodeutførelse.
Og mer.
Som et resultat av disse angrepene kan du miste kontrollen over applikasjonene, systemene og enhetene dine, og dataene dine kan falle i hendene på angripere som kan selge, manipulere eller publisere dem. For bedrifter kan dette medføre alvorlige konsekvenser når det gjelder personvern for kundedata, tillit, konfidensialitet, salg og inntekter, i tillegg til risiko for manglende overholdelse av regelverk.
En rapport viser at over 40 % av globale bedriftsnettverk har opplevd angrep som følge av denne sårbarheten.
Selv om du ikke bruker sårbare Log4j-versjoner i dine egne applikasjoner, kan det hende at tredjepartsintegrasjoner gjør appen din sårbar for angrep.
Merk at alle Log4j-versjoner før Log4j 2.17.0 er berørt. Det er derfor nødvendig å oppgradere loggeren dersom den er i bruk. Kjente leverandører som er berørt av Log4j-sårbarheten, inkluderer Adobe, AWS, IBM, Cisco, VMware, Okta og Fortinet. Dersom du benytter deg av disse, er det viktig å overvåke applikasjonene kontinuerlig og iverksette sikkerhetstiltak for å løse eventuelle problemer umiddelbart.
Hvordan oppdage Log4j-berørte programmer og fikse problemene
Log4Shell-sårbarheten har en CVSS-poengsum på 10. Dette betyr at ikke alle problemer i Log4j er fullstendig løst ennå. Likevel er det en mulighet for at du eller en tredjepartsleverandør benytter Log4j i din applikasjon.
For å beskytte dine data, systemer og nettverk, må du følge en rekke utbedringstrinn.
#1. Oppdater din Log4j-versjon
Den mest effektive måten å beskytte dine enheter og applikasjoner mot Log4j-relaterte angrep, er å oppgradere til Log4j 2.17.1.
Log4Shell er en type null-dagsangrep som potensielt kan ramme hele programvareøkosystemet. Apache har utbedret enkelte sårbarheter i nyere versjoner, men dersom systemet ditt har blitt kompromittert før oppgraderingen, er det fortsatt en risiko.
Derfor er det viktig å ikke bare oppgradere versjonen, men også iverksette beredskapsprosedyrer umiddelbart for å sikre at det ikke finnes sårbarheter i systemene og applikasjonene dine. Dette inkluderer å gjennomgå alle serverlogger for å identifisere Indicators of Compromise (IOC) og kontinuerlig overvåke systemene og nettverket.
#2. Benytt de nyeste brannmurene og sikkerhetssystemene
Brannmurer, som Web Application Firewall (WAF) og neste generasjons brannmurer, kan bidra til å sikre nettverkets perimeter mot angripere ved å skanne innkommende og utgående datapakker og blokkere mistenkelige aktiviteter. Det er derfor viktig å implementere de nyeste brannmurene i nettverket ditt og sette strenge regler for utgående trafikk for å forhindre angrep i forbindelse med Log4j-sårbarheten.
Selv om angripere kan omgå brannmurer, vil de fortsatt gi en viss grad av beskyttelse ved å blokkere angripernes forespørsler.
Det er også viktig å oppdatere alle sikkerhetssystemer, som inntrengingsdeteksjonssystemer (IDS) og inntrengingsforebyggende systemer (IPS), med de nyeste signaturene og reglene. Disse systemene vil bidra til å blokkere eller filtrere RMI- og LDAP-trafikk fra å koble seg til en ondsinnet LDAP-server.
#3. Implementer MFA
Implementering av multifaktorautentisering (MFA) i applikasjonene og systemet ditt vil øke sikkerheten mot angripere. Det gir et ekstra sikkerhetslag selv om en angriper skulle klare å bryte det første. Du kan implementere MFA gjennom biometri som fingeravtrykk, irisskanning, sikkerhetsspørsmål eller sikkerhets-PIN.
MFA vil øke angriperens arbeidsmengde og tid som kreves for å utføre et angrep. Samtidig kan det gi deg rask varsling om hendelsen, slik at du kan iverksette nødvendige tiltak i tide.
Det er også viktig å bruke strenge VPN-retningslinjer for å redusere risikoen for datainnbrudd. Dette gir brukere sikker tilgang til systemene dine fra hvor som helst uten frykt for angripere.
#4. Endre systemegenskaper
Dersom du ikke kan oppgradere til den nyeste versjonen av Log4j-biblioteket, må du endre Java-systemegenskaper umiddelbart hvis du bruker en versjon mellom Log4j 2.10 og Log4j 2.14.1.
Du må konfigurere systemet for å forhindre oppslag som angripere benytter for å oppdage sårbarheten og utnytte den.
#5. Fjern JNDI
Årsaken til denne kritiske sikkerhetssårbarheten ligger i utformingen. JNDI Lookup-plugin har en designfeil som angripere kan utnytte til å utføre angrep.
JNDI brukes til å kjøre kode basert på logginformasjon, som enkelt kan manipuleres av hvem som helst siden loggeren aksepterer forespørsler uten verifisering.
Sikkerhetsforskere har funnet ut at denne plugin-en alltid har tillatt uparsede data siden lanseringen i 2013, og sender dem til Log4j-biblioteket.
Derfor er Log4j-sårbarheten sårbar for utnyttelse med en enkel strenginjeksjon. Når angriperen injiserer den, vil loggeren godta operasjonen i strengen og utføre den umiddelbart uten verifisering.
For å sikre dine systemer og applikasjoner, må du deaktivere JndiLookup-klassen. Dette vil hindre loggeren fra å iverksette tiltak basert på loggdata.
JNDI-oppslag er allerede deaktivert som standard i Log4j 2.16.0 for å bedre beskytte applikasjoner og systemer.
Dersom du bruker en Log4j-versjon eldre enn 2.16.0, må du sørge for at JNDI Lookup er deaktivert.
#6. Kommuniser med leverandørene dine
Selv om du har iverksatt alle nødvendige tiltak som brannmurer, sikkerhetssystemer, oppdatering av Log4j-versjonen og deaktivering av JNDI Lookup, bør du likevel være årvåken.
Selv om du ikke bruker en sårbar Log4j-versjon i dine egne applikasjoner, kan tredjepartsleverandører gjøre det. Du kan dermed ikke utelukke muligheten for et angrep via tredjepartsintegrasjoner.
Kommuniser derfor med dine leverandører og sørg for at de også har oppgradert Log4j til den nyeste versjonen og implementert de sikkerhetstiltakene som er nevnt ovenfor.
#7. Bruk en Log4j Vulnerability Scanner
Det finnes et bredt utvalg av Log4j-sårbarhetsskannere på markedet som forenkler prosessen med å oppdage Log4j-sårbarheter i dine systemer og applikasjoner.
Når du ser etter et slikt verktøy, bør du undersøke nøyaktigheten da mange av dem kan generere falske positiver. Det er også viktig å velge et verktøy som oppfyller dine spesifikke behov, ettersom de kan fokusere på identifisering, rapportering og utbedring av sårbarheter.
Dersom du primært er ute etter gjenkjenning, bør du velge en skanner som kan oppdage problemet, eller et verktøy som både kan identifisere og rette opp problemet.
Noen av de mest anerkjente Log4j-skanneverktøyene er:
- Microsoft 365 Defender: Microsoft tilbyr en rekke sikkerhetsløsninger og verktøy for å hjelpe deg med å oppdage og forhindre Log4j-utnyttelser i nettverket ditt. Disse verktøyene gjør det mulig å identifisere fjernstyrt kodeutførelse og forsøk på utnyttelse, og beskytte Windows- og Linux-enheter mot Log4j-sårbarheter.
- Amazon Inspector og AWS: Amazon har utviklet et skanneverktøy for å identifisere Log4j-sårbarheter i Amazon EC2-forekomster og Amazon ECR.
- CloudStrike Archive Scan Tool (CAST): CloudStrike har også utviklet et skanneverktøy for å oppdage Log4j-sårbarheter og hjelpe med å løse problemer i tide før angripere kan utnytte dem.
- Google Cloud Logging-deteksjon: Googles løsning for deteksjon via sky-logging lar deg oppdage Log4j-utnyttelser ved å bruke Logs Explorer. Verktøyet gir deg mulighet til å opprette en loggspørring og skanne for potensielle utnyttelsesstrenger.
- Google har også utviklet log4jscanner, en åpen kildekode-filsystemskanner for å oppdage Log4j-sårbarheter.
- BurpSuite Log4j Scanner: Dette er en sikkerhetsplugin for profesjonelle og bedrifter for å hjelpe dem med å oppdage Log4j-sårbarheter.
- Huntress Log4Shell Vulnerability Tester: Dette verktøyet genererer en tilfeldig, unik identifikator som kan brukes under testing av inndatafelter. Ved å identifisere en sårbarhet i applikasjonen eller inndatafeltet, vil den sikre LDAP-serveren avslutte den skadelige tilkoblingen umiddelbart og ivareta sikkerheten.
- WhiteSource Log4j Detect: WhiteSource har utviklet et gratis CLI-verktøy, WhiteSource Log4j Detect, som er tilgjengelig på GitHub, for å hjelpe med å oppdage og fikse Log4j-sårbarheter – CVE-2021-445046 og CVE-2021-44228.
- JFrog Open-Source skanneverktøy for Log4j: JFrog har utviklet ulike åpen kildekode-løsninger og verktøy for å finne Log4j-sårbarheter i binærfiler og kildekode.
Konklusjon
Log4j-sårbarheten er en kritisk sikkerhetsutfordring. Det utbredte bruken av dette loggbiblioteket i et bredt spekter av applikasjoner og systemer har ført til at Log4j-sårbarheten har blitt svært utbredt. Dette gir angripere muligheten til å utnytte et stort antall systemer og applikasjoner.
For å beskytte dine systemer og applikasjoner mot denne sikkerhetstrusselen, er det viktig å oppgradere Log4j-biblioteket til den nyeste versjonen og implementere de sikkerhetsrutinene som er nevnt ovenfor.