Taggat med: google

Kommande kritisk sårbarhet i OpenSSL

OpenSSL-teamet har gått ut med förhandsinformation gällande en ny sårbarhet som uppdagats i kryptobiblioteket OpenSSL. Information och en ny version av OpenSSL-biblioteket kommer att släppas den 1:a November någon gång mellan klockan 13 och 17:00 UTC.

Den nya versionen har nummer 3.0.7 och åtgärden klassas som KRITISK. Och enligt OpenSSL-projektets policy så innebär KRITISK att det är en sårbarhet som enkelt kan utnyttjas via internet och kan ge möjlighet att läsa minne eller godtycklig exekvering av kod.

Det är oklart i dagsläget huruvida andra forkar av OpenSSL påverkas såsom LibreSSL och BoringSSL. Viktigt är också att OpenSSL 1.1.x inte är drabbad av denna sårbarhet.

Vi får hoppas att detta inte blir en ny Heartbleed. Men OpenSSL är en viktig del av otroligt många produkter, system osv så oavsett vad som händer på tisdag den 1:a november så kommer det att komma många uppdateringar till diverse system och produkter.

Bugbounties är en av flera metoder att öka säkerheten i opensource-mjukvaror och Google betalar ut pengar till den som hittar buggar i OpenSSL sedan 2013.

Uppdatering: Även om OpenSSL 1.x är den vanligare versionen där ute så finns OpenSSL 3.x på rätt många ställen, bl.a. så skeppar Red Hat Enterprise Linux 9.x och Ubuntu 22.04 med OpenSSL 3.x som är sårbar.

Uppdatering 2: Lista med mjukvara som är berörd av patchen: https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md

Velociraptor för threat hunting

Velociraptor digital forensics and incident response (DFIR)

Velociraptor är ett digital forensics and incident response (DFIR)-verktyg som är utvecklat av Mike Cohen. Mike jobbade tidigare på Google och var då med och utvecklade Googles verktyg för IT-incidentutredningar vid namn Google Rapid Response (GRR).

Velociraptor är gratis och använda och det finns ett aktivt community som ständigt släpper nya VQL såsom denna som kan detektera CVE-2021-4034 (PwnKit aka polkit pkexec) eller denna (Log4jVulnHunter) för Log4j-sårbarheten. VQL är ett SQL-liknande språk för att skriva ”hunts” eller monitor-regler.

Klienten för Velociraptor går att köra på Windows, Linux och macOS samt så använder den TLS för kommunikationen mellan klient och server.

Tre tre främsta användningsområden för Velociraptor är följande:

  • Insamling av data och artefakter
  • Övervakning och monitorering
  • Threat hunting

Du har även möjlighet att ladda hem och köra tredjepartsprogram såsom Sysinternals Autoruns och använda den informationen för vidare analys. Och inbyggt så finns det stöd för att söka efter Indicators of Compromise och liknande med Yara. Minnesdumpar kan hämtas in med en winpmem och en VQL heter Acquisition.

Du kan även skicka vidare information som Velociraptor hämtar in till andra system som är bättre på att analysera mängder med information såsom Splunk eller Elasticsearch.

En av fördelarna som jag ser med Velociraptor är att tiden för mean time to detect (MTTD) och mean time to respond (MTTR) kan förkortas.

Men vad finns det för nackdelar då? Jo, tröskeln att komma igång och lära sig verktyget kan ta några dagar. Du inför även en ytterligare komponent till din IT-miljö där säkerhetsbrister kan uppstå.

Men sammanfattningsvis så rekommenderar jag helt klart Velociraptor om ni ej har en liknande förmåga i dagsläget i Er IT-miljö.

Skärmdumpar

Insamling av DNS-loggar via Event Tracing for Windows (ETW)
Ett jobb som samlar in scheduled tasks i Windows
Jag testar PwnKit exploiten och kör sedan en hunt för att identifiera den. Lyckas bra!
Hur det ser ut när man loggar in i Admin GUI:t. Visar server status som standard

Om du vill läsa mer och lära dig om Velociraptor rekommenderar jag hemsidan här:

Sammanfattning

