Log4Shell: Log4j-sårbarhedsnødsituationen forklaret tydeligt

Siden den 1. december 2021 er en sårbarhed knyttet til open source-logningsbiblioteket Apache Log4j 2 blevet aktivt udnyttet, hvilket har påvirket utallige digitale produkter og tjenester globalt.

For at hjælpe dig med at blive hurtigt informeret om denne begivenhed, dens konsekvenser og hvordan du reagerer, har vi opsummeret de vigtige detaljer om Log4Shell i dette indlæg.

En oversigt over Log4Shell-sårbarheden

En kritisk sikkerhedsfejl i Log4j-rammen gør det muligt for cyberkriminelle at kompromittere sårbare systemer med blot en enkelt ondsindet kodeinjektion.

Sårbarheden er forbundet med brugeraktivitetsloggeren kendt som Log4J - et logningsbibliotek, der distribueres frit af Apache Software Foundation.

Java implementeres på tværs af en bred vifte af digitale produkter, herunder cloud-løsninger, webservere og apps, hvilket gør hvert af disse produkter sårbare over for udnyttelse gennem Log4Shell-sårbarheden.

Fordi denne sikkerhedsfejl er så udbredt, og de fleste organisationer ikke er klar over, at de er påvirket, er der i øjeblikket et udnyttelsesvanvid i gang i den cyberkriminelle verden. Sikkerhedsforskere har identificeret cirka 10 millioner Log4Shell-udnyttelsesforsøg hver time.

Detailbranchen lider under det højeste antal angreb, efterfulgt af teknologi, finansielle tjenesteydelser og fremstillingstjenester.

Sundhedsudbydere er også i høj alarmberedskab i betragtning af branchens mangeårige ry for at lide under cyberangreb.

Kortet nedenfor viser de regioner, hvor Log4Shell har forsøgt at udnytte og tætheden af disse angreb. De regioner, der er højest målrettet, er USA, Storbritannien, Tyskland, Tyrkiet og Holland.

Kilde: eset.com

Sådan løses Log4j-problemet

Aktualiteten af denne sårbarhed, kombineret med dens maksimale CVSS-score på 10, betyder, at det vil tage noget tid, før en pålidelig patch af denne eksponering er udviklet.

I mellemtiden skal beredskabsteams følge denne beskyttelses- og afhjælpningsprotokol for at hjælpe med at håndtere sårbarheden.

1. Opdater til den nyeste version af Log4j-biblioteket

Den hurtigste og i øjeblikket mest effektive afhjælpningsreaktion er at opgradere alle forekomster af Log4j til den nyeste version - Log4j 2.17.1 (download den seneste Apache Log4j-version her).

Ifølge Apache er sårbarheden CVE-2021-45105 rettet i den seneste biblioteksversion. Dette bør forhindre fremtidige angreb, men det vil ikke afhjælpe eventuelle skader, der er opstået før biblioteksopgraderingen.

Da denne sårbarhed er så udbredt, er det sikrest at antage, at dit økosystem blev kompromitteret før en biblioteksopgradering, og at iværksætte reaktioner på databrud med det samme.

Selv enheder, der ikke bruger Apache-logtjenester, bør antage et databrud, fordi virkningen af dette zero-day-par potentielt påvirker hele angrebsfladen.

Få mere at vide om mentaliteten om at antage brud.

Ud over en antagelses brud-mentalitet bør alle serverlogfiler gennemgås for Indicators of Compromise (IOC) som beskrevet i følgende ressourcer:

  • GitHub-ressource 1
  • GitHub-ressource 2
  • GitHub-ressource 3
  • Gråstøj ressource

UpGuard har udviklet en domæne- og IP-scanner, der hurtigt opdager enheder, der er påvirket af CVE-2021-44228.

Scanneren fungerer ved at sende en streng i URL'en til en HTTP GET-anmodning til hvert domæne og IP-adresse, der scannes.

Sårbare Log4j-biblioteker bekræftes, når der oprettes en godartet LDAP-forbindelse til en sikker server.

Hvis alle udgående forbindelser er blokeret, bekræftes kilden til mislykkede forsøg på at oprette forbindelse til UpGuards sikre LDAP-server i din udgående proxy/firewall som sårbar over for nul-dagen.

