Taggat med: Shodan

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!

Tips för att höja cybersäkerheten

Tips för att höja cybersäkerheten

Med anledning av senaste tidens händelser och en ökad hotbild på cyberarenan så tänkte jag passa på att skriva ner några bra tips och råd på hur Er organisation kan höja cybersäkerheten.

Cyberresiliens och överbelastningsattacker

Er hemsida kan utsättas för överbelastningsattacker eller DDoS som det också brukar kallas. Antagonisten kommer att försöka identifiera kritiska punkter och skicka anrop om och om igen till dessa. Därför är det viktigt att se över hela den exponering som återfinnes mot Internet. Glöm inte API:er, subdomäner, DNS, SMTP osv.

Se till att ha en nödsajt samt alternativa vägar för att kommunicera inom Er organisation. Om internetförbindelsen går ner till Er organisation eller om tjänster såsom Slack går ner på grund av ökad belastning, hur kan ni då kommunicera? Om ni använder tjänster såsom Cloudfront, Akamai eller Cloudflare, se då till att den bakomliggande infrastrukturen inte går att nås via utanför dessa tjänster.

Internetexponering

Att veta hur organisationen ser ut från internet är otroligt viktigt. För det är just på dessa exponerade punkter som antagonisten kommer att fokusera först på. Kontrollera därför Er domän eller IP-adresser mot följande tjänster:

360PassiveDNS, ARIN, Ahrefs, AlienVault, AnubisDB, BinaryEdge, BGPView, BufferOver, BuiltWith, C99, Chaos, CIRCL, Censys, CommonCrawl, DNSdumpster, DNSDB, DNSlytics, DNSRepo, Detectify, FOFA, FullHunt, GitHub, GitLab, Greynoise, HackerTarget, Hunter, IntelX, IPdata, IPinfo, Maltiverse, Mnemonic, N45HT, NetworksDB, ONYPHE, PassiveTotal, PentestTools, Quake, RADb, Robtex, SecurityTrails, ShadowServer, Shodan, SonarSearch, Spamhaus, Spyse, Sublist3rAPI, TeamCymru, ThreatBook, ThreatCrowd, ThreatMiner, Twitter, Umbrella, URLScan, VirusTotal, WhoisXMLAPI, ZETAlytics, ZoomEye.

Eller använd OAWSP amass som gör det automatiskt. Använd DNS Anycast och försök att fronta via CDN och WAF. Även om jag inte är ett stort fan av Web Application Firewalls så kan det vinna Er några timmar.

Autentisering

Denna punkt har också att göra med ovan punkt. Dvs identifiera alla exponerade delar mot internet där en användare kan autentisera sig. Här är det otroligt viktigt att använda flera lager av skydd, jag rekommenderar att använda VPN som omslutning för allt. Och se till att också använda tvåfaktorsautentisering med hårdvaru-tokens såsom Yubikeys och certifikat.

Så kortfattat: Exponera inget mot internet som går att köra över VPN. Se till att den som ansluter via VPN inte kommer åt mer än nödvändigt, tänk zero-trust arkitektur.

Patchning och uppdatering

Om möjligt, se till att systemen uppdaterar sig själva automatiskt med nya säkerhetspatchar. Men var också medveten om att det finns möjlighet för bakdörrar att sig sig in den vägen. Dvs gör ett noga övervägande om för respektive nackdelar med automatiskt säkerhetspatchning. För majoriteten så är detta rätt väg att gå men inte något för alla.

Patcha inte bara mjukvaror, glöm inte heller switchar, skrivare, firmware och annat som också måste uppdatera. Och håll koll på om produkter eller system börjar närma sig End-of-Life och vad ni har för möjligheter då.

Har ni system som är äldre och som inte går att uppdatera men som ni ändå är beroende av, se till att isolera dessa extra noga. Exempelvis ett eget segment i nätverket där allt är filtrerat in och ut samt en speciell jump-host måste användas för att komma åt detta gamla system.

Härda systemen och se till att enbart mjukvaror som används exponeras eller är påslagna.

Övervaka, öva och testa

Testa säkerheten kontinuerligt med automatiska testverktyg såsom Holm Security, Detectify eller Nessus. Anlita konsulter som gör återkommande manuella penetrationstester samt genomför kodgranskning löpande om ni utvecklar mjukvara.

Öva på att återställa backup och se till att backuperna lagras offline eller på annat sätt icke åtkomliga från den ordinarie IT-infrastrukturen.