Velociraptor är ett mycket bra komplement till Er redan befintliga miljö som troligtvis innehåller flertalet förmågor för att upptäcka och försvåra intrång. Tanken är inte att Velociraptor ska byta ut OSSEC, Wazuh, Sysmon, auditd eller liknande. Inte heller är Velociraptor ett antivirus-system som automatiskt uppdateras med nya IoC:er, men givetvis kan det till viss del utföra alla dessa funktioner.

Bildkälla

Två nya Linux-sårbarheter

Det är ingen bra vecka för Linux-baserade operativsystem såsom Debian, Ubuntu, Fedora och CentOS. Minst två olika sårbarheter har upptäckts och program för att nyttja dessa sårbarheter finns publicerade.

De två sårbarheterna som är aktuella just nu är en som går under namnet PwnKit och utnyttjar en brist i pkexec som är en del av Polkit, CVE-2021-4034. Den andra buggen är en kernel-bugg som kan användas för att göra Docker/container samt escapes från Kubernetes. För denna sista bugg så betalade Google ut en Bug Bounty på hela $31337 vilket är ungefär 300,000 svenska kronor.

Video där Qualys som identifierade sårbarheten visar hur polkit-buggen utnyttjas på Debian Bullseye:

Den andra Linux-kernelbuggen identifierades av CTF-teamet Crusaders of Rust där bl.a. William Liu och Jamie Hill-Daniel ingår, den har CVE-2022-0185.

För att buggen ska fungera på Docker så måste –privileged användas samt så hjälper den standard-seccomp profil som följer med. Men tyvärr är det inte allt för ofta som seccomp används för containers.

Det finns en exploit här och jag kan verkligen rekommendera deras utförliga write-up här:

Uppdatering: Amazon Linux 2 har inte polkit installerat som standard. Men om du installerar polkit så är det nuvarande paketet sårbart.

Identifiera log4j med OSS-Fuzz och några säkerhetshöjande tips

Såhär i efterhand är det bra att dra lärdomar från log4j-sårbarheten och hur vi i framtiden kan förhindra liknande sårbarheter. En av mina personliga metoder är att genomföra fuzz-tester för att identifiera indikationer på att något är fel i ett system, bibliotek eller mjukvara.

Ett av Googles projekt som har identifierat flest antal sårbarheter genom tiderna heter OSS-Fuzz och drivs av ett antal backends såsom  libFuzzer, AFL++ och Honggfuzz. I början av 2021 så fick libFuzzer stöd för att fuzza Java-kod med hjälp av Jazzer. Främst kod som är skriven JVM-baserade språk, såsom Java, Kotlin och Clojure.

Bildkälla: code-intelligence.com

För den fuzzing-kod som har hand om Remote JNDI-lookups så går den att se här. Men givetvis är fuzz-tester inte enbart den enda lösningen på att bygga säkra och robusta IT-system. Några andra säkerhetshöjande åtgärder för att försvåra attacker såsom Log4Shell (log4j) i framtiden:

  • Begränsa så att servrar och klienter inte får prata godtyckligt ut mot internet. Gäller även DNS-uppslag
  • Använd data-dioder för att föra in loggar i fysiskt separerade system. Till exempel en SOC/SIEM (airgap)
  • Se över Er software bill of materials (SBOM)
  • Genomför regelbundet automatiska och manuella penetrationstester
  • Öva regelbundet olika scenarior där ni exempelvis snabbt måste identifiera ett tredjepartsbibliotek och begränsa skadan som kan uppstå till följd av en sårbarhet
  • Se till att ni har verktyg som stödjer alla olika former av aktiviteter såsom den på raden ovan. Buzz-word för ett sådant verktyg kan vara Endpoint Detection & Response (EDR). Rekommenderar att snegla på Velociraptor (blogginlägg kommer)
  • Mjukvaror, system osv bör separeras så mycket som det går och gå med så låga behörigheter som möjligt. Se till att ha en förmåga att logga om en mjukvara avviker från detta
  • Ställ relevanta säkerhetskrav vid anskaffning av produkter och system. Följ upp så att dessa krav efterlevs

Photo by Danial Igdery on Unsplash

Uppgradera Google Chrome omgående

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) 
  • CVE-2021-37975 är en user-after-free sårbarhet i V8 JavaScript motorn. Och har klassificerats som mycket allvarlig.

Ä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.

Test av Recorded Future Express

