Taggat med: shodan.io

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!

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: