Nu finns det en ny version av phishing-ramverket Evilginx. Evilginx är utvecklat av Kuba Gretzky och var det första ramverket som var öppet och hade möjlighet att kringgå multifaktorsautentisering genom att utföra man-i-mitten-attacker (MITM). Jag kan även rekommendera denna artikel då jag testar ett annat liknande verktyg.
Nyheter i version 3.2
Den första och största nyheten har och göra med hur redirect_url fungerar. När väl en sessionstoken har spelats in vid en phishing-sida så har det tidigare varit svårt att göra ompekningar när sidorna har varit SPA:er (Single Page Applications). Men genom att injicera ett javascript i webbsidan som MITM:as så går det nu att göra en redirect enklare.
När en ny phishing-kampanj skickas ut via E-post så brukar de första som besöker phishing-sidorna vara automatiserade scanners som automatiskt försöker lista ut om länken i ett E-post är en phishing-sida. Genom att nu använda följande konfigurations-direktiv så är det möjligt att pausa phishing-sidan temporärt och således försvåra för dessas automatiserade scanningar och säkerhetsprodukter:
lures pause <id> <time_duration>
Det går nu att finjustera proxy-anropen som går via Evilginx och returnera egna fel-koder eller svar på HTTP-förfrågningar. Exempelvis:
Det finns många andra nyheter och buggfixar i Evilginx, se följande inlägg för alla nyheter.
Skydd mot MITM/proxy phishing-attacker
Kuba som utvecklar Evilginx höll ett föredrag på konferensen x33fcon om hur man kan skydda sig mot denna typ av phishing-attacker där angriparen gör MITM/proxy-attacker för att stjäla sessions-cookies.
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
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.
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.
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!
Verktyget mitmproxy som används för att genomföra man-i-mitten attacker (man-in-the-middle) angrepp finns nu ute i en ny version. Verktyget kan exempelvis användas för att analysera trafik till och från datorer, iPhone, iPads eller andra enheter.
* New built-in key/value editor. This lets you interactively edit URL query
strings, headers and URL-encoded form data.
* Extend script API to allow duplication and replay of flows.
* API for easy manipulation of URL-encoded forms and query strings.
* Add ”D” shortcut in mitmproxy to duplicate a flow.
* Reverse proxy mode. In this mode mitmproxy acts as an HTTP server,
forwarding all traffic to a specified upstream server.
* UI improvements – use unicode characters to make GUI more compact,
improve spacing and layout throughout.
* Add support for filtering by HTTP method.
* Add the ability to specify an HTTP body size limit.
* Move to typed netstrings for serialization format – this makes 0.7
backwards-incompatible with serialized data from 0.6!
* Many minor bugfixes and improvements.
En användare av webbläsaren Google Chrome har i Iran upptäckt ett felaktigt certifikat för Google-tjänster. Efter ytterligare undersökningar så visade det sig att någon på vägen mellan användaren i Iran och Google genomförde en såkallad man-i-mitten attack (man-in-the-middle /MITM ) mot krypterade anslutningar (https).
Att användaren i Iran kunde upptäcka attacken berodde på att Google lagt in fingerprints för dess tjänster hårdkodat i webbläsaren Chrome. Så oavsett om certifikatet ser ut att vara korrekt utfärdat för *.google.com så visas en varning till användaren.
En av bovarna i dramat är företaget DigiNotar som utfärdat ett certifikat felaktigt. Omfattningen av denna attack är i dagsläget oklar.
Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).
Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.
To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates.
To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.
En allvarlig säkerhetsbugg har upptäckts i Apples mobiltelefon iPhone som använder operativsystemet iOS. Denna typ av attack upptäcktes för nio år sedan och har drabbat exempelvis webbläsaren Internet Explorer tidigare.
Denna bugg medger att någon kan göra en aktiv, oupptäckbar MITM (man-in-the-middle) attack mot TLS/SSL-krypterade anslutningar. För detta kan verktyget sslsniff användas som även uppdaterats.
Skatteverket har missat att kryptera all kommunikation mellan dess iPhone/Android-app och servrar vilket resulterat i att en man-in-the-middle (MITM) attack varit möjlig. Appen är nu uppdaterad och säkerhetsbuggen är åtgärdad.