Svensk-grundade företaget Recorded Future har släppt ett browser-plugin som låter dig söka igenom IOC:er (Indicators of Compromise) på webbsidor.

Det kan först låta lite konstigt att man skulle vilja söka igenom webbsidor efter IOC:er men många SIEM-system i dagsläget såsom Moloch och Maltrail (som jag bloggat om tidigare) har webbgränssnitt.

Pluginet finns till Google Chrome, Edge samt Mozilla Firefox och för att använda det måste du registrera dig med en E-post och sedan erhålla en licensnyckel. Denna licensnyckel används sedan för att göra slagningar mot Recorded Futures databas över IOC:er såsom:

  • Checksummer över skadlig kod
  • Kolla upp CVE-nummer och prioritera sårbarheter
  • Domännamn som används för skadliga syften
  • Suspekta E-postadresser (kollar domänerna)

Pluginet är gratis att använda men viss data samlas in av Recorded Future (se nedan). Och har du en betalversion såsom Core eller Advanced så kan du länkas direkt vidare till din dashboard hos Recorded Future.

Nedan skärmdump visar på hur malware-kampanjen vid namn Gamaredon larmar på flertalet IOC:er:

Recorded Future Express
Källa: MalCrawler

Jag upplever det som om det mesta finns med hos Recorded Future och att täckningen är väl över 90% av alla kända IOC:er jag har kollat på.

Dock så finns ett antal URL:er inte med som IOC:er hos Recorded Future såsom denna:

  • message-office.ddns.net

Vilken uppenbarligen finns med på Maltrails IOC-lista över APT Gamaredon (pterodo, primitive bear). Tyvärr identifieras inte heller CVE 2017-0199 på sidan ovan hos MalCrawler. Men på en annan test-sida så identifieras CVE-2017-11882 korrekt (kanske har med bindestreck att göra?).

Här nedan är ett exempel där Checkpoint kollat på flertalet kampanjer och RF Express fångar upp alla IOC:er utmärkt. Du ser en röd eller gul prick till höger om checksumman som Chrome pluginet lägger till.

Här kan du testa Express:

Patch-gapping

Patch-gapping är ett nytt ord på en gammal metod som successivt ökar: Nämligen att utnyttja sårbarheter som åtgärdats av leverantörer, eller är på väg att åtgärdats av leverantörer. Området är närbesläktat med zero-days och patch-gapping kan även gå under benämningen 1-days eller n-days sårbarheter.

Under tiden som leverantören åtgärdar säkerhetsbristen eller det att användare ej uppdaterat sina system eller mjukvaror så finns det ett fönster för att utföra angrepp.

Detta är så klart något som angripare tar till vara på och utvecklar exploits så snart som det finns information om sårbarheter eller säkerhetsfixar. Ett område där detta uppdagas löpande är attacker mot webbläsare.

En av de första att utnyttja och påvisa denna typ av sårbarheter var Halvar Flake som utvecklade BinDiff runt år 2004. BinDiff används framförallt för att granska patchar som släpps av Microsoft och således se vilken kod som ändrats:

Zynamics BinDiff

Mjukvaran BinDiff utvecklades av Halvars företag Zynamics som blev uppköpta av Google och numera kan du gratis ladda hem bindiff. Andra liknande mjukvaror är Diaphora, YaDiff, DarunGrim och TurboDiff.

Men oftast så behövs det inte avancerad binär diffing utan räcker med att läsa changelog samt kolla git-repot eller motsvarande. När det gäller öppen källkod framförallt.

Företaget Exodus Intelligence har skrivit om patch-gapping gällande Google Chrome några gånger.

Följande graf har några år på nacken men visar på det window of opportunity som angriparen har på sig innan användaren uppdaterar till en ny version, i detta fall Google Chrome:

Säkerhetsbrist i Google H1

Google H1

H1 är Googles säkerhetschip som återfinnes i Chromebooks. Andra smeknamn för Google H1 är Cr50 eller G Chip.

Säkerhetsbristen som återfinnes i H1 har och göra med ECDSA signaturgenerering och gör att enbart 64 bitar istället för 256 bitar entropi används för den privata nyckeln. Enligt Google gör detta att det är möjligt för en angripare att återskapa den privata nyckeln:

We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained

