Taggat med: IOC

Guide till säkrare containers

Guide till säkrare containers

Senast uppdaterad 2023-09-22

Att containers har blivit en del av många organisationers vardag råder det ingen tvivel om. Med hjälp av populära verktyg såsom Docker, Podman eller Kubernetes (K8s) så realiserar dessa en containerbaserad infrastruktur och applikationsdistribution.

Det är av stor vikt att hålla dessa säkra och nedan följer en guide hur du kan minska risken för eventuella cyberattacker.

Minska attackytan

Först och främst gäller det att minska attackytan. Detta för att minska risken, och att uppnå en 100%-ig säkerhet är så klart helt omöjligt. Men hur gör man för att minska attackytan? Jo det består i flertalet saker:

  • Använd användare med låga behörigheter inne i containern. Kör rootless utanför om möjligt
  • Använd en container till ett syfte. Dvs inte både webbserver och databas, exponera eller installera ej sshd inne i en container
  • Exponera minimalt med kataloger, sockets eller annat mellan containers och mot värden (operativsystemet som kör containers) och vice versa
  • Stäng av sådant som inte behövs, såsom nätverk. Kan stängas av med: –network none
  • Utgå från minimala containers såsom -slim och distroless
  • Skydda API:et eller socketen för att kommunicera med din containermjukvara såsom Podman, Docker osv. Dvs podman.socket och /var/run/docker.sock samt TCP-portarna 2376/2375
  • Håll dockerd, podman etc uppdaterat och även containers
  • Undvik argument såsom : –privileged och –cap-add då dessa öppnar upp för ”container escape” sårbarheter

Attacker via mjukvarukedjan (supply chain)

Ladda inte hem och använd godtyckliga containers, utan utgå ifrån sådana som är signerade och verifierade. Använd verktyg såsom cosign och docker trust för att verifiera. Det har hänt flertalet gånger att containers innehåller bl.a. crypto-miners.

Exempel på hur docker trust inspect kan användas för att validera alpine:latest

dock trust inspect alpine:latest

Och för cosign där jag verifierar distroless python3-debian11:

Även om containers är signerade så är det givetvis ingen garant för att den innehåller bakdörrar.

Loggning och spårbarhet

Det är av stor vikt att logga även sådant som händer i containers. Det vanligaste sättet är att skriva loggarna till stdout och sedan fånga upp detta. Viktigt är att centralt samla in loggarna och analysera dessa ytterligare efter avvikande mönster, kända attacker osv.

Även så finns det verktyg såsom Sysdig Falco eller auditd som kan kontrollera beteendet på dockerd eller inviduella containers. Exempel på hur audit.rules kan se ut för docker:

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

Glöm inte heller att logga och analysera nätverkstrafik som går in/ut ur respektive container, använd Suricata, Zeek eller Arkime. Försök att skilja på applikationsloggar, operativsystemsloggar, prestandaloggar etc. Även om alla är viktiga så har alla sina unika mönster för att identifiera intrång. Andra saker som kan skilja är hur länge du vill lagra dessa.

Sårbarhetsskanning

Det finns många bra verktyg för att genomföra sårbarhetsskanning av containers. Dels det inbyggda kommandot docker scout (tidigare docker scan som använde Snyk) och dels tredjepartsverktyg såsom trivy och grype.

Jag tänkte göra en snabb jämförelse mellan dessa tre enligt nedan.

Trivy

Jag använder en test-image vid namn hello-python. Sedan kör jag kommandot:

trivy image hello-python

Då identifierar den tre sårbarheter i python-paket och 47 st i alpine 3.11.5:

trivy container vulnerability scan

Grype

För att skanna av en container med grype kör jag kommandot:

grype hello-python

Och då hittar den enligt nedan. Totalt blir det 118 kända sårbarheter som identifieras, vilket är flest antal av de tre verktyg jag testar. Men dock räknar jag antalet CVE:er och GHSA:s individuellt så blir det 81 st.

