Taggat med: indicators of compromise

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

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:

Test av MISP, threat sharing

MISP är ett projekt som startades av den belgiska försvarsmakten runt 2011 för att sedan fångas upp och vidareutvecklas av NATO. Projektet är i dagsläget oberoende men finansieras helt eller delvis av CIRCL – Computer Incident Response Center Luxembourg samt EU. Förkortningen MISP stod från början för Malware Information Sharing Project men numera heter projektet enbart: MISP, threat sharing.

Men vad är då MISP kanske du undrar? Jo det är ett verktyg för att underlätta lagring, sökning och kategorisering av cyberunderrättelser, främst olika former av IOC:Er (Indicators of Compromise). Men du kan skriva hela rapporter i MISP:en och länka direkt till IOC:er inom MISP.

När du arbetar mot MISP:en manuellt så kan man säga att du genomför tre steg för att lägga in information om en händelse, eller Event som det heter på MISP-språk. Dessa tre steg är:

  • Skapa Event
  • Lägg till attribut och attachment
  • Publicera eventet

Video som förevisar dessa steg:

Attributen som du kopplar till händelser kan vara checksummor till skadliga filer, textsträngar som återfinnes i exploits, skadlig kod, IP-adresser, domännamn och mycket mer. Här kan du se en lista med samtliga attribut.

Relativt nytt är också att du kan skriva rapporter under event, dessa rapporter kan sedan länka vidare till olika typer av attribut. Rapporterna skrivs i märkspråket markdown.

Exempel på en rapport för Winnti Group:

Och styrkan i MISP är att att dela med sig av denna information. Därav finns det ett avancerat system för vilken information du kan dela med dig av till vem. Det går även att koppla ihop flertalet MISP:ar så dessa synkroniserar information löpande. Även kan MISP:en hämta in olika former av former av feeds i format såsom csv, misp och fritext. Standard så följer 63 olika externa feeds med i MISP som du kan slå på.

Du kan sedan konfigurera dina säkerhetssystem att hämta IOC:er från din lokala MISP, det finns exempelvis stöd i Zeek (fd Bro). Även kan du koppla MISP mot andra system såsom OpenCTI, TheHIVE och MITRE ATT&CK.

När jag testade att starta upp en instans av MISP så var detta mycket enkelt med hjälp av Docker. Men tänk på hur du publicerar din MISP-instans mot internet, för sårbarheter finns det gott om i MISP. Bara detta året har 15 st CVE:er publicerats, men om detta är ett bra mätetal för säkerhet är en helt annan diskussion.

Om Er organisation verkar inom en viss bransch så rekommenderar jag att ni sätter upp en gemensam MISP inom just Er bransch. Men tänk också på att ni måste ha kompetens och en förmåga att underhålla och lägga in information i MISP:en. Här i Sverige har exempelvis Sunet en MISP-installation som Sunet-anslutna lärosäten kan använda sig av.

Är ni en stor organisation med egen ThreatHunting-kapacitet eller en CERT så kan det också vara läge att sätta upp en egen MISP där ni kan lägga in IOC:er och bygga upp er CTI, Cyber threat intelligence.

För API kan man använda PyMISP eller REST-gränssnittet, här testar jag en sökning med hjälp av curl och söker efter 89.203.249.203:

Svaret returnerar ett event info som säger Benkow.cc RAT feed.

Under huven så drivs MISP av en PHP-baserad applikation som använder sig av Apache, MySQL och Redis. MISP:en stödjer även ZeroMQ, Yara och kan exportera/importera STIX 1+2.

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:

Threat Hunting med Bro, Critical Stack och AlienVault OTX

Threat Hunting eller Cyber Threat Hunting som det också kallas har varit ett modeord inom cybersäkerhetsbranschen sedan några år. Och förra året så skrev jag på LinkedIn om vad det är för något. Kort och gått så jobbar du efter en eller flera teser och försöker identifiera antagonister i dina IT-system.

I denna guide tänkte jag gå igenom hur du med hjälp av Bro samt threat-feeds från Critical Stack samt AlienVaults OTX.

AlienVault OTX

Open Threat Exchange (OTX) är en tjänst där du kan dela med dig av Indicators of Compromise (IOC). Jag har exempelvis lagt upp IOC:er för domännamn som anropas från en bakdörr som återfinnes i ett Chrome Extension. Tjänsten är gratis att använda och har ett API där du kan med hjälp av en API-nyckel ladda hem IOC:er som andra eller du själv har lagt upp.

Critical Stack

