Google släppte igår en säkerhetsuppdatering till webbläsaren Chrome på grund av aktivt utnyttjande av två nya zero-days som fått CVE-2021-37975 och CVE-2021-37976.
CVE-2021-37976 är en bugg som orsakar informationsläckage och underlättar utnyttjande av sårbarheten nedan. Upptäcktes av Clément Lecigne från Googles Threat Analysis Group (TAG)
Även så har följande sårbarhet identifierats som allvarlig men där inget aktivt utnyttjande identifierats:
CVE-2021-37974 är också en use after free i Safe Browsing.
Samt så har minst en till säkerhetsbugg åtgärdats där fuzzing-tester identifierat denna internt hos Google. Så totalt innehåller denna uppdatering fyra säkerhetsfixar.
Och det var inte så många dagar sedan som ytterligare två sårbarheter åtgärdades av Google där också dessa utnyttjades aktivt. Den gången rörde det sig om CVE-2021-30632 och CVE-2021-30633 där ena va dessa var en sårbarhet i IndexedDB API:et.
För att kontrollera om du har installerat senaste versionen av Chrome så kan du skriva in följande sökväg i adressfältet: chrome://settings/help och då bör du se något i stil med följande när du installerat senaste uppdateringen och blivit ombedd att starta om webbläsaren:
Den versionen som släpptes igår till Windows, Linux och macOS har versionsnummer 94.0.4606.71. Och vill du läsa mer om denna stable-channel update så kan du göra det här.
I detta blogginlägg tänkte jag redogöra för en av flera metoder som kan användas för att identifiera spionprogramvaran Pegasus från ökända NSO Group.
Pegasus installeras via en eller flera sårbarheter som utnyttjas främst i iPhones. Och kräver att användaren öppnar en länk, SMS eller liknande. Dessa sårbarheter går under benämningarna Zero-Click, One-Click eller FCP som står för Full Chain with Persistence. Lite beroende på vilken typ av sårbarhet som utnyttjas.
Att vi känner till några av sårbarheterna som utnyttjas av Pegasus är för att Citizen Lab har analyserat mobiltelefonerna hos personer med kopplingar till Bahrain Center for Human Rights. Sårbarheterna åtgärdades i iOS version 14.8 som släpptes igår. Och sårbarheterna har CVE-2021-30860 som är enligt Apple:
Processing a maliciously crafted PDF may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
Samt CVE-2021-30858 som inrapporterats av en anonym person men som återfinnes i Webkit:
Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
Detektion
Tyvärr så finns det inget bra sätt att analysera innehållet på en iPhone om den inte är jailbreakad. Jag hoppas på att Apples Endpoint Security som finns till macOS även kommer att komma till iOS.
Har du inte möjlighet att jailbreaka så finns det några andra metoder att använda. Dels kan du via en MDM-lösning forcera ett VPN som gör det möjligt att titta på nätverkstrafik som går till och från en mobiltelefon och dels så kan du analysera backup-filer från iTunes. Även finns det möjlighet att installera en proxy som tittar på all kommunikation samt titta på eventuella loggfiler/krashloggar.
Men för detta blogginlägg tänkte jag testa MVT (Mobile Verification Toolkit) som är ett verktyg som släppts av Amnesty International. Det är ett öppet verktyg som är skrivet i Python och kan ge en fingervisning om en mobiltelefon blivit hackad.
Verktyget MVT hittar du på Github här samt Indicator of Compromise (IOC) hittar du här. Värt att nämna är att MVT även fungerar på Android-baserade mobiltelefoner.
Steg 1 är att skapa en backup av iOS-enheten via iTunes eller Finder. Du kan även skapa en krypterad backup, för mvt kan dekryptera denna med hjälp av ett lösenord:
När vi sedan har en backup så behöver vi eventuellt dekryptera denna först, det kan man göra på följande sätt:
Även finns det mer IOC:er att kontrollera mot, bl.a här. Observera att denna metod först och främst kontollerar om mobiltelefonen kommunicerat med några av de kända ändpunkterna. Huruvida sårbarheten/sårbarheterna lyckats eller ej är svårare att avgöra med denna metodik.
Uppdatering: Erik från Netresec tipsade om denna enkla metod som kan användas. Obs denna kan ge en hel del false positives:
Another simple way to check iOS devices for signs of CVE-2021-30860 / FORCEDENTRY exploitation. Run MVT, then simply:
Igår så fångade min honeypot upp ett intressant meddelande, nämligen att någon försöker utnyttja, alternativt kontrollera huruvida servrar är sårbara för CVE-2021-26084.
Eftersom min honeypot inte är just en Confluence-server så vet jag inte om antagonisten hade för avsikt att utnyttja en sårbarhet eller ej, som beskrivs enligt följande av Atlassian själva som utvecklar Confluence:
An OGNL injection vulnerability exists that would allow an authenticated user, and in some instances unauthenticated user, to execute arbitrary code on a Confluence Server or Data Center instance
Sårbarheten upptäcktes av Benny Jacob (SnowyOwl) och rapporterades via deras bugbounty-program hos BugCrowd.
Amerikanska myndigheten FBI skickade ut ett flash-meddelande gällande grupperingen Hive ransomware. Grupperingen använder främst phishing och exponerade RDP-tjänster för att ta sig in i nätverk och sedan kryptera data och utpressa målen. Gällande utpressningen så har grupperingen en webbsajt på Tor-nätverket vid namn HiveLeaks.
På HiveLeaks tor-sajt hittar jag mängder av företag som utpressas av grupperingen:
Skärmdump från HiveLeaks
Den skadliga koden som exekveras i systemen hos offren innehåller delar för att stänga av antivirus-mjukvara samt förhindra eventuell backup.
Vad också är intressant är att grupperingen använder legitima mjukvaror som troligtvis redan finns inom Er organisation, FBI skriver:
Some of these indicators might appear as applications within your enterprise supporting legitimate purposes; however, these applications can be used by threat actors to aid in further malicious exploration of your enterprise.
FBI har även med en lista med rekommenderade åtgärder där de framhåller att organisationer ej bör betala antagonisterna för ransomware men oavsett så bör man kontakta FBI.
När det gäller åtgärder för att försvåra för dessa grupperingar så rekommenderar FBI:
Se till att backup verkligen är offline och har ni har backup + testar backupen
Använd tvåfaktorsautentisering
Övervaka externa anslutningar såsom VPN efter suspekta logins
Håll datorer, enheter och servrar uppdaterade med säkerhetspatchar och nya antivirus-regler
Och om du drabbas av ett intrång så genomför följande:
Isolera systemet och stäng av all kommunikation såsom bluetooth, wifi, ethernet osv
Stäng av infekterade system och andra anslutna system. Om krypteringen inte blivit färdig så finns det möjlighet för återställning
Säkra eventuella backuper så de ej raderas. Sök igenom dessa efter skadlig kod innan återställning.
Rapporten från FBI innehåller även en del IOC:er samt att antagonisterna använder tjänster för anonym fildelning för att exfiltrera information. Listan är enligt följande:
Den som följer mig på LinkedIn vet att jag flaggade upp för en eller flera nya sårbarheter i OpenSSL. Idag den 24:de Augusti så släpptes informationen om dessa.
Sårbarheterna återfinnes dels i ASN.1-hanteringen (no suprise) samt hanteringen av SM2-signaturer. SM2 är framtaget av Kina och återfinnes som standarden ISO/IEC 14888 (GM/T 0003-2012).
Gällande ASN.1 så skriver OpenSSL-projektet följande:
If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext).
Sårbara funktioner listas bl.a. X509_get1_email(), X509_REQ_get1_email() och X509_get1_ocsp().
Den allvarligaste är SM2-hanteringen som är en buffer-overflow, men troligtvis används av färre.
Varför är dessa två sårbarheterna allvarliga? Jo det är så att OpenSSL och dess olika forkar såsom BoringSSL återfinnes i många hundratals miljoner enheter och mjukvaror. Att patcha och åtgärda sårbarheter kommer att ta otroligt lång tid.
Rätt ofta när jag granskar olika typer av tjänster eller produkter så kan dessa på något sätt hantera PDF-filer. Så under några år så har jag manuellt skapat PDF-filer som innehåller olika avarter såsom ”ringa hem”-funktionalitet. Dvs en länk som på något sätt triggar ett anrop mot internet manuellt eller automatiserat. Dessa går som oftast via HTTPS/HTTP eller bara ett DNS-uppslag.
Efter några timmars research och komplettering med de PDF-filer som jag hade tidigare så skrev jag ihop ett enkelt verktyg som spottar ut ett gäng PDF-filer som du sedan laddar upp eller skickar in i tjänsten som du granskar/testar.
Det är således ett verktyg främst för penetrationstestare eller säkerhetsgranskare. Verktyget heter malicious PDF vilket kanske är lite missvisande eftersom det bara är externa länkar som PDF-filerna innehåller. Jag brukar använda det på så sätt att jag genererar en Burp Collaborator URL som sedan automatiskt placeras i PDFerna av verktyget.
Givetvis går det även att sätta upp en egen Burp Collaborator-server genom att följa denna guide.
Några av de funktioner som implementeras:
ImportData
SubmitForm
GoToR
Launch
URI
Extern XSLT stylesheet in XFA
CHTTP app.openDoc Javascript
Och finns givetvis fler anrop som kan implementeras, kolla gärna credits i länken nedan och gör gärna en pull request!
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:
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.
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.
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.
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:
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.
