Log4j-sårbarheter er kommet for å bli – er du forberedt?

Den utbredte sårbarheten som først dukket opp i Apache Log4j i 2021 vil fortsette å bli utnyttet, potensielt til og med på verre måter enn vi har sett til dags dato. Det mer bekymringsfulle aspektet ved disse truslene er at det er en god sjanse for at de vil fortsette å bli utnyttet måneder eller år inn i fremtiden.

Department of Homeland Securitys Cyber ​​Safety Review-styre debuterte i 2021, og ga i 2022 ut sin første sikkerhetsrapport (PDF). I den kalte styret Log4j en "endemisk sårbarhet", hovedsakelig fordi det ikke er en omfattende "kundeliste" for Log4j, noe som gjør det til en nesten umulig oppgave å holde tritt med sårbarheter. En føderal kabinettavdeling brukte til og med 33,000 4 timer på sin LogXNUMXj-respons.

Og mange organisasjoner og sikkerhetsløsninger på markedet klarer ikke å identifisere forskjellen mellom utnyttelse og sårbarhet – noe som gir angripere en mulighet til å utføre ondsinnet aktivitet.

Utnyttbarhet vs. sårbarhet

Et av hovedproblemene med cybersikkerhet i dag er å forstå forskjellen mellom sårbarheter og deres alvorlighetsgrad. Når det gjelder å måle utnyttbarhet kontra en sårbarhet, er det stor forskjell på om en sikkerhetstrussel kan utnyttes i virksomheten din eller om den bare er "sårbar" og ikke kan hindre virksomheten eller nå en kritisk ressurs. Sikkerhetsteam bruker for mye tid på å ikke forstå forskjellen mellom de to og fikser hver sårbarhet etter hvert, i stedet for å prioritere de som kan utnyttes.

Hvert selskap har tusenvis av vanlige sårbarheter og eksponeringer (CVE), hvorav mange scorer høyt på Common Vulnerability Scoring System (CVSS), så det er umulig å fikse dem alle. For å bekjempe dette er håpet at verktøy for risikobasert sårbarhetsstyring (RBVM) vil gjøre prioritering enklere ved å avklare hva som kan utnyttes.

Sikkerhetsprioriteringsmetoder som kombinerer CVSS-score med RBVM-trusselsinformasjon gir imidlertid ikke optimale resultater. Selv etter å ha filtrert og sett på hva som kan utnyttes i naturen, har sikkerhetsteam fortsatt for mye å håndtere fordi listen er lang og uhåndterlig. Og bare fordi en CVE ikke har en utnyttelse i dag, betyr det ikke at den ikke vil ha en neste uke.

Som svar har selskaper lagt til prediktiv risiko AI, som kan hjelpe brukere å forstå om en CVE kan bli utnyttet i fremtiden. Dette er fortsatt ikke nok og fører til for mange problemer å fikse. Tusenvis av sårbarheter vil fortsatt vise seg å ha en utnyttelse, men mange vil ha andre sett med betingelser som må oppfylles for å faktisk utnytte problemet.

For eksempel, med Log4j, må følgende parametere identifiseres:

• Finnes det sårbare Log4j-biblioteket?
• Lastes den av et Java-program som kjører?
• Er JNDI-oppslaget aktivert?
• Lytter Java til eksterne tilkoblinger, og er det en tilkobling for andre maskiner?

Hvis betingelsene og parameterne ikke er oppfylt, er ikke sårbarheten kritisk og bør ikke prioriteres. Og selv om en sårbarhet kan utnyttes på en maskin, hva så? Er den maskinen ekstremt kritisk, eller er den kanskje ikke koblet til noen kritiske eller sensitive eiendeler?

Det er også mulig at maskinen ikke er viktig, men den kan gjøre det mulig for en angriper å fortsette mot kritiske eiendeler på skjulte måter. Med andre ord, kontekst er nøkkelen - er denne sårbarheten på en potensiell angrepsvei til den kritiske ressursen? Er det nok å kutte av en sårbarhet ved et chokepoint (et skjæringspunkt mellom flere angrepsveier) for å stoppe angrepsbanen fra å nå en kritisk ressurs?

Sikkerhetsteam hater sårbarhetsprosesser og deres løsninger, fordi det er flere og flere sårbarheter – ingen kan noen gang tørke hele listen rent. Men hvis de kan fokus på det som kan skape skade til en kritisk ressurs, kan de få en bedre forståelse av hvor de skal begynne.

Bekjempelse av Log4j-sårbarheter

Den gode nyheten er at riktig sårbarhetshåndtering kan bidra til å redusere og fikse eksponeringen for Log4j-sentriske angrep ved å identifisere hvor risikoen for potensiell utnyttelse eksisterer.

Sårbarhetshåndtering er et viktig aspekt ved cybersikkerhet og er nødvendig for å sikre sikkerheten og integriteten til systemer og data. Det er imidlertid ikke en perfekt prosess, og sårbarheter kan fortsatt være tilstede i systemer til tross for best mulig innsats for å identifisere og redusere dem. Det er viktig å regelmessig gjennomgå og oppdatere prosesser og strategier for sårbarhetshåndtering for å sikre at de er effektive og at sårbarheter blir løst i tide.

Fokuset for sårbarhetshåndtering bør ikke bare være på selve sårbarhetene, men også på den potensielle risikoen for utnyttelse. Det er viktig å identifisere punktene der en angriper kan ha fått tilgang til nettverket, samt veiene de kan ta for å kompromittere kritiske eiendeler. Den mest effektive og kostnadseffektive måten å redusere risikoen for en bestemt sårbarhet på er å identifisere forbindelsene mellom sårbarheter, feilkonfigurasjoner og brukeratferd som kan utnyttes av en angriper, og proaktivt løse disse problemene før sårbarheten utnyttes. Dette kan bidra til å forstyrre angrepet og forhindre skade på systemet.

Du bør også gjøre følgende:

• Lapp: Identifiser alle produktene dine som er sårbare for Log4j. Dette kan gjøres manuelt eller ved å bruke åpen kildekode-skannere. Hvis en relevant oppdatering er utgitt for et av dine sårbare produkter, må du lappe systemet ASAP.
• Løsning: På Log4j versjoner 2.10.0 og nyere, i Java CMD-linjen, angi følgende: log4j2.formatMsgNoLookups=true
• Blokkere: Hvis mulig, legg til en regel i brannmuren for nettapplikasjonen for å blokkere: "jndi:"

Perfekt sikkerhet er en uoppnåelig bragd, så det er ingen vits i å gjøre perfekt til det godes fiende. Fokuser i stedet på å prioritere og låse potensielle angrepsveier som kontinuerlig forbedrer sikkerhetsstillingen. Å identifisere og være realistisk om hva som faktisk er sårbart versus hva som kan utnyttes, kan bidra til dette, siden det vil tillate muligheten til å strategisk kanalisere ressurser mot kritiske områder som betyr mest.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-