Steven J. Vaughan-Nichols medvirkende redaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologivirksomhet siden CP/M-80 var banebrytende PC-operativsystem; 300bps var en rask Internett-tilkobling; WordStar var toppmoderne tekstbehandler; og vi likte det.
Full Bio Publisert i Zero Day 17. desember 2021 | Emne: Sikkerhet 
Det regner ikke, men det regner. Tidligere var en antagelse om sikkerhetssårbarheten på 10 av 10 Log4j at den var begrenset til utsatte sårbare servere. Vi tok feil. Sikkerhetsselskapet Blumira hevder å ha funnet en ny, spennende Log4j-angrepsvektor.
Du ville egentlig ikke ta denne helgen fri, gjorde du? Selvfølgelig ikke! I stedet vil du jage ned sårbar Log4j-kode stadig dypere inn i nettverket ditt. I følge Blumira kan denne nyoppdagede Javascript WebSocket-angrepsvektoren utnyttes gjennom banen til en lytteserver på deres maskin eller lokale nettverk. En angriper kan ganske enkelt navigere til et nettsted og utløse sårbarheten. Ved å legge fornærmelse til skade, kan WebSocket-tilkoblinger i verten være vanskelig å få dyp synlighet i. Det betyr at det er enda vanskeligere å oppdage denne sårbarheten og angrepene ved å bruke den.
Denne vektoren utvider angrepsoverflaten betydelig. Hvor mye så? Den kan brukes på tjenester som kjører som localhost, som ikke er eksponert for et nettverk. Dette er det vi liker å kalle et “Skyt meg nå”-problem.
Å, og nevnte jeg det? Klienten selv har ingen direkte kontroll over WebSocket-tilkoblinger. De kan starte stille når en nettside lastes inn. Elsker du ikke ordet “stille” i denne sammenhengen? Jeg vet jeg gjør det.
WebSockets, for de av dere som ikke er nettutviklere, finnes i nesten alle moderne nettlesere. De brukes ofte til toveis kommunikasjonsfunksjoner som nettprat og varsler. De er flinke til å sende rettidig informasjon tilbake til nettleseren og lar nettleseren raskt sende data frem og tilbake.
Men WebSockets har sine egne sikkerhetsrisikoer. WebSockets er ikke begrenset av retningslinjer for samme opprinnelse som en vanlig HTTP-forespørsel på tvers av domener. I stedet forventer de at nettserveren validerer en forespørsels opprinnelse. Kort sagt, de kommer ikke med mye i veien for innebygde sikkerhetstiltak.
Som du vil gjette ut fra dette, har WebSockets blitt brukt i angrep før. WebSockets har blitt brukt til å angripe kabelmodemer ved å sende ondsinnede forespørsler. Den brukes også av hackere til vertsfingeravtrykk og portskanning.
I sitt proof-of-concept-angrep fant Blumira at ved å bruke en av de mange Java Naming and Directory Interface (JNDI)-utnyttelsene som de kunne utløse via en filbane-URL ved å bruke en WebSocket-tilkobling til maskiner med et installert sårbart Log4j2-bibliotek. Alt som var nødvendig for å utløse suksess var en baneforespørsel som ble startet på nettsiden. Enkelt, men dødelig.
For å gjøre saken verre, trenger den ikke å være lokalvert. WebSockets tillater tilkoblinger til enhver IP. La meg gjenta “Alle IP” og det inkluderer privat IP-plass.
Etter hvert som siden laster, vil den starte en lokal WebSocket-tilkobling, treffe den sårbare lytteserveren og koble seg ut over den identifiserte typen tilkobling basert på JNDI-tilkoblingsstrengen. Forskerne så mest suksess ved å bruke Java Remote Method Invocation (RMI). standard port 1099., selv om vi ofte ser tilpassede porter brukt. Bare portskanning, en teknikk som allerede finnes i WebSocket hackerhåndboken, var den enkleste veien til et vellykket angrep. For å gjøre det enda vanskeligere å oppdage slike angrep, fant selskapet at “spesifikke mønstre ikke bør forventes, da det er lett å utløse trafikk passivt i bakgrunnen.”
Deretter blir det funnet en åpen port til en lokal tjeneste eller en tjeneste tilgjengelig for verten, den kan da slippe JNDI-utnyttingsstrengen i banen eller parametere. “Når dette skjer, ringer den sårbare verten ut til utnyttelsesserveren, laster angriperens klasse og kjører den med java.exe som overordnet prosess.” Da kan angriperen løpe hva han vil.
Det er de faktisk allerede. Som Anurag Gurtu, StrikeReadys chief product officer, observerte: “Tilsynelatende utnytter et løsepenge-angrep for øyeblikket Log4Shell-sårbarheten. Det er Khonsari-ransomware-gjengen som har bygget et angrep ved hjelp av C# og .NET-rammeverket. Etter utførelse teller skadevaren opp alt som er montert. stasjoner (annet enn C:/) og målretter mot brukerkataloger inkludert dokumenter, videoer, bilder, nedlastinger og skrivebord. En AES 128 CBC-algoritme brukes for kryptering, og filene lagres med en .khonsari-utvidelse.”
De er ikke de eneste. Statsstøttede hackere fra Kina, Iran, Nord-Korea og Tyrkia; Cobalt Strike; og mange andre utnytter også Log4j-sårbarheter. Denne siste sårbarheten åpner ganske enkelt dørene enda bredere for potensielle angripere.
Det vil bare bli verre før det blir bedre For som seniortrusselsforsker Sean Gallagher fra Sophos nylig forklarte til dags dato, har Log4Shell-angripere vært fokusert på kryptominering, men dette er bare en “pause før stormen.”< /p>
Han fortsatte, “Vi forventer at motstandere sannsynligvis vil få så mye tilgang til det de kan få akkurat nå… for å tjene penger og/eller kapitalisere på det senere. Den mest umiddelbare prioriteringen for forsvarere er å redusere eksponeringen ved å lappe og redusere alle hjørner av deres infrastruktur og undersøke utsatte og potensielt kompromitterte systemer.” Tross alt, konkluderte Gallagher: “Denne sårbarheten kan være overalt.”
Hva kan du gjøre med dette? Blumira foreslår følgende:
Oppdater alle lokale utviklingstiltak, interne applikasjoner og internettvendte miljøer til Log4j 2.16 så snart som mulig, før trusselaktører kan bevæpne denne utnyttelsen ytterligere. Dette inkluderer flytting av tilpassede applikasjoner i deres avhengighetsmanifester til 2.16 så snart som mulig for å unngå tilfeldig utnyttelse.
Du bør også se nøye på nettverkets brannmur og utgangsfiltrering. Oppdraget her er å begrense tilbakeringingen som kreves for selve utnyttelsen til land. Betraktelig begrensning av utgående trafikk til endepunktene dine vil redusere risikoen når du lapper applikasjonene dine. Pass spesielt på at bare enkelte maskiner kan sende ut trafikk over 53, 389, 636 og 1099 porter. Alle andre porter skal blokkeres. Til slutt, siden bevæpnet Log4j-applikasjoner ofte forsøker å ringe hjem til herrene sine over tilfeldige høye porter, bør du blokkere tilgangen deres til slike porter.
Lykke til, kom tilbake til jobben med å lete etter Log4j-biblioteker og samtaler og håper at du får så mye av infrastrukturen som mulig før ferien.
Relaterte historier:
Log4j: Store IT-leverandører skynder seg å fikse denne feilen og mer før jul. Log4j null-dagers feil: Hva du trenger å vite og hvordan beskytte deg selv.US advarer Log4j-feil setter hundrevis av millioner av enheter i fare.
Sikkerhet
Log4j-trussel: Hva du trenger å vite og hvordan du kan beskytte deg selv Ransomware i 2022: Vi er alle skrudd Microsoft Patch Tirsdag: Zero-day utnyttet for å spre Emotet malware Kronos rammet med løsepengeprogramvare, advarer om datainnbrudd og “flere ukers” utfall De beste VPN-ene for små og hjemmebaserte bedrifter i 2021 Enterprise Software | Sikkerhets-TV | Databehandling | CXO | Datasentre