Taggat med: TLSI

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

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.

bakdörr IT-system skadlig kod

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!

Identifiera cyberintrång med Moloch

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:

Tre unika HASSH (bilden är maskad)

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.

NSA varnar för TLS-inspektion

NSA

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:

Bild från NSA

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