Taggat med: auditd

2023-09-12

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

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:

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.

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

Ö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}

2022-10-18

Så upptäcker ni bakdörrar i IT-system

Att upptäcka bakdörrar i IT-system är ingen lätt match och en mycket bra utvecklad bakdörr är mer eller mindre omöjlig att upptäcka. En bra utvecklad bakdörr har en mycket liten och snäv målgrupp och ligger vilande större delen av tiden. Men det finns givetvis olika metoder och sätt att upptäcka bakdörrar, för förr eller senare så kan misstag eller avvikande beteenden analyseras och påvisa en bakdörr.

Denna guide är främst skriven för att upptäcka bakdörrar som redan är in-planterade. Och hur bakdörrarna kommer in är utanför denna guide, men för att nämna några sätt:

Implanterade från start i servrar eller mjukvara/hårdvara
Via manuella eller automatiska uppdateringar av mjukvara, firmware osv
Man in the middle-attack eller MOTS mot nedladdad mjukvara
Via hackad server eller klient, bifogade filer i mail, sårbarhet i mjukvara
Fysiskt installerad via serverhall eller evil-maid attack
Infekterat PyPi, NPM, CPAN, RubyGem, NuGet-paket
Insider

Klienter och servrar

En vital funktion för att upptäcka bakdörrar på klienter och servrar är att samla in data, det kan röra sig om processer som startar och avslutas, drivrutiner som installeras/avinstalleras, telemetridata. Det är information där en enskild loggrad eller händelse kanske inte säger så mycket, men om den berikas och sätts i ett större sammanhang kan identifiera ett avvikande beteende.

Använder ni Windows-baserade system så är Sysmon ett givet verktyg att använda. För Linux-system så bör man använda verktyg såsom Sysdig Falco och auditd. Eller mer generiska verktyg såsom osquery.

Jag rekommenderar även att titta närmare på Velociraptor som jag bloggade tidigare om. Givetvis bör även binärer, konfigurationsfiler och dylikt hållas koll på med tripwire-liknande funktionalitet. Jobb som körs vid regelbundna intervall såsom cron, AT (Task Scheduler) osv. Eller vid uppstart av mjukvara, system (autoruns).

Nätverk

Jag har tidigare skrivit om RITA som kan underlätta analysen av nätverkstrafik för att hitta beacons som bakdörrar och implantat använder sig av för att kommunicera. Men en väl skriven bakdörr gör detta väldigt sällan och avviker minimalt från normal nätverkstrafik.

Att använda sig av TLSI (TLS Inspection) kan underlätta analysen av TLS/SSL-krypterad nätverkstrafik men det finns givetvis risker också, som bl.a. NSA varnat för. Rekommenderar att titta på PolarProxy som kan hjälpa till med TLSI.

Verktyg som kan hjälpa dig att analysera nätverkstrafik är exempelvis Zeek, JA3/S, Brim, Suricata, Arkime (fd Moloch) och SecurityOnion.

Passivt bör ni också undersöka om system anropar och kopplar upp sig mot kända C&C-servrar, därav viktigt att underhålla aktuella Threat Intelligence-listor med IP-adresser, domännamn etc.

Mängden av data som flödar ut ur era system kan också ge en fingervisning om exfiltration genomförs. Men detta är inte alltid helt enkelt att upptäcka, vid forensiska undersökningar där jag medverkat har jag sett att antagonister delar upp upp information i flertalet 500MB RAR-arkiv som exfiltreras över en längre tid för att undgå upptäckt.

Glöm inte heller att DNS kan användas för kommunikation, som bl.a. SolarWinds Orion SUNBURST-bakdörren gjorde. Även kan Twitter och andra sociala medier eller andra välkända tjänster användas för kommunikation med bakdörren. Steganografi kan också nyttjas för att försvåra upptäckt.

På internet eller fjärrsystem

Att aktivt undersöka vilka fjärrsystem på Internet som anropas kan hjälpa till att förstå om bakdörren pratar med en Command and Control-infrastruktur (C&C). Flertalet olika datakällor såsom Shodan kan användas för att förstå vilket eller vilka målsystem som kommunikationen sker mot.

Ett verktyg såsom JARM kan hjälpa till med detta och skapa unika signaturer. Observera att just aktivt undersöka system på internet kan vara en legal gråzon och undersök noga vad ni har möjlighet att göra.

Avslutande ord

Jag rekommenderar att bygga upp ett antal olika scenarion där ni undersöker vilka möjligheter ni har att upptäcka just dessa metoder. För att ge några exempel:

Log4j JNDI-sårbarheten utnyttjas på ett system mot Internet. Om en bakdörr sedan installeras på detta system, hur kan ni försvåra installation av bakdörren och hur ni upptäcka denna bakdörr?
En mjukvara som automatiskt uppdateras börjar att ”ringa hem” via dess normala kanaler för uppdateringar. Men innehåller nu krypterad data om erat interna nätverk såsom AD-namnet
DNS används för exfiltration
Switchen ni köpte innehåller en Rasperry Pi med WiFi eller 4G-mobildata för exfiltration av intern nätverkstrafik

Vad väntar ni på? Avsätt tid och resurser redan nu för att utveckla förmågan att upptäcka bakdörrar i IT-system. Och givetvis så bör ni också genomföra åtgärder för att försvåra för att bakdörren hamnar i IT-systemet i första taget, och även dess möjligheter att kommunicera ut på internet (eller på andra sätt ringa hem).

Desto mer bakdörren är integrerad i en befintlig komponent i era IT-system desto svårare är det att upptäcka den.

Tack till Erik Hjelmvik för genomläsning och synpunkter!