2020-03-23

Identifiera cyberintrång med Moloch

Uppdatering 2020-11-20: Moloch har nu bytt namn till Arkime. Läs mer om bakgrunden till namnbytet här.

Jag har haft på min todo-lista ända sedan det första släppet av Moloch som var år 2012 att jag ska testa verktyget. Moloch utvecklades innan 2012 internt hos AOL men släppte det sedan fritt för allmänheten. Dock så dröjde ända tills November 2019 innan jag fick bekanta mig mer med verktyget.

Moloch är ett verktyg som låter dig göra indexerade sökningar i stora mängder data. Säg exempelvis att du lagrar många hundra terabyte av PCAP-data och vill hitta vilka datorer på ditt nätverk som pratat med en viss IP-adress. Att göra en sådan sökning i mängder med PCAP:s kan ta otroligt lång tid. Du kan så klart använda Argus-metadata för att snabba upp sökningen men Moloch är mer användarvänligt samt avkodar information om varje protokoll också, som så klart också är sökbart.

Som backend använder Moloch sökmotorn Elasticsearch som är skriven i Java. Även så tillför Moloch ett snyggt webbgränssnitt och ett REST-API.

Förutom själva webb-gränssnittet så finns även mjukvaran moloch-capture med som antingen kan importera PCAP-filer offline eller läsa av data direkt från ett interface.

Du kan även enkelt tagga upp information från andra system såsom Maltrail eller Suricata och sedan se dessa taggar eller söka på taggarna i Moloch via API:et eller verktyget som följer med:

capture/plugins/taggerUpload.pl localhost:9200 ip iptagdata tag tag .. tag
capture/plugins/taggerUpload.pl localhost:9200 host hosttagdata tag ..
capture/plugins/taggerUpload.pl localhost:9200 md5 md5tagdata tag
capture/plugins/taggerUpload.pl localhost:9200 email emailtagdata tag
capture/plugins/taggerUpload.pl localhost:9200 uri uritagdata tag

Det jag gillar mest med Moloch är att den kan avkoda ett antal olika protokoll såsom DNS, SSH, HTTPS, HTTP, DHCP, radius, socks osv.

För att ge ett exempel på en av många Threat Hunting teser du kan köra:

Vilka unika HASSH klient fingerprint SSH finns det och vart ansluter dom?

Så steg ett är att exportera dessa, exempelvis genom att gå på SPI-vyn och sedan Export unique HASSH. Då öppnas en ny länk med följande tre HASSH-fingerprints:

Sedan klickar jag på Sessions-fliken och kan söka på sessioner med någon av dessa unika HASSH-fingerprints:

Sökning på en unik hassh i Moloch, bilden är maskad.

Om du är observant så ser du även att det finns en flik som heter Hunt. Den kan användas för att göra klartext-sökningar med intervaller, tyvärr inte så användbar om du inte kör TLSI (TLS Inspection).

Du kan även lägga upp något som heter Cron-queries som körs vid intervaller som sedan skickar notifieringar via Slack, E-post eller Twilio.

Sammanfattning Moloch

Verktyget är gratis att använda och stödjer Er verksamhet i att analysera nätverkstrafik. Det är ingen hög inlärningströskel och kan snabba upp arbete som i dagsläget kanske är mindre effektivt.

Moloch kompletterar andra open-source verktyg såsom Zeek och Suricata mycket bra.

Även har Moloch möjlighet att exportera data som PCAP från sessioner, vilket gör det enklare också om du vill analysera en händelse ytterligare med exempelvis Wireshark.

2019-11-23

NSA varnar för TLS-inspektion

Amerikanska säkerhetsmyndigheten NSA går nu ut och varnar för Transport Layer Security Inspection (TLSI). Anledningen till att NSA nu varnar för TLSI är för att metoden att granska nätverkstrafik som går in och ut ur organisationer blir allt vanligare samt att denna metod även medför ett antal olika säkerhetsrisker.

Några anledningar till att TLSI blir allt vanligare är för att kontrollera att nätverkstrafiken inte innehåller någon form av skadlig kod eller att klienter kommunicerar med skadliga webbplatser eller Command and Control-servrar (C&C). Denna form av inspektion kan också förekomma i enheter såsom Deep Packet Inspection (DPI) eller NIDS/IDS, Network Intrusion Detection Software.

Exempel på hur det kan se ut med och utan TLS-inspektion:

Problemen som NSA pekar på

Men vilka problem är det då som kan uppstå med denna set-up? Jo det finns flertalet problem som jag tänkte gå igenom här:

Validering av certifikat – Tidigare undersökningar visar på att certifikatvalideringen i TLSI-enheter inte varit 100%-ig och detta ökar risken för bl.a. man-i-mitten attacker.

Algoritmer och SSL/TLS-versioner – Precis som förra punkten så kan brister i SSL/TLS-handskakningen eller val av algoritmer påverka säkerheten såsom nedgraderingsattacker.

Tillgången till klartext – Det finns en punkt i organisationen där någon kan läsa och modifiera klartexttrafik. Detta är ett problem ur säkerhetssynpunkt men även integritet. Ett intrång kan även leda till att klartexttrafik kan läsas.

Insiderhotet – En person som har tillgång till trafiken kan läsa ut lösenord. Se till att ha en särskild granskningsroll som kan se vad TLSI-administratörerna gör för något.

Observera också att en TLSI kan användas både för utgående trafik från klienter men även inkommande (reverse proxy) för exempelvis webbsajter. Värt att nämna här är även den sårbarhet i F5:s produkter som Christoffer Jerkeby hittade. Vill du själv testa TLSI så kan jag rekommendera Erik Hjelmviks PolarProxy.

En annan sak som NSA lyfter i rapporten är även att du bör undvika att bädda in flertalet produkter där din klartext flödar. Försök att hålla ner komplexiteten för riskerna ökar med antalet produkter samt så försvåras felsökning. Certifikatspinning kan också bli ett problem samt så påpekas att HTTP Strict Transport Security (HSTS) inkluderar stöd för att binda en TLS-session(?).

Rapporten från NSA kan du hitta i sin helhet här:

NSA tls rapport — MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION

Källa: NSA