Log4j-sårbarhet er blant de dødeligste sikkerhetsproblemene i moderne systemer.
Logging er en nøkkelfunksjon i moderne applikasjoner, og loggbiblioteket, Log4j, er ledende på dette området.
Dette biblioteket brukes i de fleste applikasjoner, tjenester og systemer. Derfor er alle applikasjonene der Log4j brukes alle påvirket av denne Log4j-sårbarheten som ble funnet i fjor.
Med økende bekymringer for cybersikkerhet over hele verden, tar organisasjoner og enkeltpersoner skritt for å beskytte sine applikasjoner, systemer og data.
Og da denne sårbarheten ble oppdaget, stresset den fagfolk og bedrifter enda mer.
Derfor er det viktig å oppdage Log4j-sårbarheten og fikse den hvis du ønsker å beskytte dataene dine, nettverket, omdømmet og kundenes tillit.
I denne artikkelen vil jeg diskutere hva Log4j-sårbarhet er, sammen med trinnene for å oppdage og fikse det.
La oss starte med å forstå Log4j og hvorfor du trenger det.
Innholdsfortegnelse
Hva er Log4j?
Log4j er et åpen kildekode-loggingsverktøy skrevet i Java som hovedsakelig brukes til å lagre, formatere og publisere loggoppføringer generert av applikasjoner og systemer og deretter se etter feil. Postene kan være av ulike typer, fra en nettside og nettleserdata til et systems tekniske detaljer der Log4j kjører.
I stedet for å skrive kode fra bunnen av, kan utviklere bruke Log4j-biblioteket ved å integrere koden i appene deres.
Ved å bruke Log4j kan utviklere spore alle hendelsene knyttet til applikasjonene deres med nøyaktig logginformasjon. Det hjelper dem med å overvåke applikasjoner, oppdage problemer i tide og fikse problemer før de kan bli et større problem når det gjelder ytelse og/eller sikkerhet.
Dette Java-baserte biblioteket ble skrevet av Ceki Gülcü og ble utgitt i 2001 under Apache License 2.0. Den bruker Java-navne- og kataloggrensesnitt (JNDI)-tjenester for å tillate apper å samhandle med andre apper som LDAP, DNS, CORBA, etc., og få en katalog og navnefunksjonalitet for Java-baserte applikasjoner. Log4j har tre komponenter for å utføre sine oppgaver:
- Loggere for å fange loggoppføringer
- Oppsett for å formatere loggposter i forskjellige stiler
- Vedlegg for å publisere loggoppføringer til forskjellige destinasjoner
Log4j er faktisk et av de mest kjente loggbibliotekene på nettet og brukes av organisasjoner fra flere bransjer og land. De har integrert dette loggbiblioteket i mange applikasjoner, inkludert topp skytjenester fra Google, Microsoft, Apple, Cloudflare, Twitter, etc.
Utvikleren, Apache Software Foundation, utviklet Log4j 2, en oppgradering til Log4j for å løse problemene som ble funnet i de tidligere utgivelsene. I fjor ble det funnet en sårbarhet i Log4j, som, når den ikke blir adressert, kan tillate angripere å bryte seg inn i applikasjoner og systemer, stjele data, infisere et nettverk og utføre andre ondsinnede aktiviteter.
La oss forstå det mer.
Hva er Log4Shell – Log4j-sårbarheten?
Log4Shell er en kritisk cybersikkerhetssårbarhet på Log4j-biblioteket, som påvirker kjernefunksjonen til biblioteket. Den lar en angriper kontrollere en Internett-tilkoblet enhet eller applikasjon ved å utføre ekstern kjøring av kode. Når de lykkes med det, kan de:
- Kjør hvilken som helst kode på enheten eller systemet
- Få tilgang til alle nettverk og data
- Endre eller krypter enhver fil på den berørte appen eller enheten
Denne sårbarheten ble først rapportert 24. november 2021 av Chen Zhaojun, en sikkerhetsforsker hos Alibaba (en kinesisk e-handelsgigant). Sårbarheten påvirket Minecraft-serverne deres, som Alibabas skysikkerhetsteam oppdaget 9. desember.
Deretter publiserte NIST dette sikkerhetsproblemet i National Vulnerability Database og kalte det CVE-2021-44228. Apache Software Foundation vurderte deretter dette sikkerhetsproblemet til 10 i CVSS-alvorlighetsgrad. Dette er sjelden tildelt og er svært alvorlig siden det har potensialet til å bli utnyttet bredt og enkelt, noe som fører til massiv skade for organisasjoner og enkeltpersoner.
Apache, som svar, utstedte en oppdatering for denne sårbarheten, men likevel ble noen deler ikke adressert, noe som førte til andre sårbarheter:
- CVE-2021-45046 som muliggjorde Denial of Service (DoS)-angrep gjennom JNDI-oppslag
- CVE-2021-45105 for å tillate hackere å kontrollere trådkontekstkartinformasjon og forårsake DoS-angrep ved å tolke en laget streng
- CVE-2021-44832 påvirker alle Log4j 2-versjoner via Remote Code Injection (RCE)
Hvordan fungerer Log4Shell?
For å forstå alvorlighetsgraden og hvor mye skade Log4Shell kan gjøre, er det relevant å lære hvordan denne Log4j-sårbarheten fungerer.
Log4Shell-sårbarhet lar en angriper eksternt injisere hvilken som helst vilkårlig kode i et nettverk og få full kontroll over den.
Denne nettangrepssekvensen starter med loggingsbiblioteket, for eksempel Log4j, som samler inn og lagrer logginformasjon. Hvis det ikke er noe loggbibliotek, vil alle data fra serveren bli arkivert umiddelbart etter at dataene er samlet inn.
Men hvis du ønsker å analysere disse dataene eller trenger å gjøre noen handlinger basert på spesifikk logginformasjon, vil du kreve et loggbibliotek for å analysere loggdata før de arkiveres.
På grunn av Log4j-sårbarheten, blir alle systemer eller apper som bruker Log4j sårbare for nettangrep. Loggbiblioteket kjører kode basert på inndata. En hacker kan tvinge loggbiblioteket til å kjøre skadelig kode siden sårbarheten vil tillate dem å manipulere inndataene.
I mellomtiden skjer det mye i bakgrunnen. Når Log4j sendes en spesifikt laget streng, vil den påkalle en LDP-server og laste ned den koden som ligger i katalogen for å utføre koden. På denne måten kan angripere opprette en LDAP-server for å lagre ondsinnet kode som kan hjelpe dem med å kontrollere enhver server der koden kjøres. Den vil da sende en streng som dirigerer den ondsinnede koden deres til en målrettet app eller system og ta full kontroll over den.
Så dette er hvordan Log4j-sårbarheten kan utnyttes:
- En angriper finner en server med en sårbar Log4j-versjon.
- De vil sende den målrettede serveren en get-forespørsel med sin ondsinnede LDAP-servers kobling.
- Målserveren vil, i stedet for å bekrefte forespørselen, koble seg direkte til denne LDAP-serveren.
- Angriperne vil nå sende målserveren med et LDAP-serversvar som inneholder ondsinnet kode. På grunn av Log4js sårbarhet, som gjør det mulig å motta koden og utføre den uten verifisering, kan hackeren utnytte denne svakheten til å bryte seg inn på målserveren og utnytte tilkoblede systemer, nettverk og enheter.
Hvordan kan Log4j-sårbarhet skade brukere?
Log4j-sårbarheten er bekymringsfull siden den brukes i et bredt spekter av programvareapplikasjoner og systemer.
Siden logging er en essensiell funksjon i de fleste programvareapper og Log4j er en ledende løsning i verdensrommet, finner Log4j applikasjoner i en rekke programvaresystemer.
Noen av de populære tjenestene og appene som bruker Log4j er Minecraft, AWS, iCloud, Microsoft, Twitter, Internett-rutere, programvareutviklingsverktøy, sikkerhetsverktøy og så videre. Derfor kan angripere målrette mot et stort antall applikasjoner, tjenester og systemer fra hjemmebrukere, kodeutviklere, tjenesteleverandører og andre relaterte fagpersoner og enkeltpersoner.
I tillegg er Log4j-sårbarheten ekstremt enkel å utnytte for en angriper. Den generelle prosessen krever færre ferdighetssett, ikke ekspertnivå, for å utføre et angrep. Dette er grunnen til at antallet angrep som utnytter denne sårbarheten øker.
Virkningen av Log4j-sårbarheten er:
- DoS-angrep
- Supply chain angrep
- Myntgruvedrift
- Injeksjoner av skadelig programvare som løsepengevare og trojanske hester
- Vilkårlig kodeinjeksjon
- Ekstern kjøring av kode
Og mer.
Som et resultat av disse angrepene kan du miste grepet om applikasjonene, systemene og enhetene dine, og dataene dine kan bli offer for angriperne som kan selge dataene dine, manipulere dem eller utsette dem for omverdenen. Derfor kan bedriften din bli skadet når det gjelder personvern for kundedata, tillit, organisasjonens hemmeligheter, og til og med salg og inntekter, enn si overholdelsesrisikoen.
Ifølge en rapporthar over 40 % av globale bedriftsnettverk opplevd angrep på grunn av denne sårbarheten.
Så selv om du ikke bruker noen sårbare Log4j-versjoner i applikasjonene dine, kan det hende at tredjepartsintegrasjonene bruker den, noe som gjør appen din sårbar for angrep.
Merk at alle Log4j-versjoner før Log4j 2.17.0. er påvirket; derfor må du oppgradere loggeren hvis du bruker den. Også kjente leverandører som er berørt av denne Log4j-sårbarheten er Adobe, AWS, IBM, Cisco, VMware, Okta, Fortinet, etc. Hvis du bruker noen av dem, overvåk appene dine kontinuerlig og bruk sikkerhetssystemer for å fikse problemer så snart det skjer. oppstår.
Hvordan oppdage Log4j-berørte programmer og fikse problemene
Log4Shell-sårbarheten har 10 i CVSS-poengsummen. Derfor er ikke alle problemene i Log4j korrigert ennå. Men det er en sjanse for at du eller din tredjepartsleverandør kan bruke Log4j, som du har brukt i applikasjonen din.
Derfor, hvis du vil beskytte data, systemer og nettverk, må du følge noen utbedringstrinn.
#1. Oppdater din Log4j-versjon
Å oppdatere din nåværende Log4j-versjon til Log 4j 2.17.1 er den mest effektive utbedringsteknikken hvis du ønsker å beskytte enheten og appene dine mot angrep som følge av Log4j-sårbarheten.
Log4Shell er en type nulldagers angrep som potensielt kan påvirke programvareøkosystemet ditt. Apache har fikset noen av sårbarhetene i nyere versjoner, men hvis systemet ditt ble kompromittert før oppgraderingen, er du fortsatt i faresonen.
Derfor, forutsatt at dette, må du ikke bare oppgradere versjonen, men også starte hendelsesprosedyrene umiddelbart for å sikre at ingen sårbarheter er der i systemene og appene dine og redusere angrepene. Du må også gå gjennom alle serverloggene dine for å finne Indicators of Compromise (IOC) og kontinuerlig overvåke systemene og nettverket.
#2. Bruk de nyeste brannmurene og sikkerhetssystemene
Brannmurer som Web Application Firewall (WAF) og neste generasjons brannmurer kan bidra til å sikre nettverkets perimeter fra angripere ved å skanne innkommende og utgående datapakker og blokkere mistenkelige. Så bruk de nyeste brannmurene i nettverket ditt og sett strenge utgående regler på serverne dine for å forhindre angrep assosiert med Log4j-sårbarhet.
Selv om angripere kan omgå brannmurer, vil du fortsatt få en viss grad av sikkerhet med brannmurer som kan blokkere en angripers forespørsler.
I tillegg oppdaterer du alle sikkerhetssystemene dine, slik som inntrengningsdeteksjonssystemer (IDS), inntrengningsforebyggende systemer (IPS), etc., med de nyeste signaturene og reglene. Disse systemene vil hjelpe med å blokkere eller filtrere RMI- og LDAP-trafikk fra å koble til en ondsinnet LDAP-server.
#3. Implementere MFA
Å sette opp multifaktorautentisering (MFA) i applikasjonene og systemet vil gi bedre sikkerhet fra angripere. Det vil gi et andre lag med sikkerhet selv om en angriper klarer å bryte det første laget. Du kan gjøre det gjennom biometri som fingeravtrykk, irisskanning osv., stille inn et sikkerhetsspørsmål eller aktivere en sikkerhets-PIN.
Bruk av MFA vil øke angripernes vanskeligheter og tid til å utføre et fullverdig angrep. I mellomtiden kan den også informere deg om hendelsen umiddelbart, slik at du kan ta nødvendige utbedringsgrep når du fortsatt har tid.
I tillegg må du også bruke strenge VPN-policyer for å redusere datainnbrudd. Dette vil gjøre det mulig for brukere å få tilgang til systemene dine sikkert fra hvor som helst uten frykt for angripere.
#4. Endre systemegenskaper
I tilfelle du ikke kan oppgradere til den nyeste versjonen av Log4j-biblioteket, må du endre Java-systemegenskaper umiddelbart hvis du bruker en versjon som strekker seg fra Log4j 2.10 til Log4j 2.14.1.
Du må sette den på en slik måte å forhindre oppslag som angripere bruker for å oppdage sårbarhetene og deretter finne måter å utnytte dem på.
#5. Fjern JNDI
Årsaken til dette kritiske sikkerhetssårbarheten ligger i utformingen. JNDI Lookup-plugin har en designfeil som angripere kan utføre et angrep gjennom.
JNDI brukes til kodekjøring basert på inndataene i loggen, som alle kan manipulere enkelt siden loggeren aksepterer enhver forespørsel uten bekreftelse.
Sikkerhetsforskere har funnet ut at denne plugin-en alltid har tillatt uparsede data siden den ble utgitt i 2013 og sender den til Log4j-biblioteket.
Derfor er Log4j-sårbarheten utsatt for utnyttelse med en enkel strenginjeksjon. Når angriperen injiserer det, vil loggeren godta operasjonen som er forespurt i strengen og utføre den umiddelbart uten bekreftelse.
Så hvis du vil sikre systemene og applikasjonen din, må du deaktivere klassen – JndiLookup. Dette vil hindre loggeren fra å iverksette tiltak basert på loggdata.
Faktisk er JNDI-oppslag allerede deaktivert i Log4j 2.16.0 som standard i et forsøk på å sikre applikasjonene og systemene dine.
Så hvis du bruker en Log4j-versjon lavere enn 2.16.0, sørg for at du har deaktivert JNDI Lookup.
#6. Snakk med leverandørene dine
Hvis du har fått alt riktig, brannmurer og sikkerhetssystemer oppdatert, Log4j-versjon oppdatert, JNDI Lookup deaktivert, etc., ikke slapp av ennå.
Selv om du ikke bruker en sårbar Log4j-versjon i applikasjonene dine, kan det hende at tredjepartsleverandørene bruker den. Så du vil aldri vite hvordan applikasjonen eller systemet ble hacket fordi det virkelige problemet var tredjepartsintegrasjonen din.
Snakk derfor med leverandørene dine og sørg for at de også har oppgradert Log4j til den nyeste versjonen og implementert annen sikkerhetspraksis diskutert ovenfor.
#7. Bruk en Log4j Vulnerability Scanner
Det er mange Log4j-sårbarhetsskanneverktøy tilgjengelig på markedet for å gjøre det enkelt for deg å oppdage Log4j-sårbarheter i systemene og applikasjonene dine.
Så når du ser etter disse verktøyene, sjekk nøyaktighetsgradene deres siden mange av dem genererer falske positiver. Finn også et verktøy som kan imøtekomme dine behov fordi de kan fokusere på å identifisere Log4j-sårbarhet, rapportere eksponeringen og utbedre sårbarheten.
Så hvis fokuset ditt er gjenkjenning, finn en Log4j sårbarhetsskanner som kan oppdage problemet eller bruk den som kan oppdage og rette opp problemet.
Noen av de beste 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. Du vil kunne oppdage ekstern kjøring av kode og utnyttelsesforsøk, og beskytte deg mot Log4j-sårbarheter i Windows- og Linux-enheter.
- Amazon Inspector og AWS: Amazon har laget et skanneverktøy for å finne Log4j-sårbarhet i Amazon EC2-forekomster og Amazon ECR.
- CloudStrike Archive Scan Tool (CAST): CloudStrike har også laget et utmerket skanneverktøy for å oppdage Log4j-sårbarhet for å hjelpe deg med å fikse problemer i tide før angripere kan utnytte det.
- Google Cloud Logging-deteksjon: Googles cloud-logging-deteksjonsløsning lar deg oppdage Log4j-utnyttelser ved å bruke Logs Explorer. Du kan opprette en loggspørring i dette verktøyet og skanne etter potensielle utnyttelsesstrenger.
- Google har også laget log4jscanner, en åpen kildekode-filsystemskanner for å oppdage Log4j-sårbarhet.
- BurpSuite Log4j Scanner: Dette er en sikkerhetsplugin for profesjonelle og bedrifter for å hjelpe dem med å oppdage Log4j-sårbarhet.
- Huntress Log4Shell Vulnerability Tester: Dette verktøyet genererer en unik identifikator tilfeldig som du kan bruke mens du tester inndatafeltene dine. Ved å finne en sårbarhet i applikasjonen eller inndatafeltet, vil dens sikre LDAP-server avslutte den skadelige tilkoblingen umiddelbart og holde deg trygg.
- WhiteSource Log4j Detect: WhiteSource har laget et gratis CLI-verktøy, WhiteSource Log4j Detect, hostet på GitHub for å hjelpe deg med å oppdage og fikse Log4j-sårbarheter – CVE-2021-445046 og CVE-2021-44228.
- JFrog Open-Source skanneverktøy for Log4j: JFrog har laget ulike åpen kildekode-løsninger og verktøy for å finne Log4j-sårbarheter i binærfiler og kildekode.
Konklusjon
Log4j-sårbarhet er et kritisk sikkerhetsproblem. Siden dette loggingsbiblioteket brukes mye i ulike applikasjoner og systemer, har Log4j-sårbarheten blitt utbredt, og lar angripere utnytte et bredt spekter av systemer og apper.
Så hvis du ønsker å beskytte systemene og applikasjonene dine mot dette sikkerhetsproblemet, sørg for at du oppgraderer Log4j-biblioteket til den nyeste versjonen og implementerer de beste sikkerhetspraksisene diskutert ovenfor.