Intel Feed från företaget Critical Stack är också en gratis tjänst där du kan ladda hem en aggregerad lista med IOC:er. Denna lista som du ladda hem innehåller flertalet andra listor som du själv väljer. Och upp till 160 olika listor finns att välja på hos Critical Stack. Jag har valt 155 st där jag aktivt har valt bort fem stycken listor som ger false-positive larm:

  • hosts-file.net Ad/Tracking Domains
  • sysctl.org Domain Blocklist (Ads)
  • Known Tor Exit Nodes
  • hosts-file.net Misleading Marketing Domains
  • torproject.org Official Exit Node List

Installation

Denna guide förutsätter att du redan har open-source IDS:en Bro installerat. Du kan exempelvis använda min favorit, Linux-disten Security Onion där Bro finns färdiginstallerat.

Jag har inför denna guide sparat ner PCAP-filer för ungefär ett års datatrafik där jag kommer att gå igenom samtliga filer efter indikatorer från listorna ovan. Men du behöver inte köra mot nersparade pcap-filer, för listorna går även att köra direkt mot realtidstrafik i Bro.

Installation Critial Stack

Du kan antingen köra den mer osäkra vägen via Packagecloud eller installera deb-paktet:

curl https://packagecloud.io/install/repositories/criticalstack/critical-stack-intel/script.deb.sh | sudo bash

Eller:

wget https://intel.criticalstack.com/client/critical-stack-intel-arm.deb
sudo dpkg -i critical-stack-intel-arm.deb

Sedan måste du skapa ett konto på Criticalstack för i nästa steg ska du skriva in din API-nyckel (key)

sudo -u critical-stack critical-stack-intel api abc-123API-nyckel

Nedan skärmdump påvisar förfarandet då jag laddar hem den aggregerade listan och skriver samtliga IOC:er till filen master-public.bro.dat

För att sedan uppdatera löpande så kan du lägga ett cron-jobb för att uppdatera eller manuellt köra:

sudo -u critical-stack critical-stack-intel pull

Vi kan sedan verifiera hur många IOC:er vi fick hem genom att kontrollera antalet rader i

$ wc -l /opt/critical-stack/frameworks/intel/master-public.bro.dat
81442 /opt/critical-stack/frameworks/intel/master-public.bro.dat

Och indikatorerna är uppdelade på följande typer:

  • 42815 st Intel::DOMAIN
  • 37097 st Intel::ADDR
  • 1043 st Intel::FILE_HASH
  • 477 st Intel::URL
  • 4 st Intel::FILE_NAME
  • 1 st Intel::EMAIL

För mer information om Bro:s Intelligence Framework kan du läsa här.

Installation Alienvault OTX

Först registrerar du dig för ett gratis-konto och får sedan tillgång till en API-nyckel. Sedan klonar vi ner ett projekt från Github som heter Alienvault OTX Bro IDS Connector. Viktigt här är att vi klonar ner projektet till rätt katalog.

Eller så kör vi detta script som automatiserar förfarandet:

wget https://raw.githubusercontent.com/weslambert/securityonion-otx/master/securityonion-otx

sudo bash securityonion-otx

Om allt går vägen så laddas IOC:erna hem till filen otx.dat och vi kan kontrollera antalet rader:

securityonion$ wc -l /opt/bro/share/bro/policy/bro-otx/otx.dat
 39015 /opt/bro/share/bro/policy/bro-otx/otx.dat

Och kollar vi på uppdelningen gällande vilka typer så skiljer det sig något mot Critical Stacks indikatorer:

  • 17354 st Intel::DOMAIN
  • 15018 st Intel::FILE_HASH
  • 5969 st Intel::URL
  • 594 st Intel::ADDR
  • 75 st Intel::EMAIL

Analysera PCAP-filerna

Nu är det bara sista steget kvar och det är att köra bro direkt mot pcap-filerna. Jag brukar göra ett enkelt shellscript på 4-5 rader som loopar igenom alla sparade pcap-filer och skapar en ny katalog för varje dag (om du lagrar en fil per dag).

En av fördelarna med att köra Bro istället för att enbart titta på käll- och destinations- IP-nummer är att Bro avkodar och tittar i protokoll. Såsom om certifikatet i en TLS-förbindelse har ett CN (CommonName) som matchar en IOC.

Jag kör Bro med följande argument:

time bro -r filnamn.pcap local "Site::local_nets += {10.0.0.0/8}"

Jag hoppas att denna guide kan hjälpa dig att identifiera intrång. Du kommer troligtvis även att behöva filtrera bort en hel del falska positiva larm.

Identifiera Projekt Sauron (Remsec)

Detta är en guide till hur Er organisation kan identifiera den senaste avancerade skadliga koden vid namn Projekt Sauron.