Klik her for at se UpGuard Log4j-sårbarhedsscanneren i aktion.

3. Skift Java-systemegenskaber

Hvis det ikke er muligt at opgradere til den nyeste Log4j-version, skal sikkerhedsteams implementere følgende svar med det samme for version 2.10 til 2.14.1:

>

Angiv enten følgende systemegenskab til true:


log4j2.formatMsgNoLookups

Eller indstil følgende miljøvariabel til sand:


LOG4J_FORMAT_MSG_NO_LOOKUPS

4. Deaktiver JNDI

En designfejl i JNDI Lookup-plugin'et er primært skyld i denne kritiske sårbarhed. JNDI letter kodeudførelse baseret på data fundet i loggen, data, der let kan manipuleres, da de accepteres af loggeren uden sanitet.

Det er for nylig blevet opdaget, at JNDI Lookup-plugin'et altid har tilladt, at uanalyseret information sendes til Log4j-biblioteket, lige siden udgivelsen i 2013.

Dette er grunden til, at CVE-2021-44228 kan udnyttes ved en enkelt strenginjektion.

Når den er injiceret, vil loggeren betragte operationen, der er indlejret i strengen, som en del af dens originale kodebase og øjeblikkeligt udføre den.

Ved at deaktivere JndiLookup-klassen vil loggeren ikke være i stand til at foretage handlinger baseret på data fundet i loggen. JNDI er deaktiveret som standard i version 2.16.0 af Log4j

Sårbare versioner af Log4j kan også sikres ved at fjerne JndiLookup-klassen fra følgende klassesti:

zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.class

5. Send Apache Log4j-spørgeskema til leverandører

UpGuards Apache Log4j-spørgeskema hjælper sikkerhedsteams med at opdage tredjepartsleverandører, der bruger software eller cloud-tjenester, der er påvirket af Log4j-sårbarheden, enten direkte eller via forsyningskæder.

For at se dette spørgeskema i aktion, klik her.

6. Opdater alle firewalls og systemer til forebyggelse af indtrængen

Opdater alle næste generations firewalls, webapplikationsfirewalls og systemer til beskyttelse mod indtrængen med de nyeste regler og signaturer. Rettelserne kan filtrere eller blokere LDAP- og RMI-trafik, der forsøger at nå skadelige LDAP-servere.

7. Implementer multifaktorgodkendelse

Generel sanitetspraksis som multifaktorgodkendelse og strenge VPN-politikker kan hindre succesen med databrud, hvis en angriber formår at opnå netværksadgang gennem Apache Log4j-sårbarheden,

8. Brug Huntress Log4Shell sårbarhedstester

Huntress har skabt et scanningsværktøj til at teste, om nogen almindeligt loggede processer eller data, der sendes gennem API'er, er påvirket af Log4Shell-sårbarheden. Kildekoden kan downloades fra GitHub her.

Ved at bruge begge scannere vil du have en større chance for at opdage grænsevirkningerne af Log4j-sårbarheden.

For yderligere anbefalinger til beskyttelsesforanstaltninger mod denne nul-dages trussel henvises til dette indlæg fra Cybersecurity and Infrastructure Security Agency (CISA).

Hvad er CVE-2021-44228?

Den originale Apache Log4j-sårbarhed (CVE-2021-44228), også kendt som Log4Shell, er en cybersikkerhedssårbarhed på Apache Log4j 2 Java-biblioteket.

Denne sikkerhedsfejl er en sårbarhed i forbindelse med fjernudførelse af kode (RCE) - en af de mest kritiske sikkerhedseksponeringer.

Fordi den originale Log 4j-sårbarhed har den mest kritiske trusselsklassificering af CVSS 10 - en vurdering, der sjældent tildeles - er det usandsynligt, at et enkelt patch-forsøg vil løse alle loggerens sikkerhedsproblemer, især når næsten alle cyberkriminelle i verden forsøger at omgå forsvaret mod en af de største udnyttelser i internetæraen.

