Taggat med: twitter

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:

Nya attacker mot VPN med hjälp av vishing

VPN Vishing

Cyberangripare attackerar nu personal som nu jobbar hemma i allt större utstäckning. Med ett nytt modus operandi så ringer angriparen upp den anställde och förmår denne att logga in på en alternativ fiktiv webbsida för VPN-anslutningar.

👉 Stöd mitt bloggande via Patreon

Denna webbsida innehåller även funktion att lura till sig engångstokens för tvåfaktorsautentisering. Det var även på detta sätt som angripare lyckades göra intrång hos Twitter förra månaden.

Här är ett riktigt exempel på hur webbsidan helpdesk-att.com såg ut för några dagar sedan:

AT&T fiktiv VPN-portal inloggning. Bildcredd: urlscan.io

Denna typ av attack kallas för Vishing (voice phising) och har några år på nacken men att nu kombinera detta med attacker mot VPN som stjäl 2FA-tokens är det nya tillvägagångssättet.

Även kan denna attack kombineras med en annan attack som medger att spoofa numret till företagets växel så samtalet ser ut att komma från medarbetarens egna organisation.

Motåtgärder

Först och främst är utbildning en viktig faktor, även återkommande utbildningspass för medarbetare. När det gäller MFA/2FA så har angriparna ännu inte någon metod för att genomföra MITM på hårdvarunycklar såsom Yubikeys.

Och sist men inte minst så är det viktigt med spårbarhet och loggning och övervaka samtliga inloggningar och knyta dessa inloggningar vidare mot klientcertifikat och datorkonfiguration.

Kan även tipsa om svenska startupen Castle.io har en hel del intressanta metoder att hitta kapade konton.

Så spionerade Saudiarabien med hjälp av Twitter

Twitters huvudkontor i San Francisco

Dokument från amerikanska justitiedepartementet visar på hur flertalet insiders tagit jobb hos företag Twitter för att spionera på dissidenter via plattformen.

Information om kritiska konton såsom E-postadress och telefonnummer har troligtvis stulits och skickats vidare till kungadömet i Saudiarabien.

De två personerna Mr. Alzabarah och Mr. Abouammo har nu efterlysts av FBI och finns nu med på deras lista med följande förklaring:

Ali Hamad A Alzabarah is wanted for failing to register as an agent of a foreign government as required by United States law.  In 2015, Alzabarah allegedly took part in a scheme to steal proprietary and confidential user data from a U.S. company, Twitter, for the benefit of the Kingdom of Saudi Arabia. 

The stolen data included email addresses, telephone numbers and internet protocol addresses of Saudi dissidents and critics of the Saudi government, among others.  A federal arrest warrant was issued for Alzabarah in the United States District Court, Northern District of California, on November 5, 2019, after he was charged with acting as an unregistered agent of a foreign government.

Den person som först approcherade och lyckades rekrytera dessa två Twitter-anställda som agenter jobbade med en täckmantel under organisationen MiSK Foundation.

Information om cirka 6000 konton har läckt från Twitter uppger en källa till New York Times. Detta inträffade under 2015 och personerna fick efter ett tag lämna Twitter.

Det modus operandi som Saudiarabien följt här är eg ”by the book” och inget som är speciellt konstigt. De lyckades rekrytera två insiders som hade behörigheter att göra sökningar i Twitters databaser.

Twitter läckte lösenord

Twitter gick ut med ett meddelande till samtliga 300+ miljoner användare gällande att lösenord har läckt. Samtliga lösenord på mikrobloggen Twitter är hashade med algoritmen bcrypt, men har nu läckt i ett internt system och därför uppmanas alla användare byta sina lösenord. Lösenorden i klartext har enbart varit tillgängliga i en intern loggfil som enbart varit tillgänglig för anställda.

Twitter skriver på sin blogg:

“Due to a bug, passwords were written to an internal log before completing the hashing process,” he continued. “We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.”

Följande rekommendationer kommer från Twitter gällande lösenord:

  1. Byt ditt lösenord på Twitter och andra tjänster om du haft samma lösenord
  2. Använd ett starkt lösenord och återanvänd inte detta lösenord på andra tjänster
  3. Använd tvåfaktorsautentisering
  4. Använd en lösenordshanterare som ser till att du använder starka och unika lösenord för alla dina tjänster

Skärmdump på meddelandet som visas till samtliga användare:

Vikten av stark autentisering

Via CERT-SE hittar vi följande bra inlägg om vikten av att skydda sina kontouppgifter.

Graham Cluley skriver att det är viktigt att skydda kontouppgifter och använda stark autentisering (om möjligt) till sociala mediewebbplatser, som till exempel Facebook och Twitter.

Just a username/password combination isn’t enough when a social media account is an important part of your business or public image.

Det gäller i allra högsta grad myndigheter och företag som använder sig av sociala medier för att kommunicera med medborgare. Man bör noga utvärdera eventuella risker med att använda kommunikationsplattformar som saknar möjlighet till stark autentisering och där man kan få problem med att mitigera effekterna om inloggningsuppgifter skulle hamna på avvägar.

Artikeln som CERT-SE rekommenderar finns att läsa här: http://nakedsecurity.sophos.com/2012/04/16/hyatt-acai-berry/ och vi har även skrivit om Facebook och dess tvåfaktorsautentisering här.

Följ oss på Twitter

Du missar väl inte att vi även finns på Twitter? Där får du krypto och IT-säkerhetsrelaterade nyheter mellan uppdateringarna här på bloggen.

Klicka på bilden för att komma till vår Twitter-profil:

Twitter börjar med https-kryptering för alla

Den populära mikroblogg-tjänsten Twitter börjar successivt med att slå på https för samtliga avändare. Vi rapporterade i Mars att Twitter slagit på https och valet att nu gå över helt till https beror troligtvis på attacker såsom Firesheep.

Källa:

We suggest using HTTPS for improved security. We’re starting to turn this on by default for some users. More here: http://t.co/p1HWKpVless than a minute ago via web Favorite Retweet ReplyTwitter Comms
twitterglobalpr



Du kan även titta på supportsidan: support.twitter.com/articles/481955-how-to-enable-https