Log4j-sårbarhed er blandt de mest dødbringende sikkerhedsproblemer i moderne systemer.
Logning er en nøglefunktion i moderne applikationer, og logbiblioteket, Log4j, er førende på dette område.
Dette bibliotek bruges i de fleste applikationer, tjenester og systemer. Derfor er alle de applikationer, hvor Log4j bruges, alle påvirket af denne Log4j-sårbarhed, der blev fundet sidste år.
Med stigende cybersikkerhedsproblemer verden over tager organisationer og enkeltpersoner skridt til at beskytte deres applikationer, systemer og data.
Og da denne sårbarhed blev opdaget, stressede det fagfolk og virksomheder endnu mere.
Derfor er det vigtigt at opdage Log4j-sårbarheden og rette den, hvis du vil beskytte dine data, netværk, omdømme og kundetillid.
I denne artikel vil jeg diskutere, hvad Log4j sårbarhed er, sammen med trinene til at opdage og rette det.
Lad os starte med at forstå Log4j og hvorfor du har brug for det.
Indholdsfortegnelse
Hvad er Log4j?
Log4j er et open source-logningsværktøj skrevet i Java, der hovedsageligt bruges til at gemme, formatere og udgive logføringsposter genereret af applikationer og systemer og derefter kontrollere for fejl. Registreringerne kan være af forskellige typer, lige fra en webside og browserdata til et systems tekniske detaljer, hvor Log4j kører.
I stedet for at skrive kode fra bunden, kan udviklere bruge Log4j-biblioteket ved at integrere dets kode i deres apps.
Ved hjælp af Log4j kan udviklere spore alle hændelser forbundet med deres applikationer med nøjagtige logningsoplysninger. Det hjælper dem med at overvåge applikationer, spotte problemer til tiden og løse problemer, før de kan blive til et større problem med hensyn til ydeevne og/eller sikkerhed.
Dette Java-baserede bibliotek blev skrevet af Ceki Gülcü og blev udgivet i 2001 under Apache License 2.0. Den bruger Java-navngivning og Directory Interface (JNDI)-tjenester til at tillade apps at interagere med andre apps som LDAP, DNS, CORBA osv., og få en mappe og navngivningsfunktionalitet til Java-baserede applikationer. Log4j har tre komponenter til at udføre sine opgaver:
- Loggere til at fange logningsposter
- Layouts til at formatere logregistreringer i forskellige stilarter
- Bilag til udgivelse af logningsposter til forskellige destinationer
Log4j er faktisk et af de mest berømte logbiblioteker på nettet og bruges af organisationer fra flere brancher og lande. De har integreret dette logbibliotek i masser af applikationer, inklusive topskytjenester fra Google, Microsoft, Apple, Cloudflare, Twitter osv.
Dets udvikler, Apache Software Foundation, udviklede Log4j 2, en opgradering til Log4j for at løse problemerne i de tidligere udgivelser. Sidste år blev der fundet en sårbarhed i Log4j, som, når den ikke adresseres, kan tillade angribere at bryde ind i applikationer og systemer, stjæle data, inficere et netværk og udføre andre ondsindede aktiviteter.
Lad os forstå det mere.
Hvad er Log4Shell – Log4j-sårbarheden?
Log4Shell er en kritisk cybersikkerhedssårbarhed på Log4j-biblioteket, som påvirker bibliotekets kernefunktion. Det giver en hacker mulighed for at kontrollere en internetforbundet enhed eller applikation ved at udføre fjernudførelse af kode. Når de har succes med det, kan de:
- Kør enhver kode på enheden eller systemet
- Få adgang til alle netværk og data
- Rediger eller krypter enhver fil på den berørte app eller enhed
Denne sårbarhed blev første gang rapporteret den 24. november 2021 af Chen Zhaojun, en sikkerhedsforsker hos Alibaba (en kinesisk e-handelsgigant). Sårbarheden påvirkede deres Minecraft-servere, som Alibabas cloud-sikkerhedsteam opdagede den 9. december.
Dernæst offentliggjorde NIST denne sårbarhed i den nationale sårbarhedsdatabasen og kaldte den CVE-2021-44228. Apache Software Foundation vurderede derefter denne sårbarhed til 10 i CVSS-alvorlighed. Dette er sjældent tildelt og er meget alvorligt, da det har potentialet til at blive udnyttet bredt og nemt, hvilket fører til massiv skade for organisationer og enkeltpersoner.
Apache udsendte som svar en patch til denne sårbarhed, men nogle dele blev stadig efterladt uadressert, hvilket førte til andre sårbarheder:
- CVE-2021-45046, der lettede Denial of Service (DoS)-angreb gennem JNDI-opslag
- CVE-2021-45105 for at give hackere mulighed for at kontrollere trådkontekstkortoplysninger og forårsage DoS-angreb ved at fortolke en udformet streng
- CVE-2021-44832 påvirker alle Log4j 2-versioner via Remote Code Injection (RCE)
Hvordan virker Log4Shell?
For at forstå dens alvor og hvor meget skade Log4Shell kan gøre, er det relevant at lære, hvordan denne Log4j-sårbarhed fungerer.
Log4Shell-sårbarheden lader en angriber eksternt injicere enhver vilkårlig kode i et netværk og få fuldstændig kontrol over det.
Denne cyberangrebssekvens starter med logningsbiblioteket, såsom Log4j, der indsamler og lagrer loginformation. Hvis der ikke er noget logningsbibliotek, vil alle data fra serveren blive arkiveret med det samme, efter at dataene er indsamlet.
Men hvis du vil analysere disse data eller har brug for at udføre nogle handlinger baseret på specifikke logoplysninger, skal du kræve et logbibliotek for at parse logdata, før det arkiveres.
På grund af Log4j-sårbarheden bliver ethvert system eller app, der bruger Log4j, sårbart over for cyberangreb. Logningsbiblioteket udfører kode baseret på inputtet. En hacker kan tvinge logbiblioteket til at udføre skadelig kode, da sårbarheden vil give dem mulighed for at manipulere inputtet.
Imens sker der en masse ting i baggrunden. Når Log4j videregives en specifikt udformet streng, vil den kalde en LDP-server og downloade den kode, der er hostet i dens mappe for at udføre koden. På denne måde kan angribere oprette en LDAP-server til at gemme ondsindet kode, der kan hjælpe dem med at kontrollere enhver server, hvor koden udføres. Det vil derefter sende en streng, der dirigerer deres ondsindede kode til en målrettet app eller system og tage fuld kontrol over det.
Så det er sådan Log4j sårbarhed kan udnyttes:
- En angriber finder en server med en sårbar Log4j-version.
- De vil sende den målrettede server en get-anmodning med deres ondsindede LDAP-servers link.
- Den målrettede server vil i stedet for at bekræfte anmodningen oprette direkte forbindelse til denne LDAP-server.
- Angriberne vil nu sende den målrettede server med et LDAP-serversvar, der indeholder skadelig kode. På grund af Log4js sårbarhed, som gør det muligt at modtage koden og udføre den uden verifikation, kan hackeren udnytte denne svaghed til at bryde ind på målserveren og udnytte tilsluttede systemer, netværk og enheder.
Hvordan kan Log4j-sårbarhed skade brugere?
Log4j sårbarhed er bekymrende, da den bruges i en bred vifte af softwareapplikationer og systemer.
Da logning er en væsentlig funktion i de fleste software-apps, og Log4j er en førende løsning i rummet, finder Log4j applikationer i en række forskellige softwaresystemer.
Nogle af de populære tjenester og apps, der bruger Log4j, er Minecraft, AWS, iCloud, Microsoft, Twitter, internetroutere, softwareudviklingsværktøjer, sikkerhedsværktøjer og så videre. Derfor kan angribere målrette mod et stort antal applikationer, tjenester og systemer fra hjemmebrugere, kodeudviklere, tjenesteudbydere og andre relaterede fagfolk og enkeltpersoner.
Derudover er Log4j-sårbarheden ekstremt nem at udnytte for en angriber. Den overordnede proces kræver færre færdighedssæt, ikke ekspertniveau, for at udføre et angreb. Det er grunden til, at antallet af angreb, der udnytter denne sårbarhed, er stigende.
Virkningen af Log4j sårbarhed er:
- DoS-angreb
- Supply chain angreb
- Møntudvinding
- Malware-injektioner såsom ransomware og trojanske heste
- Vilkårlig kodeindsprøjtning
- Fjernudførelse af kode
Og mere.
Som et resultat af disse angreb kan du miste fat i dine applikationer, systemer og enheder, og dine data kan blive ofre for angriberne, som kan sælge dine data, manipulere dem eller udsætte dem for omverdenen. Derfor kan din virksomhed blive skadet med hensyn til kundedatabeskyttelse, tillid, organisationens hemmeligheder og endda dit salg og indtjening, endsige overholdelsesrisici.
Ifølge en rapporthar over 40 % af globale virksomhedsnetværk oplevet angreb på grund af denne sårbarhed.
Så selvom du ikke bruger nogen sårbare Log4j-versioner i dine applikationer, kan dine tredjepartsintegrationer bruge det, hvilket gør din app sårbar over for angreb.
Bemærk, at alle Log4j-versioner før Log4j 2.17.0. er påvirket; derfor skal du opgradere loggeren, hvis du bruger den. Også kendte leverandører, der er påvirket af denne Log4j-sårbarhed, er Adobe, AWS, IBM, Cisco, VMware, Okta, Fortinet osv. Hvis du bruger nogen af dem, skal du overvåge dine apps løbende og bruge sikkerhedssystemer til at løse problemer, så snart det er tilfældet. opstår.
Sådan registrerer du Log4j-berørte programmer og løser problemerne
Log4Shell sårbarhed har en 10 i CVSS-score. Derfor er alle problemerne i Log4j ikke rettet endnu. Men det er en chance for, at du eller din tredjepartsleverandør bruger Log4j, som du har brugt i din applikation.
Derfor, hvis du vil beskytte dine data, systemer og netværk, skal du sørge for at følge nogle afhjælpningstrin.
#1. Opdater din Log4j-version
At opdatere din nuværende Log4j-version til Log 4j 2.17.1 er den mest effektive afhjælpningsteknik, hvis du vil beskytte din enhed og apps mod angreb som følge af Log4j-sårbarheden.
Log4Shell er en type nul-dages angreb, der potentielt kan påvirke dit software-økosystem. Apache har rettet nogle af sårbarhederne i de seneste versioner, men hvis dit system blev kompromitteret før opgraderingen, er du stadig i fare.
Hvis du antager dette, skal du derfor ikke kun opgradere versionen, men også starte dine hændelsesprocedurer med det samme for at sikre, at der ikke er nogen sårbarheder i dine systemer og apps og afbøde angrebene. Du skal også gennemgå alle dine serverlogfiler for at finde Indicators of Compromise (IOC) og konstant overvåge dine systemer og netværk.
#2. Brug de nyeste firewalls og sikkerhedssystemer
Firewalls såsom Web Application Firewall (WAF) og næste generations firewalls kan hjælpe med at sikre dit netværks perimeter mod angribere ved at scanne indgående og udgående datapakker og blokere mistænkelige. Så brug de nyeste firewalls i dit netværk og sæt strenge udgående regler på dine servere for at hjælpe med at forhindre angreb forbundet med Log4j-sårbarhed.
Selvom angribere kan omgå firewalls, vil du stadig få en vis grad af sikkerhed med firewalls, der kan blokere en angribers anmodninger.
Derudover skal du opdatere alle dine sikkerhedssystemer, såsom Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) osv., med de nyeste signaturer og regler. Disse systemer hjælper med at blokere eller filtrere RMI- og LDAP-trafik fra at oprette forbindelse til en ondsindet LDAP-server.
#3. Implementere MFA
Opsætning af multi-factor authentication (MFA) i dine applikationer og system vil give bedre sikkerhed fra angribere. Det vil give et andet lag af sikkerhed, selvom en angriber formår at bryde det første lag. Du kan gøre det gennem biometri som fingeraftryk, irisscanning osv., indstille et sikkerhedsspørgsmål eller aktivere en sikkerhedspinkode.
Brug af MFA vil øge angribernes sværhedsgrad og tid til at udføre et komplet angreb. I mellemtiden kan den også informere dig om hændelsen med det samme, så du kan tage nødvendige afhjælpende skridt, når du stadig har tid.
Derudover skal du også anvende strenge VPN-politikker for at reducere databrud. Dette vil gøre det muligt for brugerne at få adgang til dine systemer sikkert fra hvor som helst uden frygt for angribere.
#4. Skift systemegenskaber
Hvis du ikke kan opgradere til den nyeste version af Log4j-biblioteket, skal du ændre dine java-systemegenskaber med det samme, hvis du bruger en version, der spænder fra Log4j 2.10 til Log4j 2.14.1.
Du skal indstille det på en sådan måde at forhindre opslag, som angribere bruger til at opdage sårbarhederne og derefter finde måder at udnytte dem på.
#5. Fjern JNDI
Årsagen til denne kritiske sikkerhedssårbarhed ligger i dens design. JNDI Lookup plugin har en designfejl, hvorigennem angribere kan udføre et angreb.
JNDI bruges til kodeudførelse baseret på inputdataene i sin log, som enhver let kan manipulere, da loggeren accepterer enhver anmodning uden verifikation.
Sikkerhedsforskere har fundet ud af, at dette plugin altid har tilladt ikke-parserede data, siden det blev frigivet i 2013 og sender det til Log4j-biblioteket.
Derfor er Log4j-sårbarheden tilbøjelig til at blive udnyttet med en simpel strenginjektion. Når først angriberen injicerer det, vil loggeren acceptere den handling, der anmodes om i strengen og udføre den øjeblikkeligt uden verifikation.
Så hvis du vil sikre dine systemer og applikation, skal du deaktivere klassen – JndiLookup. Dette forhindrer loggeren i at foretage handling baseret på logdata.
Faktisk er JNDI-opslag allerede deaktiveret i Log4j 2.16.0 som standard i et forsøg på at sikre dine applikationer og systemer.
Så hvis du bruger en Log4j-version, der er lavere end 2.16.0, skal du sikre dig, at du har deaktiveret JNDI-opslag.
#6. Tal med dine leverandører
Hvis du har fået alt rigtigt, dine firewalls og sikkerhedssystemer opdateret, Log4j-version opdateret, JNDI Lookup deaktiveret osv., så slap ikke af endnu.
Selvom du ikke bruger en sårbar Log4j-version i dine applikationer, kan dine tredjepartsleverandører bruge den. Så du vil aldrig vide, hvordan din applikation eller dit system blev hacket, fordi det virkelige problem var din tredjepartsintegration.
Tal derfor med dine leverandører og sørg for, at de også har opgraderet Log4j til den nyeste version og implementeret andre sikkerhedsforanstaltninger, der er beskrevet ovenfor.
#7. Brug en Log4j Vulnerability Scanner
Der er mange Log4j sårbarhedsscanningsværktøjer tilgængelige på markedet for at gøre det nemt for dig at opdage Log4j sårbarheder i dine systemer og applikationer.
Så når du leder efter disse værktøjer, skal du kontrollere deres nøjagtighed, da mange af dem genererer falske positiver. Find også et værktøj, der kan imødekomme dine behov, fordi de kan fokusere på at identificere Log4j-sårbarhed, rapportere eksponeringen og afhjælpe sårbarheden.
Så hvis dit fokus er påvisning, skal du finde en Log4j sårbarhedsscanner, der kan opdage problemet, eller brug den, der kan opdage og afhjælpe problemet.
Nogle af de bedste Log4j-scanningsværktøjer er:
- Microsoft 365 Defender: Microsoft tilbyder en række sikkerhedsløsninger og værktøjer til at hjælpe dig med at opdage og forhindre Log4j-udnyttelse i dit netværk. Du vil være i stand til at spotte fjernudførelse af kode og udnyttelsesforsøg, hvilket beskytter dig mod Log4j-sårbarheder i Windows- og Linux-enheder.
- Amazon Inspector og AWS: Amazon har lavet et scanningsværktøj til at finde Log4j-sårbarhed i Amazon EC2-instanser og Amazon ECR.
- CloudStrike Archive Scan Tool (CAST): CloudStrike har også skabt et fremragende scanningsværktøj til at opdage Log4j-sårbarhed for at hjælpe dig med at løse problemer i tide, før angribere kan udnytte det.
- Registrering af Google Cloud-logning: Googles løsning til registrering af cloud-logning giver dig mulighed for at opdage Log4j-udnyttelse ved hjælp af Logs Explorer. Du kan oprette en logforespørgsel i dette værktøj og scanne for potentielle udnyttelsesstrenge.
- Google har også skabt log4jscanner, en open source-filsystemscanner til at opdage Log4j-sårbarhed.
- BurpSuite Log4j Scanner: Dette er et sikkerhedsplugin til fagfolk og virksomheder for at hjælpe dem med at opdage Log4j-sårbarhed.
- Huntress Log4Shell Vulnerability Tester: Dette værktøj genererer tilfældigt en unik identifikator, som du kan bruge, mens du tester dine inputfelter. Når dens sikre LDAP-server finder en sårbarhed i applikationen eller inputfeltet, vil dens sikre LDAP-server afslutte den ondsindede forbindelse øjeblikkeligt og holde dig sikker.
- WhiteSource Log4j Detect: WhiteSource har skabt et gratis CLI-værktøj, WhiteSource Log4j Detect, hostet på GitHub for at hjælpe dig med at opdage og rette Log4j-sårbarheder – CVE-2021-445046 og CVE-2021-44228.
- JFrog Open-Source-scanningsværktøjer til Log4j: JFrog har skabt forskellige open source-løsninger og værktøjer til at finde Log4j-sårbarheder i dine binære filer og kildekode.
Konklusion
Log4j-sårbarhed er et kritisk sikkerhedsproblem. Da dette logbibliotek bruges meget i forskellige applikationer og systemer, er Log4j-sårbarheden blevet udbredt, hvilket gør det muligt for angribere at udnytte en lang række systemer og apps.
Så hvis du vil beskytte dine systemer og applikationer mod denne sårbarhed, skal du sørge for at opgradere Log4j-biblioteket til den nyeste version og implementere den bedste sikkerhedspraksis, der er beskrevet ovenfor.