Steven J. Vaughan-Nichols bidragende redaktør
Steven J. Vaughan-Nichols, aka sjvn, har skrevet om teknologi og teknologiens forretning, siden CP/M-80 var det banebrydende pc-operativsystem; 300bps var en hurtig internetforbindelse; WordStar var den nyeste tekstbehandler; og vi kunne lide det.
Fuld bio Udgivet i Zero Day den 17. december 2021 | Emne: Sikkerhed 
Det regner ikke, men det øser. Tidligere var en antagelse om 10 ud af 10 Log4j sikkerhedssårbarhed, at den var begrænset til udsatte sårbare servere. Vi tog fejl. Sikkerhedsfirmaet Blumira hævder at have fundet en ny, spændende Log4j-angrebsvektor.
Du havde ikke rigtig lyst til at holde denne weekend fri, gjorde du? Selvfølgelig ikke! I stedet vil du jagte sårbar Log4j-kode stadig dybere ind i dit netværk. Ifølge Blumira kan denne nyopdagede Javascript WebSocket-angrebsvektor udnyttes gennem stien til en lytteserver på deres maskine eller lokale netværk. En angriber kan blot navigere til et websted og udløse sårbarheden. WebSocket-forbindelser inden for værten tilføjer fornærmelse til skade, kan være svære at få dyb synlighed i. Det betyder, at det er endnu sværere at opdage denne sårbarhed og angreb ved at bruge den.
Denne vektor udvider angrebsoverfladen betydeligt. Hvor meget så? Det kan bruges på tjenester, der kører som localhost, som ikke er udsat for et netværk. Det er det, vi kan lide at kalde et “Skyd mig nu”-problem.
Åh, og nævnte jeg det? Klienten selv har ingen direkte kontrol over WebSocket-forbindelser. De kan stille og roligt starte, når en webside indlæses. Elsker du ikke ordet “stille” i denne sammenhæng? Det ved jeg, at jeg gør.
WebSockets, for dem af jer, der ikke er webudviklere, findes i næsten alle moderne webbrowsere. De bruges almindeligvis til tovejskommunikationsfunktioner såsom hjemmesidechat og advarsler. De er gode til at sende rettidig information tilbage til browseren og tillader browseren hurtigt at sende data frem og tilbage.
Men WebSockets har deres egne sikkerhedsrisici. WebSockets er ikke begrænset af politikker med samme oprindelse som en normal HTTP-anmodning på tværs af domæner. I stedet forventer de, at webserveren validerer en anmodnings oprindelse. Kort sagt, de kommer ikke med meget i vejen for indbyggede sikkerhedsforanstaltninger.
Som du ville gætte ud fra dette, er WebSockets blevet brugt i angreb før. WebSockets er blevet brugt til at angribe kabelmodemmer ved at sende ondsindede anmodninger. Det bruges også af hackere til host-fingeraftryk og portscanning.
I deres proof-of-concept-angreb fandt Blumira ud af, at ved at bruge en af de mange Java Naming and Directory Interface (JNDI) udnyttelser, som de kunne udløse via en filsti-URL ved hjælp af en WebSocket-forbindelse til maskiner med et installeret sårbart Log4j2-bibliotek. Alt, hvad der var nødvendigt for at udløse succes, var en sti-anmodning, der blev startet på websideindlæsningen. Simpelt, men dødbringende.
For at gøre tingene værre, behøver det ikke at være lokal vært. WebSockets giver mulighed for forbindelser til enhver IP. Lad mig gentage, “Enhver IP”, og det inkluderer privat IP-plads.
Efterhånden som siden indlæses, vil den derefter starte en lokal WebSocket-forbindelse, ramme den sårbare lytteserver og oprette forbindelse over den identificerede type forbindelse baseret på JNDI-forbindelsesstrengen. Forskerne så den største succes ved at bruge Java Remote Method Invocation (RMI). standardport 1099., selvom vi ofte ser brugerdefinerede porte brugt. Simpelthen portscanning, en teknik, der allerede findes i WebSockets hackerhåndbog, var den nemmeste vej til et vellykket angreb. For at gøre det endnu sværere at opdage sådanne angreb fandt virksomheden ud af, at “specifikke mønstre ikke bør forventes, da det er let at udløse trafik passivt i baggrunden.”
Derefter findes en åben port til en lokal tjeneste eller en tjeneste, der er tilgængelig for værten, og den kan derefter slippe JNDI-udnyttelsesstrengen i stien eller parametrene. “Når dette sker, kalder den sårbare vært til exploit-serveren, indlæser angriberens klasse og udfører den med java.exe som overordnet proces.” Så kan angriberen løbe, hvad han vil.
Det er de faktisk allerede. Som Anurag Gurtu, StrikeReadys chief product officer, bemærkede: “Tilsyneladende udnytter et ransomware-angreb i øjeblikket Log4Shell-sårbarheden. Det er Khonsari-ransomware-banden, der har bygget et angreb ved hjælp af C# og .NET frameworket. Efter udførelse opregner malwaren alle monterede drev (bortset fra C:/) og målretter mod brugermapper inklusive dokumenter, videoer, billeder, downloads og skrivebord. En AES 128 CBC-algoritme bruges til kryptering, og filerne gemmes med en .khonsari-udvidelse.”
De er ikke de eneste. Statssponserede hackere fra Kina, Iran, Nordkorea og Tyrkiet; Cobalt Strike; og mange andre udnytter også Log4j-sårbarheder. Denne seneste sårbarhed åbner simpelthen dørene endnu bredere for potentielle angribere.
Det bliver kun værre, før det bliver bedre For som seniortrusselsforsker Sean Gallagher fra Sophos til dato for nylig forklarede, har Log4Shell-angribere været fokuseret på kryptominering, men dette er blot en “pause før stormen.”< /p>
Han fortsatte: “Vi forventer, at modstandere sandsynligvis vil få så meget adgang til, hvad de kan få lige nu… for at tjene penge og/eller udnytte det senere. Den mest umiddelbare prioritet for forsvarere er at reducere eksponeringen ved at lappe og afbøde alle hjørner. af deres infrastruktur og undersøge udsatte og potentielt kompromitterede systemer.” Når alt kommer til alt, konkluderede Gallagher: “Denne sårbarhed kan være overalt.”
Hvad kan du gøre ved dette? Blumira foreslår følgende:
Opdater alle lokale udviklingsindsatser, interne applikationer og internet-vendende miljøer til Log4j 2.16 så hurtigt som muligt, før trusselsaktører kan våben denne udnyttelse yderligere. Dette inkluderer flytning af tilpassede applikationer i deres afhængighedsmanifester til 2.16 så hurtigt som muligt for at undgå utilsigtet udnyttelse.
Du bør også se nøje på din netværksfirewall og udgangsfiltrering. Missionen her er at begrænse det tilbagekald, der kræves for den faktiske udnyttelse til land. En væsentlig begrænsning af udgående trafik for dine endepunkter vil reducere risikoen, når du patcher dine applikationer. Sørg især for, at kun visse maskiner kan sende trafik over 53, 389, 636 og 1099 porte. Alle andre porte skal være blokeret. Endelig, da bevæbnet Log4j-applikationer ofte forsøger at ringe hjem til deres herrer over tilfældige høje porte, bør du blokere deres adgang til sådanne porte.
Held og lykke, kom tilbage til arbejdet med at jage Log4j-biblioteker og opkald, og håber, at du får så meget af din infrastruktur, som du kan slå ned inden ferien.
Relaterede historier:
Log4j: Store IT-leverandører skynder sig at løse denne fejl og mere forud for jul. Log4j nul-dages fejl: Hvad du behøver at vide og hvordan du beskytter dig selv.US advarer Log4j-fejlen sætter hundredvis af millioner af enheder i fare.
Sikkerhed
Log4j-trussel: Hvad du behøver at vide, og hvordan du beskytter dig selv Ransomware i 2022: Vi er alle sammen skruet Microsoft Patch Tirsdag: Zero-day udnyttet til at sprede Emotet-malware, som Kronos ramte med ransomware, advarer om databrud og “flere ugers” udfald De bedste VPN'er til små og hjemmebaserede virksomheder i 2021 Enterprise Software | Sikkerheds-tv | Datastyring | CXO | Datacentre