secforce/tunnaTunna è un insieme di strumenti che incapsuleranno e tunnelleranno qualsiasi comunicazione TCP su HTTP. Può essere utilizzato per bypassare le restrizioni di rete in ambienti completamente protetti da firewall.
Tunna è un insieme di strumenti che incapsulano e tunnelano qualsiasi comunicazione TCP su HTTP. Può essere utilizzato per aggirare restrizioni di rete in ambienti completamente protetti da firewall.
v1.1 Versione Alpha
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, per tunnelare connessioni TCP su HTTP di Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Tunnelizza connessioni TCP su HTTP
In un ambiente completamente protetto da firewall (connessioni in entrata e in uscita limitate – tranne la porta del server web)
La webshell può essere utilizzata per connettersi a qualsiasi servizio sull'host remoto. Si tratta di una connessione locale su una porta locale dell'host remoto e dovrebbe essere consentita dal firewall.
La webshell legge i dati dalla porta del servizio, li incapsula su HTTP e li invia come risposta HTTP al proxy locale.
Il proxy locale decapsula e scrive i dati sulla propria porta locale, alla quale si connette il programma client.
Quando il proxy locale riceve dati sulla porta locale, li invia alla webshell come richiesta POST HTTP.
La webshell legge i dati dalla richiesta POST HTTP e li inserisce sulla porta del servizio.
E si ripete --^
Solo la porta del server web deve essere aperta (tipicamente 80/443) L'intera comunicazione (esternamente) avviene tramite il protocollo HTTP
python proxy.py -u <urlremoto> -l <portalocale> [opzioni]
--help, -h mostra questo messaggio di aiuto ed esci
--url=URL, -u URL url della webshell remota
--lport=PORTA_LOCALE, -l PORTA_LOCALE
porta di ascolto locale
--verbose, -v Verbose (mostra la dimensione dei pacchetti)
--buffer=DIMENSIONE_BUFFER, -b DIMENSIONE_BUFFER*
dimensione della richiesta HTTP (alcune webshell hanno limitazioni
sulla dimensione)
Le opzioni vengono ignorate se viene utilizzato un proxy SOCKS
--no-socks, -n Non utilizzare il proxy SOCKS
--rport=PORTA_REMOTA, -r PORTA_REMOTA
porta remota del servizio a cui deve connettersi la webshell
--addr=IP_REMOTO, -a IP_REMOTO
indirizzo a cui deve connettersi la webshell remota (predefinito =
127.0.0.1)
Tunnela la connessione attraverso un proxy locale
--up-proxy=PROXY_UP, -x PROXY_UP
Proxy upstream (http://proxyserver.com:3128)
--auth, -A Il proxy upstream richiede autenticazione
--ping-interval=INTERVALLO_PING, -q INTERVALLO_PING
intervallo del thread di ping webshprx (predefinito = 0.5)
--start-ping, -s Avvia prima il thread di ping – alcuni servizi inviano
dati per primi (es. SSH)
--cookie, -C Cookie di richiesta
--authentication, -t Autenticazione di base
Esempi di utilizzo:
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Questo avvierà un server proxy SOCKS locale sulla porta 8000
# Questa connessione verrà incapsulata su HTTP e decapsulata sul server remoto
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Questo avvierà un server proxy SOCKS locale sulla porta 8000
# Si connetterà attraverso un proxy locale (https://192.168.1.100:3128) che richiede autenticazione
# alla webshell Tunna remota
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Questo avvierà una connessione tra la webshell e il servizio RDP (3389) dell'host remoto
# Il client RDP può connettersi sulla porta locale 4444
# Questa connessione verrà incapsulata su HTTP
Possibilità di caricare una webshell sul server remoto
Questo è un codice proof-of-concept e potrebbe causare un DoS del server.
Sono stati fatti tutti gli sforzi per pulire dopo l'esecuzione o in caso di errore (nessuna garanzia)
Basato su test locali:
* Il buffer JSP deve essere limitato (opzione buffer):
4096 ha funzionato su Linux Apache Tomcat
1024 ha funzionato su XAMPP Apache Tomcat (lento)
* Oltre ciò si sono verificati problemi con byte mancanti sul socket remoto
es: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Socket non abilitati per impostazione predefinita:
php windows (IIS + PHP)
XAMPP Windows
php linux (server web integrato PHP/apache + PHP)
Se ricevi l'errore Uncaught Error: Call to undefined function socket_create()
vedi https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Ritorni a capo sulle webshell (al di fuori del codice):
vengono inviati nelle risposte / scritti sul socket locale → corrompono i pacchetti
* Webshell PHP per windows: la funzione loop causa DoS sul socket remoto:
aggiunta funzione sleep → funziona ma un po' lento
* La webshell PHP necessita della rimozione dei caratteri di nuova riga alla fine del file (dopo "?>")
poiché questi verrebbero inviati in ogni risposta e confondono Tunna
Webshell:
conn.jsp Testato su Apache Tomcat (windows + linux)
conn.aspx Testato su IIS 6+8 (windows server 2003/2012)
conn.php Testato su LAMP + XAMPP + IIS (windows + linux)
WebServer:
webserver.py Testato con Python 2.6.5
Proxy:
proxy.py Testato con Python 2.6.5
I dati vengono inviati grezzi nel corpo della richiesta HTTP POST (nessuna variabile POST)
Le istruzioni / configurazione vengono inviate alla webshell come parametri URL (HTTP GET)
I dati vengono inviati nel corpo HTTP (HTTP POST)
Websocket non utilizzati: non supportati per impostazione predefinita dalla maggior parte dei server web
Le risposte HTTP asincrone non sono realmente possibili
Il proxy interroga costantemente il server (predefinito 0.5 secondi)
Il 1° pacchetto avvia una sessione con la webshell – ottiene un cookie come risposta es: http://webserver/conn.ext?proxy
Il 2° pacchetto invia le opzioni di configurazione della connessione alla webshell es: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP e porta a cui deve connettersi la webshell
Questa è una richiesta thread:
In php questa richiesta entrerà in un ciclo infinito
per mantenere attiva la connessione socket della webshell
In altre webshell viene ricevuto [OK]
Verrà creato un socket locale a cui si connetterà il programma client Una volta che il client è connesso, viene avviato il thread di ping e inizia l'esecuzione. Qualsiasi dato sul socket (dal client) viene letto e inviato come richiesta HTTP POST Qualsiasi dato sul socket della webshell viene inviato come risposta alla richiesta POST
Poiché le risposte HTTP non possono essere asincrone. Questo thread esegue richieste HTTP GET sulla webshell a un intervallo (predefinito 0.5 secondi) Se la webshell ha dati da inviare, li invia (anche) come risposta a questa richiesta Altrimenti invia una risposta vuota
In generale: I dati dal proxy locale vengono inviati con HTTP POST Ci sono richieste GET ogni 0.5 secondi per interrogare la webshell per dati Se ci sono dati sul lato della webshell, vengono inviati come risposta a una di queste richieste
La webshell si connette a un socket sull'host locale o remoto. Qualsiasi dato scritto sul socket viene rinviato al proxy come risposta a una richiesta (POST/GET) Qualsiasi dato ricevuto con una POST viene scritto sul socket.
Tutte le richieste devono avere il parametro URL "proxy" impostato per essere gestite dalla webshell (http://webserver/conn.ext?proxy)
Termina tutti i thread e chiude il socket locale Invia proxy&close alla webshell: Termina i thread remoti e chiude il socket
Il supporto SOCKS è un modulo aggiuntivo per Tunna. Localmente è un thread separato che gestisce le richieste di connessione e il traffico, aggiunge un'intestazione che specifica la porta e la dimensione del pacchetto e lo inoltra a Tunna. Tunna lo invia al server web remoto, rimuove le intestazioni HTTP e inoltra il pacchetto al proxy SOCKS remoto. Il proxy SOCKS remoto avvia la connessione e mappa la porta ricevuta sulla porta locale. Se il proxy SOCKS remoto riceve dati dal servizio, consulta la tabella di mapping e trova la porta a cui rispondere, aggiunge la porta come intestazione in modo che il proxy SOCKS locale sappia dove inoltrare i dati. Qualsiasi traffico dalla porta ricevuta verrà inoltrato alla porta locale e viceversa.
Tunna, Incapsulamento TCP su HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Questo strumento è destinato esclusivamente a scopi legali.
Questo programma è software libero: puoi ridistribuirlo e/o modificarlo secondo i termini della Licenza Pubblica Generale GNU come pubblicata dalla Free Software Foundation, versione 3 della licenza o (a tua scelta) qualsiasi versione successiva.
Questo programma è distribuito nella speranza che sia utile, ma SENZA ALCUNA GARANZIA; senza nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedi la Licenza Pubblica Generale GNU per maggiori dettagli.
Dovresti aver ricevuto una copia della Licenza Pubblica Generale GNU insieme a questo programma. In caso contrario, visita http://www.gnu.org/licenses/.