grype docker vulnerability scan

Docker Scout

Kör jag med senaste versionen av docker scout, som tyvärr måste laddas hem separat då nyaste versionen ej ingår i Docker Desktop så hittar den 67 sårbarheter i 12 paket.

Även Docker Scout identifierar tre sårbarheter i python-paket (pypi). Kommandot jag använder är:

./docker-scout cves hello-python
docker scout vulnerability scan

Övrigt

Kan även rekommendera att titta på lösningar såsom Kata och Gvisor som tillför ett extra lager med säkerhet i Er container-miljö.

Vissa IT-forensiska utmaningar kan också uppstå i en container-baserad miljö. Se därför till att öva på olika scenarion där en container eller dess host-operativsystem drabbats av intrång, eller möjlighet att söka efter IOC:er (Indicators of Compromise).

Fick tips om att UFW ej fungerar tillsammans med Docker. Även en rekommendation om att skapa upp SBOM:s för alla dina containers, som jag bloggat tidigare om.

Se även över om ni kan upprätta ett eget container-index och således få en bättre överblick över vilka containers om används inom organisationen.

Bild skapad med Midjourney

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

FBI skickar ut flash gällande Hive ransomware

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
  • Följ sajter såsom StopRansomware.org

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:

https://anonfiles.com 
https://mega.nz 
https://send.exploit.in 
https://ufile.io 
https://www.sendspace.com 

Här kan du ladda hem rapporten som PDF:

Säkerhetsföretaget FireEye hackade

FireEye

FireEye som är ett av världens största säkerhetsföretag gick i förrgår ut med information om att dom blivit hackade. Enligt dem så har ingen information om kunduppgifter komprometterats vad de identifierat ännu men om så skulle vara fallet så har dessa kunder kontaktas direkt.

Att ge sig på och hacka säkerhetsföretag är ingen direkt nyhet och har hänt flertalet gånger tidigare. Bl.a. Kaspersky identifierade ett intrång 2015.

Det som däremot FireEye har gått ut och bekräftat som stulet (exfiltrerat) är deras verktyg som används vid penetrationstester och Red-Teaming. Inga zero-days har används eller blivit stulna, vilket är bra. Jag förvånas också över mängden verktyg, över 200 st som de blivit av med.

De som ligger bakom attacken är en avancerad angripare som kan mätas eller är en statlig aktör uppger företaget. FireEye som själva jobbar med att utreda intrång skriver att de aldrig sett denna typ av avancerade angreppsvektorer tidigare. Även FBI bekräftar denna bild som förmedlas. Följande kommentar var rätt intressant också:

Consistent with a nation-state cyber-espionage effort, the attacker primarily sought information related to certain government customers

Tyvärr verkar inte FireEye släppa några IOC:Er som hjälper att identifiera angriparna. Enligt bl.a Dave Kennedy så pekar på att det är Ryssland som ligger bakom attacken, bl.a baserat på att FireEye tidigare avslöjat ryska cyberoperationer. Utredningen pågår fortfarande och mer information kommer förhoppningsvis längre fram.

Kevin Mandia som är VD på FireEye kommenterar följande i press-releasen:

På GitHub har man lagt upp signaturer i form av IOC:er för att känna igen de verktyg som stulits och jag har kollat på verktygen och det ser ut att vara branschpraxis-verktyg såsom BloodHound (CoreHound), SafetyKatz (Mimikatz) och egna såsom Sharpersist och Sharpivot. Mycket är baserat på .Net men även så finns det Python, Rust och programspråket D.

Intressant också att det finns kod som heter matryoshka.rs (Rust) och just matryoshka kan ju vara rätt allmänt använt eftersom matryoshka är en rysk trädocka i flertalet dockor inuti. Men också namnet på en iransk hackinggrupps RAT, CopyKittens.

Här kan du ladda hem en sammanställning med verktygen i Yara-format: