Innholdsfortegnelse[Gjemme seg][Forestilling]
Log4Shell, et sikkerhetsproblem på internett, har nylig berørt millioner av maskiner. Log4j, en obskur, men nesten allestedsnærværende programvare, forårsaker det.
Log4j brukes til å logge alle handlingene som skjer bak kulissene i en rekke datasystemer.
Det er basert på et åpen kildekode-loggingsbibliotek som brukes av bedrifter og til og med offentlige organisasjoner i de fleste applikasjoner.
Siden det er et av de verste cybersikkerhetshullene som noen gang er avdekket, er det avgjørende å beskytte systemene dine mot dette sikkerhetsproblemet. Men hvordan?
La oss utforske Log4j-sårbarheten i detalj og alle mulige løsningsløsninger for den.
Hva er Log4j?
Log4j er en åpen kildekode loggingsrammeverk som gjør det mulig for programvareutviklere å registrere forskjellige data i applikasjonene sine. Det er en komponent i Apache Logging Services-prosjektet, som drives av Apache Software Foundation.
Hundrevis av nettsteder og apper bruker Log4j til å utføre kritiske operasjoner som logging av data for feilsøking og annen bruk.
Når du legger inn eller klikker på en dårlig nettlenke og får en 404-feilmelding, er dette et hyppig eksempel på Log4j på jobb. Nettserveren som kjører domenet til nettlenken du prøvde å få tilgang til, informerer deg om at det ikke finnes noen slik nettside. Den logger også hendelsen i Log4j for serverens systemadministratorer.
Gjennom programvareprogrammer brukes lignende diagnostiske signaler. I nettspillet Minecraft, for eksempel, bruker serveren Log4j til å logge aktivitet som total RAM brukt og brukerinstruksjoner sendt inn i konsollen.
Hvordan oppstår sårbarheten?
Oppslag er en ny funksjon introdusert i Log4j 2.0, som hjelper til med å inkludere tilleggsinformasjon i loggoppføringer. Et av disse oppslagene er JNDI (Java Naming and Directory Interface) oppslag, som er et Java API for å kommunisere med en katalogtjeneste.
Ved å bruke denne tilnærmingen kan interne bruker-IDer tilordnes til faktiske brukernavn. Denne spørringen avslører det nylig oppdagede RCE-sårbarheten, siden en av datatypene som leveres av LDAP-serveren er en URI som peker til en Java-klasse, som deretter lastes inn i minnet og kjøres av Log4j-forekomsten.
På grunn av en svakhet i Log4j-bibliotekets inndatavalidering, er det mulig å injisere en vilkårlig LDAP-server fra en ikke-klarert kilde. Fordi utviklere antar at data som sendes til logger vil bli behandlet som ren tekst, utføres ingen ekstra inndatavalidering, og farlige brukerinndata kommer inn i loggene.
En loggsetning kan se slik ut:
En ondsinnet bruker vil nå sette inn et JNDI-oppslag som refererer til en falsk LDAP-server i en URL-parameter. JNDI-oppslaget vil være som følger:
Log4j-biblioteket snakker deretter med denne LDAP-serveren på attacker.com for å få kataloginformasjon, inkludert verdier for Java Factory og Java Codebase.
Disse to verdiene inkluderer angriperens Java-klasse, som deretter lastes inn i minnet og kjøres av Log4j-forekomsten, og fullfører kodekjøringen.
Hvem er i faresonen?
Log4j-sårbarheten er utrolig bred, og påvirker forretningsapplikasjoner, innebygde enheter og deres undersystemer. Berørte apper inkluderer Cisco Webex, Minecraft og FileZilla FTP.
Dette er imidlertid på ingen måte en hel liste. Feilen påvirker til og med Ingenuity Mars 2020 chopper-oppdraget, som bruker Apache Log4j for hendelsesopptak.
Sikkerhetsmiljøet har satt sammen en liste over sårbare systemer. Det er viktig å merke seg at disse listene oppdateres kontinuerlig, så hvis et bestemt program eller system ikke er omtalt, ikke anta at det ikke er berørt.
Eksponering for denne sårbarheten er ganske sannsynlig, og selv om en spesifikk teknisk stabel ikke bruker Java, bør sikkerhetsledere forvente at kritiske leverandørsystemer, SaaS-leverandører, nettskyvertsleverandører og webserverleverandører gjør det.
Hvordan sjekke for Log4j-sårbarhet?
Det første trinnet er å finne ut om et overfall allerede har skjedd. Du kan gjøre det ved å sjekke systemloggene for RCE-nyttelastfragmenter.
Hvis et søk etter termer som "jndi", "ldap" eller "$::" gir noen logger, bør sikkerhetsforskere utforske videre for å se om det var et legitimt angrep eller bare fingeravtrykk.
Mange angrep i naturen ble oppdaget som ikke ga noen skadelig nyttelast. Ikke desto mindre ble de utført av sikkerhetseksperter for å finne ut hvor mange apper som var sårbare for dette angrepet.
Det neste trinnet er å bruke Log4j-biblioteket til å identifisere alle prosjekter. Hvis versjoner mellom 2.0-beta9 og 2.14.1 brukes, kan prosjektet være mottakelig.
Gitt vanskeligheten med å avgjøre hvor denne sårbarheten eksisterer, kan det være å foretrekke å anta at prosjektet er mottakelig og at oppdatering av biblioteket er den beste handlingen for å fjerne faren for kjøring av kode.
Prosjektet er ikke sårbart hvis den brukte versjonen er mindre enn 2.0-beta 9, selv om Log4j-biblioteket fortsatt bør oppgraderes fordi versjoner i 1.x-serien er gamle og ikke lenger får oppdateringer.
Hvorvidt et mottakelig prosjekt oppdages, anbefales det at det sjekkes for å se om informasjon logget med Log4j inneholder informasjon som brukeren kan endre. URL-er, forespørselsparametere, overskrifter og informasjonskapsler er eksempler på disse dataene. Hvis en av disse logges, er prosjektet i fare.
Denne kunnskapen kan hjelpe deg med å dykke videre inn i systemloggene og avgjøre om nettapplikasjonen din allerede har blitt angrepet.
Det finnes gratis verktøy på nett som kan oppdage om en nettapplikasjon er sårbar. Et av disse programmene er Log4Shell-jeger. Den er åpen kildekode og tilgjengelig på GitHub.
Hvis et sårbart kodeområde i nettapplikasjonen oppdages, kan nyttelasten fra det beskrevne verktøyet brukes til å injisere den i nettapplikasjonen. Testverktøyet vil avsløre forbindelsene mellom nettapplikasjonen din og LDAP-serveren hvis sårbarheten ble utnyttet.
Løsninger for å fikse Log4j-sårbarheten
Det første trinnet er å oppdatere Log4j, noe du kan gjøre ved å bruke de vanlige pakkebehandlerne eller ved å laste den ned direkte fra denne side.
Det er også mulig å redusere sårbarhetens utnyttelsesevne ved å sette miljøvariabelen FORMAT MSG NO LOOKUPS til sann. Dette mottiltaket gjelder imidlertid bare for Log4j-versjoner større enn eller lik 2.10.
La oss nå vurdere alternative alternativer.
1. Midlertidige løsninger for Log4j versjon 2.17.0
Det anbefales definitivt på det sterkeste å bruke Log4j versjon 2.15.0 for å beskytte mot Log4Shell, men hvis dette ikke er mulig, er andre løsninger tilgjengelige.
Versjon 2.7.0 og nyere av Log4j: Det er mulig å beskytte mot ethvert angrep ved å endre formatet på hendelsene som skal logges ved å bruke prosent m nolookups-syntaksen for dataene som er levert av brukeren. Denne oppdateringen krever redigering av Log4j-konfigurasjonsfilen for å generere en ny versjon av programmet. Som et resultat, før du distribuerer denne nye versjonen, må de tekniske og funksjonelle valideringsstadiene gjentas.
Log4j versjoner 2.10.0 og nyere: Det er også mulig å beskytte mot ethvert angrep ved å sette log4j2.formatMsgNoLookups konfigurasjonsparameter til true, for eksempel når du starter den virtuelle Java-maskinen med alternativet -Dlog4j2." formatMsgNoLookups = true, Et annet alternativ er å fjerne JndiLookup-klassen fra klassesti-argumentet, som vil fjerne hovedangrepsvektoren (forskerne utelukker ikke muligheten for en annen angrepsvektor).
Amazon Web Services tilbyr en hotpatch som "bør brukes på egen risiko." Andre "teknikker", som Logout4Shell, som "bruker denne sårbarheten mot seg selv," har blitt publisert. Sikkerhetseksperten stiller spørsmål ved lovligheten av dette trekket, som innebærer å "hacke en maskin for å fikse det."
2. Problemet er løst i Log4j v2.17.0.
For versjoner høyere enn 2.10: Log4j2.formatMsgNoLookups bør settes til true.
For versjoner 2.0 til og med 2.10.0: Kjør følgende kommando for å fjerne LDAP-klassen fra Log4j.
Log4j2.formatMsgNoLookups skal settes til true i systeminnstillingene.
Redusering i JVM
Redusering med JVM-parametere er ikke lenger et alternativ. Andre avbøtende metoder fortsetter å være vellykkede. Oppgrader til Log4j versjon 2.17.0 hvis mulig. Det er en migreringsveiledning tilgjengelig for Log4j v1.
Hvis en oppdatering ikke er mulig, sørg for at komponentene på klientsiden og serversiden har egenskapen -Dlog4j2.formatMsgNoLookups = true system.
Vær oppmerksom på at Log4j v1 har nådd slutten av levetiden (EOL) og vil ikke lenger motta feilrettinger. Andre RCE-vektorer er også mottakelige for Log4j v1. Derfor oppfordrer vi deg til å oppgradere til Log4j 2.17.0 så snart som mulig.
3. Avbøtende tiltak
Gjeldende utnyttelser kan ikke fungere selv om Log4j er mottakelig i noen tilfeller, for eksempel hvis vertsmaskinen kjører en Java-versjon høyere enn 6u212, 7u202, 8u192 eller 11.0.2.
Dette skyldes bedre Java-navngivning og kataloggrensesnitt (JNDI) ekstern klasse lasting beskyttelse i gjeldende versjoner, som er nødvendig for at angrepet skal fungere.
Videre, med Log4j-versjoner større enn 2.10, kan problemet unngås ved å sette formatMsgNoLookups-systemverdien til true, gi JVM-argumentet -Dlog4j2.formatMsgNoLookups = true, eller slette JndiLookup-klassen fra klassebanen.
I mellomtiden, inntil de sårbare forekomstene er fikset, kan sårbarheten løses ved å bruke teknikkene nedenfor:
- Sett systemegenskapen log4j2.formatMsgNoLookups til true for >=2.10.
- Sett miljøalternativet LOG4J FORMAT MSG NO LOOKUPS til sann for >=2.10.
- Fjern JndiLookup.class fra klassebanen for 2.0-beta9 til 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
En anbefalt beste praksis er å begrense utgående trafikk til internett til bare de riktige portene.
Selv om de fleste angrep i feltet leveres over HTTP, kan sårbarheten utnyttes via en hvilken som helst protokoll som logger brukerinndata ved hjelp av Log4j.
Oppdatering til log4j 2.17.0 er imidlertid den beste løsningen fordi noen kan oppdage en ekstra tilnærming til problemet. Videre har mange utgivere og produsenter annonsert forbedringer av tjenestene eller appene deres.
4. Log4Shell sårbarhetsoppdatering
Log4j er allestedsnærværende, spesielt nå som sårbarheten blir utnyttet. For å oppsummere, alt du trenger å gjøre er å inkludere følgende tegn i loggene inspisert av Log4j.
Og dette vil laste ned og kjøre Java-filen som ligger på slutten av URL-en. Det er like enkelt som det er dramatisk.
Som du er klar over, er det avgjørende å oppgradere log4j til versjon >= 2.17.0 for å rette opp dette Log4Shell-sårbarheten (CVE-2021-44228).
Hvis dette ikke er mulig:
For applikasjoner som bruker Log4j-bibliotekversjoner 2.10.0 og nyere, er det også mulig å beskytte mot ethvert angrep ved å sette konfigurasjonsparameteren log4j2.formatMsgNoLookups til true, for eksempel mens du starter den virtuelle Java-maskinen med -Dlog4j2.formatMsgNoLookups = true alternativ.
Et annet alternativ er å slette JndiLookup-klassen fra classpath-argumentet, som vil fjerne den primære angrepsvektoren (forskerne utelukker ikke at det finnes en annen angrepsvektor).
Merknader
Organisasjoner som er nølende eller uvillige til å foreta justeringer av følsomme systemer (eller som ønsker å installere ekstra sikkerhetstiltak) bør tenke på:
- Sørg for at all trafikk rutes gjennom en iSensor/WAF/IPS. Dette kan forhindre at angrepet får tilgang til systemet.
- Begrense mengden trafikk som kan nå det følsomme systemet Hvis systemet ikke trenger å være koblet til internett, begrense tilgangen til bare viktige og pålitelige IPS-er og rekkevidder.
- Redusere vertens autoriserte utgående trafikk. Fordi dette angrepet fungerer ved å koble til en useriøs server, bør alle overflødige IP-adresser og porter blokkeres på en brannmur.
- Hvis tjenesten ikke lenger er nødvendig, bør den deaktiveres til en løsning er klar.
konklusjonen
Log4j-feilene sjokkerte samfunnet vårt og minnet oss alle om hvor avhengige vi er av åpen kildekode-programvare.
Log4j er unik. Det er verken et operativsystem, det er heller ikke en nettleser, og det er heller ikke en programvare. Det er snarere hva programmerere omtaler som et bibliotek, en pakke eller en kodemodul. Det tjener bare ett formål, det vil si å holde oversikt over hva som skjer på en server.
Folk som skriver kode foretrekker å konsentrere seg om det som gjør programvaren deres særegen. De er ikke interessert i å finne opp hjulet på nytt. Som et resultat er de avhengige av en mengde eksisterende kodebiblioteker, for eksempel Log4j.
Log4j-modulen er avledet fra Apache, den mest brukte webserverprogramvaren. Det er derfor det kan oppdages på millioner av servere. Derfor øker sikkerhetstruslene.
Jeg håper løsningene ovenfor hjelper deg med å holde enhetene dine trygge.
Følg med på HashDork for mer nyttig informasjon fra teknologiverdenen.
Legg igjen en kommentar