En komprometterad klient kan snabbt leda till att hela Er Windows AD-miljö blir övertagen. Se därför till att ni snabbt kan detektera om en klient börjar att bete sig suspekt. Har ni inte förmågan själva så se till att anlita ett företag som är experter på SIEM/SOC. Och vad gör ni när ni upptäcker något suspekt eller blivit utsatta för intrång, då är det bra att redan ha upparbetade kontaktvägar eller plan hur delar ska isoleras för att begränsa skada.

Glöm inte att allt ni ansluter kan producera loggfiler och hjälpa till att upptäcka intrång, syslog har funnits med länge och går att slå på och använda på nästan allt som kopplas upp.

Sammanfattning

Sist men inte minst, det ni inte känner till kan ni inte heller skydda. Se därför till att inventera och ha en god koll på vilken utrustning ni har, såväl mobiltelefoner, servrar, laptops och annat.

Administrativa konton bör användas ytterst begränsas och om möjligt med dubbelhandsfattning, tidsbegränsat eller liknande. Inventera dessa konton kontinuerligt.

Se också över beroendet gällande leverantörer, underleverantörer och tredjepartsberoenden. Upprätta en SBOM eller liknande. Jobba långsiktigt och systematiskt med cybersäkerheten och genomför omvärldsbevakning löpande, jag själv använder Twitter som en källa.

FRA FMV Försvarsmakten Säkerhetspolisen Polisen Post och Telestyrelsen MSB

Relevanta myndighetsdokument att läsa vidare:

Qualys identifierar 21 sårbarheter i Exim

Det amerikanska cybersäkerhetsföretaget Qualys har identifierat 21 st sårbarheter i mail-servermjukvaran Exim. Tre av dessa 21 sårbarheter lyckades Qualys utnyttja som RCE:er (Remote Code Execution). Vilket är synnerligen allvarligt. Rekommenderat är att uppgradera till senaste versionen av Exim som i skrivande stund är 4.94.2.

RCE-sårbarheterna medger att en antagonist kan erhålla rättigheter över nätverket som exim-användaren. Det är inte heller första gången som Qualys hittar RCE:er i Exim. För 2019 så hittade man även ”return of the Wizard RCE”. En sårbarhet som utnyttjas av ryska hackergrupperingen Sandworm.

Tittar vi på en sökning med Shodan.io så hittar vi ca 1.7 miljoner sårbara installationer varav ca 7000 är i Sverige (länk).

Sårbarheterna är enligt följande:

- CVE-2020-28007: Link attack in Exim's log directory
- CVE-2020-28008: Assorted attacks in Exim's spool directory
- CVE-2020-28014: Arbitrary file creation and clobbering
- CVE-2021-27216: Arbitrary file deletion
- CVE-2020-28011: Heap buffer overflow in queue_run()
- CVE-2020-28010: Heap out-of-bounds write in main()
- CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
- CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
- CVE-2020-28015: New-line injection into spool header file (local)
- CVE-2020-28012: Missing close-on-exec flag for privileged pipe
- CVE-2020-28009: Integer overflow in get_stdinput()
Remote vulnerabilities
- CVE-2020-28017: Integer overflow in receive_add_recipient()
- CVE-2020-28020: Integer overflow in receive_msg()
- CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
- CVE-2020-28021: New-line injection into spool header file (remote)
- CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
- CVE-2020-28026: Line truncation and injection in spool_read_header()
- CVE-2020-28019: Failure to reset function pointer after BDAT error
- CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
- CVE-2020-28018: Use-after-free in tls-openssl.c
- CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()

Du kan läsa advisoryn från Qualys i sin helhet här:

Shodan Monitor

Shodan Monitor

Shodan är en onlinetjänst som har funnits sedan 2009 och söker kontinuerligt av hela internet med omfattande portskanningar. Tjänsten är omtyckt och ger bra statistik samt har en sökfunktion som visar sådant som organisationer exponerar mot internet.

För några veckor sedan så släppte Shodan en ny intressant funktion som går under namnet Shodan Monitor. Med hjälp av Monitor kan Er organisation övervaka den internet-exponering ni har och få notifieringar över händelser.

Även för mig som konsult kan detta vara intressant då jag kan övervaka mina kunder och meddela dem om något nytt suspekt dyker upp eller som ett OSINT-verktyg vid RedTeam och penetrationstester.

Det går att lägga upp nya nät och övervaka via webbgränssnittet som återfinnes på monitor.shodan.io eller direkt via CLI och det python-program som Shodan tillhandahåller (byt ut APIKEY mot din nyckel och ALERTID mot det ID som returneras)

