fkasler/cuddlephishBrowser-in-the-Middle (BitM) armato per Penetration Testers
Browser-in-the-middle (BitM) multiutente armato per penetration tester. Questo attacco può essere utilizzato per bypassare l'autenticazione multifattoriale su molte applicazioni web di alto valore. Funziona anche per applicazioni che non utilizzano token di sessione e che quindi non sarebbero sfruttabili con gli attacchi tradizionali di furto di token. È uno strumento di ingegneria sociale e non sfrutta alcun difetto tecnico nel servizio target.
Questo strumento è un server web specializzato. È progettato per funzionare su un server Linux Debian 11 (Bullseye) e si basa sulle informazioni IP pubbliche per proteggere le funzionalità di amministrazione. Non aspettarti di poter testare in locale senza superare alcuni ostacoli considerevoli.
Avvertenza: Chromium non è supportato su ARM. Sebbene sia tecnicamente possibile forzare l'uso di un binario Chromium per ARM, perderai tutte le funzionalità/protezioni aggiuntive di puppeteer-extra.
Questo esempio di configurazione utilizza Caddy per gestire TLS, SNI e aggiungere un paio di header personalizzati come 'X-Real-IP' a ogni richiesta. Non sei obbligato a usare Caddy con Cuddlephish, poiché lo stesso reverse proxy può essere configurato con Nginx, Apache, ecc. Preferisco Caddy perché è facile da installare con Docker e ha plugin per gestire i certificati Letsencrypt per la maggior parte dei registrar di domini. Il Caddyfile di esempio mostra come configurarlo per Gandi. Controlla la documentazione per il tuo registrar.
Installa Docker, Node, XVFB e altre dipendenze:
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh
Puoi quindi usare Docker per creare Caddy con un plugin per certificati wildcard per il tuo registrar. L'esempio è per Gandi. Controlla la documentazione qui e l'elenco dei moduli per provider DNS qui. Puoi modificare il Dockerfile per il tuo registrar prima di crearlo:
sudo docker build -t caddy .
Ora modifica il Caddyfile per sostituire il tuo dominio e la chiave API di Gandi (o altro registrar), quindi avvia Caddy. Ti consiglio di avviarlo in una finestra screen o tmux in modo da poter eseguire il server Node in un'altra finestra tra poco:
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest
Con Caddy che gestisce il traffico sulle porte 80 e 443, possiamo finalmente eseguire lo strumento!
Installa le dipendenze Node:
npm install
Alcune piccole modifiche alla configurazione: PASSAGGIO CRITICO: assicurati di modificare il file config.json di esempio per aggiungere i tuoi IP pubblici approvati per l'accesso amministrativo. Questa whitelist di IP determina l'accesso all'interfaccia web "/admin". Dovresti anche cambiare la chiave socket predefinita con una più sicura.
Lo strumento non è configurato per targetizzare alcun login di default, quindi dovrai aggiungerne alcuni. C'è uno script 'add_target.js' per semplificare questo passaggio. Basta eseguire lo script e incollare l'URL del portale di login che desideri targetizzare quando richiesto:
node add_target.js
Questo recupererà il nome del servizio, il titolo della scheda e la favicon per te e aggiungerà una voce a 'targets.json'. Puoi eseguire questo script più volte e aggiungerà i nuovi target. Lo script nominerà ogni servizio in base al dominio, senza il livello superiore. Quindi, per 'https://www.example.com/login.php' il servizio sarà semplicemente 'example' quando specificherai il tuo target quando...
Eseguilo!
node index.js example
Dopo alcuni secondi, dovresti vedere un messaggio nella console quando la prima istanza automatica di Chrome si connette tramite websocket. Ora i visitatori del tuo sito di phishing vedranno quella che sembra la pagina di login del target, ma in realtà è un flusso video della tua istanza automatica del browser. Possono anche interagire con la tua istanza del browser e accedere per te.
Se hai configurato correttamente i tuoi IP amministrativi in config.json, dovresti essere in grado di visualizzare un'interfaccia web speciale '/admin' per tenere traccia degli utenti, visualizzare i log dei tasti, assumere il controllo delle istanze del browser connesse, rubare i cookie ed eliminare le istanze del browser indesiderate.
Nota: non vedrai nulla nella pagina di admin finché non avrai delle vittime. Una volta che hai una vittima, la sua istanza del browser dovrebbe apparire nell'interfaccia di amministrazione.
Diverse persone hanno aperto issue riguardanti una "Pagina Bianca Vuota", che è più un sintomo di molti possibili problemi, non un problema in sé. Per favore, non aprire issue con nomi di sintomi vaghi. Invece, se vedi una pagina bianca dal lato utente, prova prima a controllare quanto segue:
Ad alto livello, se vedi solo una pagina bianca sul front-end, significa che c'è un'interruzione nella catena del flusso di dati da "Avvia WebRTC" > "Seleziona scheda da trasmettere" > "Negoziare ICE con il browser della vittima" > "Stream video". I passaggi di risoluzione dei problemi sopra hanno lo scopo di aiutarti a seguire i dati attraverso questo processo. Quando funziona correttamente, dovresti vedere un flusso di log sul server simile al seguente:
Spero che questo aiuti con eventuali problemi e, come sempre, informazioni sufficienti per riprodurre costantemente un problema sono un prerequisito per inviare issue per ulteriori indagini.
Attiva manualmente il download di un payload sul sistema della vittima tramite JavaScript. Ogni target inizia con 'payload.txt' come payload di test. Basta cambiare la posizione del file in targets.json per inviare un payload personalizzato.
Invia una modifica di window.location alla vittima per inviarla al vero portale di login. Sembrerà che sia solo costretta a riautenticarsi e impedirà di vederti mentre prendi i controlli. Se modifichi il codice, potresti fare altre cose interessanti con questa tecnica generale ;)
Ti permette di intervenire e prendere il controllo diretto di un'istanza del browser dal portale di amministrazione. Per smettere di controllare l'istanza, premi il tasto ESCAPE. Nota: questo toglierà i controlli alla vittima di phishing e potrà vedere i tuoi movimenti se non la espelli prima. Sei stato avvertito.
Ti permette di ridare manualmente il controllo dell'istanza automatica del browser all'utente. Questo potrebbe essere utile in alcuni scenari di ingegneria sociale quando si finge il reparto IT. Puoi dire all'utente che stai avviando una sessione di assistenza, prendere il controllo e navigare al servizio target, ridare il controllo e fargli accedere, riprendere il controllo, ecc.
Estrae tutti i cookie e gli elementi di archiviazione locale dall'istanza del browser e li scarica come file JSON. Per iniettare questo materiale di credenziali in un'istanza del browser in esecuzione sul tuo sistema locale, c'è uno script nel progetto chiamato 'stealer.js'. È pensato per essere eseguito dalla tua macchina, non dal server, quindi per usarlo dovrai anche installare i componenti Node del progetto sul tuo sistema.
node stealer.js ~/Downloads/cuddle_asdf1234.json
Uccide un'istanza del browser quando non ne hai bisogno. A volte gli utenti non ti fanno accedere completamente. A volte la connessione WebRTC fallisce. A volte una sessione scade prima che tu possa usarla. In questi casi, questo pulsante può aiutarti a pulire le istanze del browser inutili tramite il portale di amministrazione.
Ogni browser viene generato con un proprio "browser id" casuale e una directory di dati utente corrispondente nella cartella "user_data" del progetto. In alcuni casi in cui 'stealer.js' non funziona, potresti aver bisogno di replicare anche i dati utente per quell'istanza. Questo può essere utile in scenari che targetizzano servizi con una funzione "ricorda questo browser" a seconda di come è implementata.
C'è anche un keylog.txt in ogni directory dei dati utente con un keylog completo dell'utente vittima. Il keylog generale nel portale di amministrazione cerca di tenere conto di cose come i backspace, mentre questo keylog.txt avrà tutte le sequenze di tasti registrate.
Esempio di pm.json:
{
"tacking_id": "id",
"logging_endpoint": "https://www.phishmongerserver.com/create_event",
"admin_cookie": "admin_cookie=s3cret",
"post_url_search": "ppsecure"
}
Questo strumento funziona abbinando i visitatori del sito di phishing a un browser Chrome automatizzato, in esecuzione sul server di phishing. Un flusso video dell'istanza Chrome controllata dall'attaccante viene quindi trasmesso alla vittima di phishing tramite WebRTC, e tutti i movimenti del mouse e le sequenze di tasti forniti dall'utente vengono inoltrati dal browser della vittima alla loro istanza Chrome associata. Il server utilizza websocket per tracciare le vittime, abbinarle ai browser, intermediare i flussi video WebRTC e intercettare gli input dell'utente. Per ogni nuovo visitatore, il server genera una nuova istanza Chrome. Poiché utilizziamo il protocollo Chrome Devtools (CDP) per guidare ogni istanza Chrome, possiamo usare API come "Storage.getCookie" per estrarre i cookie di sessione per i siti target una volta che l'utente ha effettuato l'accesso per noi. Possiamo anche intervenire in qualsiasi momento e guidare direttamente ogni istanza Chrome, sfruttando lo stesso metodo che usiamo per dare il controllo remoto alle vittime in primo luogo.
Il Node Server esegue le seguenti operazioni:
È mia convinzione che questa tecnica sia stata teorizzata e persino armata per diversi anni (vedi ringraziamenti). Quindi, mentre gli attori delle minacce possono sfruttare questa tecnica, e probabilmente lo fanno da un po', i professionisti della sicurezza offensiva non hanno avuto un modo semplice per replicare questa tecnica e potrebbero persino essere inconsapevoli della sua esistenza. La mia intenzione nel rilasciare lo strumento è di permettere a penetration tester e red teamer di usare BitM nelle operazioni per mostrare il suo potenziale impatto e aiutare i difensori di rete a prepararsi per minacce reali.
Prima di tutto, comprendi che questo attacco si basa sull'ingegneria sociale per indurre un utente a visitare un sito web dannoso. La whitelist dei domini sarebbe di grande aiuto per prevenire questo e altri tipi di ingegneria sociale. Se ci affidiamo agli utenti per gestire il 100% dei dati di autenticazione (password, OTP, SMS, PhoneFactor, notifica push, ecc.) per un servizio web, siamo potenzialmente vulnerabili a questo attacco. Pertanto, per sventare questo attacco, dobbiamo sfruttare dati di autenticazione che gli utenti non gestiscono. Ad esempio, i certificati TLS client possono essere emessi per i dispositivi client e saranno validi solo per il vero servizio web. Il certificato è gestito dal browser e dal sistema operativo, e non c'è modo per il server di un attaccante di ottenere una copia del certificato TLS della vittima. Un'altra opzione è utilizzare U2F o FIDO2 con hardware come un YubiKey per gestire parte dei dati di autenticazione richiesti. Non c'è modo per un sito web di un hacker di interagire con un YubiKey collegato al computer di una vittima.
Non sono un mago di Docker (ancora). Se riesci a trovare una configurazione Dockerizzata semplice, apprezzerei molto una pull request.
È un gioco di parole su Cuttlefish (seppia), una creatura marina tosta che può mimetizzarsi nell'ambiente circostante, Phishing, perché richiede ingegneria sociale per eseguire l'attacco, e volutamente scritto male per essere unico, giocoso e stupido. Mi rende felice pensare che questo nome divertente verrà menzionato insieme a reperti di rischio critico nei report di pentest.
Sebbene abbia ideato questa tecnica e implementazione in modo indipendente, ho poi appreso che un paio di altri ricercatori mi hanno preceduto nella scoperta. Hanno entrambi adottato un approccio utilizzando client VNC basati sul web per ottenere un risultato simile. È un approccio intuitivo e potrebbe essere applicabile per eseguire attacchi MitM contro altri software, non solo browser (VPN-in-the-browser forse?). Vale sicuramente la pena dare un'occhiata:
Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5
@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/
Inoltre:
Un ringraziamento a Daniel Aaron @majordmg per il supporto nelle fasi iniziali della proof-of-concept di WebRTC.
Un enorme grazie a RJ Stallkamp @Z3rO-C00L per aver sistemato e stilizzato l'interfaccia di amministrazione, e per il fantastico nuovo logo.