Steven J. Vaughan-Nichols bidragande redaktör
Steven J. Vaughan-Nichols, alias sjvn, har skrivit om teknik och teknikens verksamhet sedan CP/M-80 var det banbrytande PC-operativsystemet; 300 bps var en snabb Internetanslutning; WordStar var den senaste ordbehandlaren; och vi gillade det.
Fullständig biografi Publicerad i Zero Day den 17 december 2021 | Ämne: Säkerhet 
Det regnar inte, men det ösregnar. Tidigare var ett antagande om 10 av 10 Log4j-säkerhetssårbarheten att den var begränsad till utsatta sårbara servrar. Vi hade fel. Säkerhetsföretaget Blumira säger sig ha hittat en ny spännande Log4j-attackvektor.
Du ville verkligen inte ta ledigt i helgen, eller hur? Självklart inte! Istället kommer du att jaga ner sårbar Log4j-kod allt djupare in i ditt nätverk. Enligt Blumira kan denna nyupptäckta Javascript WebSocket-attackvektor utnyttjas genom sökvägen till en lyssningsserver på deras maskin eller lokala nätverk. En angripare kan helt enkelt navigera till en webbplats och utlösa sårbarheten. WebSocket-anslutningar inom värden kan vara svåra att få djup insyn i, vilket ger förolämpning till skada. Det betyder att det är ännu svårare att upptäcka denna sårbarhet och attacker med den.
Denna vektor utökar attackytan avsevärt. Hur mycket så? Den kan användas på tjänster som körs som localhost, som inte är exponerade för ett nätverk. Det här är vad vi vill kalla ett “Skjut mig nu”-problem.
Åh, och nämnde jag det? Klienten själv har ingen direkt kontroll över WebSocket-anslutningar. De kan starta tyst när en webbsida laddas. Älskar du inte ordet “tyst” i detta sammanhang? Jag vet att jag gör.
WebSockets, för er som inte är webbutvecklare, finns i nästan alla moderna webbläsare. De används ofta för tvåvägskommunikationsfunktioner som webbchatt och varningar. De är bra på att skicka information i rätt tid tillbaka till webbläsaren och låter webbläsaren snabbt skicka data fram och tillbaka.
Men WebSockets har sina egna säkerhetsrisker. WebSockets är inte begränsade av principer med samma ursprung som en vanlig HTTP-förfrågan över flera domäner. Istället förväntar de sig att webbservern ska validera en begärans ursprung. Kort sagt, de kommer inte med mycket i vägen för inbyggda säkerhetsåtgärder.
Som du kan gissa från detta, har WebSockets använts i attacker tidigare. WebSockets har använts för att attackera kabelmodem genom att skicka skadliga förfrågningar. Den används också av hackare för värdfingeravtryck och portskanning.
I sin proof-of-concept-attack fann Blumira att genom att använda en av de många Java Naming and Directory Interface (JNDI) exploater som de kunde utlösa via en filsökvägs-URL med en WebSocket-anslutning till maskiner med ett installerat sårbart Log4j2-bibliotek. Allt som behövdes för att utlösa framgång var en sökvägsbegäran som startade vid webbsidans laddning. Enkelt, men dödligt.
För att göra saken värre behöver det inte vara lokalvärd. WebSockets möjliggör anslutningar till valfri IP. Låt mig upprepa, “Alla IP” och det inkluderar privat IP-utrymme.
Sedan, när sidan laddas, kommer den att initiera en lokal WebSocket-anslutning, träffa den sårbara lyssningsservern och ansluta över den identifierade typen av anslutning baserat på JNDI-anslutningssträngen. Forskarna såg mest framgång med att använda Java Remote Method Invocation (RMI). standardport 1099., även om vi ofta ser anpassade portar som används. Helt enkelt portskanning, en teknik som redan finns i WebSockets hackerhandbok, var den enklaste vägen till en framgångsrik attack. Företaget gjorde det ännu svårare att upptäcka sådana attacker och fann att “specifika mönster inte bör förväntas eftersom det är lätt att utlösa trafik passivt i bakgrunden.”
Sedan hittas en öppen port till en lokal tjänst eller en tjänst tillgänglig för värden, den kan sedan släppa JNDI-exploateringssträngen i sökväg eller parametrar. “När detta händer ropar den sårbara värden ut till exploateringsservern, laddar angriparens klass och kör den med java.exe som överordnad process.” Då kan angriparen springa vad han vill.
Det är de faktiskt redan. Som Anurag Gurtu, StrikeReadys produktchef, observerade: “Tydligen utnyttjar en ransomware-attack för närvarande log4Shell-sårbarheten. Det är Khonsari ransomware-gänget som har byggt en attack med C# och .NET-ramverket. Efter körningen räknar skadlig programvara upp alla monterade enheter (andra än C:/) och riktar in sig på användarkataloger inklusive dokument, videor, bilder, nedladdningar och skrivbord. En AES 128 CBC-algoritm används för kryptering, och filerna sparas med tillägget .khonsari.”
De är inte de enda. Statssponsrade hackare från Kina, Iran, Nordkorea och Turkiet; Cobalt Strike; och många andra utnyttjar också Log4j-sårbarheter. Denna senaste sårbarhet öppnar helt enkelt dörrarna ännu bredare för potentiella angripare.
Det kommer bara att bli värre innan det blir bättre För som Sophos seniorhotforskare Sean Gallagher nyligen förklarade hittills har Log4Shell-angripare varit fokuserade på kryptominering, men detta är bara en “vila före stormen.” /p>
Han fortsatte, “Vi förväntar oss att motståndare sannolikt kommer att få så mycket tillgång till vad de än kan få just nu… för att tjäna pengar och/eller dra nytta av det senare. Den mest omedelbara prioriteringen för försvarare är att minska exponeringen genom att lappa och mildra alla hörn. av sin infrastruktur och undersöka utsatta och potentiellt komprometterade system.” När allt kommer omkring, drog Gallagher slutsatsen, “Denna sårbarhet kan finnas överallt.”
Vad kan du göra åt detta? Blumira föreslår följande:
Uppdatera alla lokala utvecklingsinsatser, interna applikationer och internetanvändande miljöer till Log4j 2.16 så snart som möjligt, innan hotaktörer kan beväpna detta utnyttjande ytterligare. Detta inkluderar att flytta alla anpassade applikationer i deras beroendemanifest till 2.16 så snart som möjligt för att undvika tillfällig exploatering.
Du bör också titta noga på din nätverksbrandvägg och utgående filtrering. Uppdraget här är att begränsa återuppringningen som krävs för att själva exploateringen ska landa. Att avsevärt begränsa utgående trafik för dina slutpunkter kommer att minska risken när du patchar dina applikationer. Se särskilt till att endast vissa maskiner kan skicka ut trafik över 53, 389, 636 och 1099 portar. Alla andra portar bör blockeras. Slutligen, eftersom beväpnade Log4j-applikationer ofta försöker ringa hem till sina herrar över slumpmässiga höga portar, bör du blockera deras åtkomst till sådana portar.
Lycka till, börja jobba igen med att leta efter Log4j-bibliotek och samtal och hoppas att du får så mycket av din infrastruktur som du kan slå ner innan semestern.
Relaterade berättelser:
Log4j: Stora IT-leverantörer skyndar sig att fixa detta fel och mer inför jul. Log4j nolldagarsfel: Vad du behöver veta och hur du skyddar dig själv.USA varnar Log4j-felet sätter hundratals miljoner enheter i fara.
Säkerhet
Log4j-hot: Vad du behöver veta och hur du skyddar dig Ransomware 2022: Vi är alla skruvade Microsoft Patch Tisdag: Zero-day utnyttjas för att sprida Emotet malware Kronos drabbades av ransomware, varnar för dataintrång och “flera veckors” avbrott De bästa VPN:erna för små och hembaserade företag 2021 Enterprise Software | Säkerhets-TV | Datahantering | CXO | Datacenter