sudo pip install shodan
shodan init APIKEY
shodan alert create "My Production Networks" 198.20.0.0/16 8.20.5.0/24
shodan alert triggers
shodan alert enable ALERTID malware

När du skriver shodan alert triggers så kan du se vilka larm du kan slå på eller av. Listan ser ut enligt följande:

Du kan även ange ”any” och då får du larm för samtliga ovan kategorier:

shodan alert enable ALERTID any

Innan du kan övervaka några IP-nummer så måste du först bli betalande medlem. Jag valde den nivå som heter Freelancer och gör att jag kan lägga upp övervakning 5120 IPs och kostar 59$ per månad (ca 560 kr). Övriga nivåer är enligt följande:

  • $299 /månad (2 865 sek) ger dig 65536 IPs
  • $899 /månad (8 614 sek) ger dig 300000 IPs

Efter några timmar dyker det första larmet upp i min E-post. Relativt ointressant men som tur var så finns det även en möjlighet att vitlista vissa portar, så här ser mailet ut:

Och längst ner så finns länken ”Ignore this event in the future”.

Andra användningsområden för Shodan Monitor kan också vara för nät som ingår i Bug Bounty-program. Du får även använda tjänsten i kommersiellt syfte.

Samtliga argument till shodan alert för den som kör med python-mjukvaran:

Det är även möjligt att erhålla realtidsdata via shodan stream på följande sätt:

Video med demo:

Threat Hunting med Maltrail

Maltrail är en open-source mjukvara för att upptäcka skadlig kod, skriven i programspråket python. Mjukvaran består av en serverdel och en klientdel som kan köras fristående.

Maltrail kan titta på nätverkstrafik och larma om något av följande matchar någon av de medföljande listorna:

  • HTTP Host Headers
  • DNS-uppslag
  • IP-adresser
  • URL
  • User-agent

För att installera Maltrail så klonar du bara hem Git-repot och installerar beroenden såsom python-pcapy. Jag kör dessa tester på en Raspberry Pi och det fungerar fint.

Och när du startar upp Maltrail för första gången så laddas 68 stycken olika publika listor hem med IOCer:

Förutom att sniffa nätverkstrafik direkt mot ett interface så kan köra sensor.py mot en pcap-fil på följande sätt:

$ sudo python sensor.py -i /data/pcap/trace_2018-12-15_14.54.33.pcap

Och vill du se vad som larmar direkt till konsollen kan du starta Maltrail på följande sätt med –console:

sudo python sensor.py -i /data/pcap/trace_2018-12-15_14.54.33.pcap --console

En annan sak som jag noterar är att dessa 68 st listor som laddas hem innehåller hela 1 396 712 st IOC:er.

Det pcap-filter som används som standard är enligt följande:

udp or icmp or (tcp and (tcp[tcpflags] == tcp-syn or port 80 or port 1080 or port 3128 or port 8000 or port 8080 or port 8118))

Vilket den observanta läsaren kan se att HTTPS tcp port 443 exempelvis inte finns med, dock all ICMP och UDP. Som standard kontrollerar inte maltrail http-host headern men detta kan snabbt ändras i maltrail.conf som du bör ta en titt på. Du kan även ändra pcap-filtret i konfigurationsfilen, men då tar analysen givetvis längre tid.

Att analysera en 2.2GB pcap-fil med min Raspberry Pi 3 Model B+ tog cirka 3 minuter. Då hade jag satt USE_HEURISTICS till false samt CHECK_HOST_DOMAINS till true, främst för att USE_HEURISTICS gav så många false-positives.

För den som gillar trevliga webb-gränssnitt så finns det även ett till Maltrail och startas upp med server.py:

Sedan är det bara att surfa till IP-adressen där du har Maltrail installerat och port 8838. Du måste även logga in med användarnamn och lösenord som är satt till admin/changeme! som standard. Går givetvis att ändra i konfigg-filen, och server.py stödjer även SSL/TLS.

Följande bild är en skärmdump på en dag där det identifierats 145 st threats:

Maltrail larm
src_ip och dst_ip är maskerade på bilden ovan

Majoriteten av larmen som dykt upp under mina tester är klassificerade som medium eller low. Och precis som vid Threat Hunting så är det viktigt att följa upp varför just dessa larm uppstår, jag rekommenderar att använda Moloch eller Argus-data för vidare analys. Vid denna vidare analys kan det vara intressant att kolla källan som framgår samt om du har rådata i pcap:ar kvar så bidrar även detta till större framgång.

Ett annat tips är att kolla datakällor såsom Zoomeye, Censys.io och Shodan där dessa IP-nummer eller domäner kan identifieras.