Förutom att uppdatera antivirus med senate databaser så kan du även titta på nätverkstrafik för att se kommunikation till kontrollservrar (C&C). Ett till alternativ är att söka efter så kallade IOC:er (indicators of compromise).

IOC:er kan vara hashsummor, text-strängar, IP-adresser, URL:ar och mycket mer. Man kan säga att det är en typ av signaturer som är öppna, till skillnad från många antivirus-databaser som är stängda (förutom clamav).

Det finns ett antal gratis verktyg för att söka efter IOC:er samt ett antal olika öppna sammanställda listor med IOC:er.

Exempel på en IOC som identifierar Powershell verktyget Invoke Mimikatz:

Invoke Mimikatz Powershell

Ovan regel använder sig av Yara-formatet som är C-liknande. Yara är även ett öppet verktyg samt bibliotek till Python.

Följande metodik är framtagen av OpenIOC-projektet.

IOC metodik

lokiOch som du kan se av ovan process så är tanken att IOC:er snabbt ska gå att applicera i en mängd olika mjukvaror såsom IDS/IPS, SIEM, nätverket eller lokalt på en klient/server.

För att försöka identifiera Projekt Sauron så laddar jag hem först Loki-scannern:

wget https://github.com/Neo23x0/Loki/raw/master/loki.exe

Och sedan senaste signaturbiblioteket:

wget https://github.com/Neo23x0/signature-base/archive/754d19604d7c36580a3f254f341d220343ca9bdd.zip

Sedan måste du se till att hash-summan för loki.exe är korrekt samt att katalogstrukturen är korrekt. Sha256:

99239b002d76ea81fe239de2ad4d8fef4157ea0759a39e777a68e050df580342

Annars får du ett felmeddelande likt detta om katalogstrukturen är felaktig:

Traceback (most recent call last):
 File "<string>", line 811, in initialize_filename_iocs
WindowsError: [Error 3] The system cannot find the path specified: 'E:\\./signat
ure-base/iocs/*.*'
Traceback (most recent call last):
 File "<string>", line 1253, in <module>
 File "<string>", line 119, in __init__
 File "<string>", line 860, in initialize_filename_iocs
UnboundLocalError: local variable 'ioc_filename' referenced before assignment

När allt väl är på plats så är det bara att starta genomsökningen. Förslagsvis som en användare med behörighet att läsa processer och filer (Administratör):

LOKI IOC Scanner

Sen är det bara att vänta. En genomsökning kan ta flera timmar för en enda klient eller server.

När den är klar söker du efter följande text:

[RESULT] Indicators detected!
[RESULT] Loki recommends checking the elements on Virustotal.com or Google an
riage with a professional triage tool like THOR APT Scanner in corporate netw
s.
[NOTICE] Finished LOKI Scan SYSTEM: IE9WIN7 TIME: 20160813T10:53:49Z

Håll även koll på falska positiva (false-positives) indikationer. Windows sökverktyg SearchIndexer.exe gillar exempelvis att indexera upp dina signaturer och kan göra så att Loki varnar.

Loki arbetar med följande kontroller:

1. Filnamns IOC:Er
Regex-matchning på sökväg eller namn

2. Yara Regelkontroll
Yara signaturkontroll på fil eller process (minne)

3. Hashkontroll
Jämför hashar i en mängd olika format (MD5, SHA1, SHA256)

4. C2 kontrollkanal
Kontrollerar anslutningspunkter mot C2 IOCs (nytt sedan Loki version 0.10)

Och även följande presentations-bild från företaget Mandiant FireEye beskriver en indikator bra:

whats-an-indicator-copy_1

Senare kommer jag även gå igenom hur du använder verktyget Volatility för offline-analys, en av mina favoriter.

Denna guide fungerar för att identifiera nästan all skadlig kod, bara man vet vad man söker efter. Givetvis så bör även nätverkstrafik kontrolleras, men i fallet med Sauron så finns det ännu inga DNS-namn eller IP-adresser ut som man kan kontrollera för kommunikation och kontrollkanaler (C&C).

Och så klart underlättar nätverksforensik om du redan sparar undan DNS-uppslag eller all trafik som flödar ut/in på nätverket med trafikinspelning, något jag rekommenderar.

Värt även att poängtera är att när du exekverar kod såsom Loki i enlighet ovan så kan även detta innebära en säkerhetsrisk.

Men att kontrollera mot filnamn, hashsummor och annat är sådant som är statiskt. Antagonisten kommer bara att ändra sådant när hen blir upptäckt. Därför är det även bra att lära sig metoderna som nyttjas och kontrollera dessa.