Fire patches er blevet forsøgt, og indtil videre har to af dem vist sig at indeholde sikkerhedssårbarheder. Hver ny sårbarhed tildeles en separat CVE-identitet startende fra den oprindelige zero-day exploit.

Nedenfor er en opdateret kronologisk liste over CVE'er, der er forbundet med Log4j sårbart:

  • CVE-2021-44228 - dette er sporingsidentiteten for den oprindelige Log4j-udnyttelse
  • CVE-2021-45046 - sporingsidentiteten for den sårbarhed, der er knyttet til den første Log4j-patch (version 2.15.0). Ifølge Apaches sikkerhedsrådgivning viste det sig, at version 2.15.0 lette Denial of Service-angreb ved at give angribere mulighed for at fremstille ondsindede inputdata ved hjælp af et JNDI-opslagsmønster.
  • CVE-2021-45105 - sporingsidentiteten for den sårbarhed, der er forbundet med den anden Log4j-patch (version 2.16.0), efter at den viste sig at tillade angribere at kontrollere Thread Context Map-data for at forårsage et lammelsesangreb, når en fabrikeret streng fortolkes.
  • CVE-2021-44832 - sporingsidentiteten for sårbarheden, der påvirker alle versioner af Apache Log4j 2 (undtagen 2.32 og 2.12.4). Denne sikkerhedsfejl udsætter alle sårbare versioner for risiko for Remote Code Injection (RCE)

Alle ovenstående sikkerhedsrisici er adresseret i den seneste Log4J-version - version 2.17.1 (download version 2.17.1 her).

For yderligere oplysninger, se Apaches fulde afsløring her.

Hvordan fungerer Log4j-cyberangrebet?

Log4Shell-sårbarheden giver hackere mulighed for eksternt at injicere vilkårlig kode i et målnetværk og overtage fuld kontrol over det.

For at forstå cyberangrebssekvensen er det vigtigt først at forstå, hvordan loggere fungerer.

Uden et loggerbibliotek som Log4j arkiveres information fra servere øjeblikkeligt efter indsamling.

Men hvis loggede data aktivt analyseres, eller hvis visse handlinger som svar på specifikke logdata er påkrævet, kan Java-softwareudviklere bruge et bibliotek som Log4j til at analysere logfiler, før de arkiveres.

Enhver virksomhed, der bruger et sårbart Log4j-bibliotek til at analysere logdata i deres backend-systemer, er sårbar over for et Log4j-cyberangreb.

Denne logger er i stand til at udføre kode baseret på input, og fordi sårbarheden gør det muligt for angribere at manipulere inputdata, kan loggeren blive tvunget til at udføre skadelig kode.

Teknisk set vil det sårbare Log4j-bibliotek, når det passerer en særligt udformet streng, kalde ud til en LDAP-server, downloade koden i LDAP-biblioteket og derefter udføre koden. Dette gør det muligt for cyberkriminelle at oprette en ondsindet LDAP-server, der gemmer kode, der er designet til at overtage enhver server, hvor den udføres, og derefter sende applikationer/databaser/API'er den streng, der peger på deres kode.

Kilde: fastly.com

Hvorfor er Log4Shell så kritisk?

CVE-2021-44228 anses af mange sikkerhedseksperter for at være en af de værste eksponeringer i den digitale teknologis historie.

Denne dristige holdning understøttes af to faktorer:

1. CVE-2021-44228 er ekstremt let at udnytte

For at udnytte sårbarheden behøver en trusselsaktør kun at indsætte en streng i en fælles loghændelse for derefter at injicere en ondsindet nyttelast.

Denne proces kræver meget lidt dygtighed, og der er allerede sket mange udnyttelsesforsøg siden sårbarhedens opdagelse den 5. december 2021.

For at se udnyttelseshastigheden skal du tage et kig på følgende proof-of-concept, der demonstrerer et angreb på en Minecraft-server.

2. Enhver Java-software kan blive påvirket

Fordi Log4j er et almindeligt anvendt Java-logningsbibliotek, kan denne sårbarhed potentielt påvirke alle applikationer og software, der implementerer Java.

Det er svært at kvantificere det store antal potentielt berørte systemer. Et skøn på et par milliarder tilfælde ville blive betragtet som konservativt.