Denna ECDSA-nyckel används för U2F-inloggning mot webbplatser som erbjuder multifaktorautentisering. Detta innebär således att:

  • Firmware måste uppdateras i H1-chippet. Detta görs automatiskt från och med ChromeOS 75 som släpptes 26:de Juni 2019
  • Samtliga nycklar måste bytas ut mot de sajter där U2F används för multifaktorautentisering (MFA)
  • Observera att detta enbart gäller om du använt Chromebookens strömknapp för inloggning samt MFA

Du kan även skriva in chrome://system i webbläsaren på din Chromebook och sedan titta efter cr50_version och RW-raden. Version 0.3.15 och senare innehåller ej denna sårbarhet.

Följande meddelande ”Internal security key requires reset” visas för användare som är drabbade av denna säkerhetsbrist:

Detta är så klart en pinsam miss av Google och något som bör fångas upp av tester. Men att denna typ av sårbarheter ökar är något som jag tror vi kommer att få se mer av, det var exempelvis inte länge sedan som Feitian Security Key hade en sårbarhet (på bild till höger).

Bild på chip av Harrison Broadbent på Unsplash

Nya zeroday-priser från Zerodium

Jag skrev detta inlägg på LinkedIn men tänkte dela med mig av denna information även här:

Zeroday-förmedlaren Zerodium har uppdaterat sin prislista. Intressant är att priserna kopplade till Android ökat samt Apple iOS minskat. Vad beror detta på? 🤔

Några av mina gissningar:

✅ Googles arbete med att höja säkerheten i Android har gett utdelning

✅ Större efterfrågan från Zerodiums kunder som vill ta sig in i Android-telefoner

✅ Fler typer av uppkopplade enheter använder Android. Inte bara mobiltelefoner

✅ Det finns redan många iOS-exploits på svarta marknaden

Vad tror du?

Zerodium zero-day priser

Google identifierar ny avancerad attack mot iPhones

Googles Threat Analysis Group (TAG) har identifierat en ny watering hole attack som riktar sig mot iPhone-användare. Attacken är intressant på många sätt, bl.a. så uppger Google att attacken inriktas mot en viss typ av grupp samt att det faktum att fem olika exploit-kedjor används för att ta sig in i iPhones. För en säkerhetsforskare som tar fram en enda exploit-kedja och säljer den till företag såsom Zerodium kan ge upp mot 19 miljoner SEK enligt deras publika prislista.

Gällande exploit-kedjor så anger TAG följande:

seven for the iPhone’s web browser, five for the kernel and two separate sandbox escapes. Initial analysis indicated that at least one of the privilege escalation chains was still 0-day and unpatched at the time of discovery (CVE-2019-7287 & CVE-2019-7286)

När väl dessa sårbarheter utnyttjas så installeras sedan ett implantat som har möjlighet att läsa ut meddelanden ur end-to-end krypterade appar såsom iMessage, Whatsapp och Telegram. Även så kan detta implantat följa iPhone-användaren i realtid via GPS-koordinater som skickas till en Command and Control-server.

Just kommunikationen till C&C-servern går via HTTP och ej HTTPS vilket är annorlunda. Även kan dessa unika strängar användas för att identifiera kommunikation på nätverket:

  • 9ff7172192b7
  • /list/suc?name=

Ovan två förfrågningar går över HTTP GET alternativt POST.

Spekulationer om vem som ligger bakom dessa avancerade attacker riktas mot Kina eller grupperingar kopplade till Kina främst på grund av de omfattande sårbarheterna som utnyttjas mot iPhone samt att företaget Tencent är ett företag vars appar kontrolleras:

  • com.yahoo.Aerogram
  • com.microsoft.Office.Outlook
  • com.netease.mailmaster
  • com.rebelvox.voxer-lite
  • com.viber
  • com.google.Gmail
  • ph.telegra.Telegraph
  • com.tencent.qqmail
  • com.atebits.Tweetie2
  • net.whatsapp.WhatsApp
  • com.skype.skype
  • com.facebook.Facebook
  • com.tencent.xin

Google har själva också varit sparsamma med information gällande implantatet som installeras exempelvis har ingen information om C&C-servrar publicerats. Detta troligtvis eftersom en större utredning pågår av amerikanska myndigheter.

Uppdatering: Enligt källor till TechCrunch är det Uigurer som är målet.