Dette skyldes, at Java er integreret i mange digitale produkter og tjenester, herunder:

  • Internet-routere
  • Virksomhedssoftware
  • Microsoft-, Amazon-, AWS- og Twitter-servere

Selv telefoner er potentielt sårbare. Selvom de ikke kører Java direkte, kommunikerer deres backend-systemer sandsynligvis med Log4j-biblioteket via APis. Så en ondsindet streng, der sendes til en iPhone, kan blive injiceret i dens backend, hvilket fører til kompromittering.

Software med Apache Log4j-sikkerhedssårbarheder behøver ikke engang at blive direkte eksponeret for internettet for at blive udnyttet.

Ondsindede strenge kan endda trænge ind i back-end-software, der kører sårbare Apache Log4j-versioner, selvom den internetvendte webapplikation ikke er kodet i Java.

Selvom ingen af dine webapplikationer og back-end-software kører sårbare Log4j-versioner, kan dine tredjepartsleverandører være det, hvilket så udsætter dit økosystem for potentialet for tredjepartsbrud.

De enorme muligheder for angrebsvektorer og enkelheden i deres kompromis giver næring til et udnyttelsesvanvid blandt cyberkriminelle.

Ifølge Security Firm Check Point blev over 60 variationer af den oprindelige udnyttelse opdaget på mindre end 24 timer, hvilket betyder, at cyberkriminelle udvider deres udnyttelsesrammer i forventning om kommende patches.

Hvis malware injiceres i LDAP-servere, kan CVE-2021-44228-sårbarheden resultere i en flodbølge af kolossale databrud og ransomware-angreb, der ville overskygge nogle af de største brud, vi har set til dato.

Der er to historiske sikkerhedsbrud, der kan sammenlignes med den potentielle indvirkning af Apache Log4j-sårbarheden.

  • Equifax-databruddet blev lettet af Apache Struts-sårbarheden CVE-2017-5638, hvor 147 millioner mennesker blev påvirket.
  • ShellShock (kendt som Bashdoor) er en familie af sikkerhedsfejl, der påvirker Unix Bash Shell. Når de udnyttes, kan ShellShock-fejl tillade angreb at tvinge Bash til at udføre ondsindede kommandoer. De lignende egenskaber mellem Bashdoor og Log4Shell tyder på, at de to cyberrisici kan være en del af den samme familie af sårbarheder.

Hvilke versioner af Log4j 2 påvirkes?

Alle versioner af Log4j før version 2.17.0 er potentielt påvirket af Log4j-udnyttelsen. Alle objekter, der bruger Log 4j, skal straks opgradere til den nyeste Apache-biblioteksversion - 2.17.1

Log4j version 2.17.1 kan downloades her.

Log4j 1 understøttes ikke længere, og som følge heraf vil dens sårbarheder ikke blive løst med fremtidige patch-udgivelser. Alle slutpunktsforekomster af denne version skal straks opdateres til version 2.17.1

Hvilke produkter påvirkes?

De 10 bedste leverandører, der er blevet påvirket af Log4Shell, er angivet nedenfor. Hver angivet enhed linker til dokumentation, der forklarer sikkerhedssvarene fra den berørte udbyder.

  • Adobe
  • AWS
  • CISCO
  • IBM
  • F-Secure
  • Broadcom
  • Fortinet
  • FortiGuard
  • Okta
  • VMware

For den komplette liste over produkter og cloud-tjenester, der er påvirket af Log4j-sårbarheden, henvises til dette indlæg. Hvis din virksomhed bruger nogen af disse produkter, skal du sørge for at opdatere dem med de nyeste patches med det samme.

Selvom ingen af disse løsninger bruges internt, kan du stadig være i fare. Hvis nogen af dine leverandører bruger en løsning, der er påvirket af Log4Shell-sårbarheden, kan din virksomhed blive offer for et forsyningskædeangreb.

Strategier til styring af leverandørrisiko hjælper med at evaluere potentialet for sådanne tredjepartsbrud gennem løsninger til overvågning af angrebsoverflader og sikkerhedsspørgeskemaer, der specifikt adresserer cybertrusler som Log4Shell zero-day exploit.