secforce/tunnaTunna est un ensemble d'outils qui encapsulent et tunnelisent toute communication TCP via HTTP. Il peut être utilisé pour contourner les restrictions réseau dans des environnements entièrement pare-feu.
Tunna est un ensemble d'outils qui encapsuleront et tunnelleront toute communication TCP via HTTP. Il peut être utilisé pour contourner les restrictions réseau dans des environnements entièrement pare-feu.
v1.1 Version Alpha
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, pour le tunneling de connexions TCP via HTTP par Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Tunnelise les connexions TCP via HTTP
Dans un environnement entièrement pare-feu (connexions entrantes et sortantes restreintes - à l'exception du port du serveur web)
La webshell peut être utilisée pour se connecter à n'importe quel service sur l'hôte distant. Il s'agirait d'une connexion locale sur un port local de l'hôte distant et devrait être autorisée par le pare-feu.
La webshell lira les données du port de service, les encapsulera via HTTP et les enverra comme réponse HTTP au proxy local.
Le proxy local les désencapsulera et écrira les données sur son port local où le programme client serait connecté.
Lorsque le proxy local reçoit des données sur le port local, il les enverra à la webshell sous forme d'une requête HTTP Post.
La webshell lira les données de la requête HTTP Post et les placera sur le port de service
et répète --^
Seul le port du serveur web doit être ouvert (généralement 80/443) Toute la communication (Externe) se fait via le protocole HTTP
python proxy.py -u <remoteurl> -l <localport> [options]
--help, -h affiche ce message d'aide et quitte
--url=URL, -u URL url de la webshell distante
--lport=LOCAL_PORT, -l LOCAL_PORT
port d'écoute local
--verbose, -v Verbeux (affiche la taille des paquets)
--buffer=BUFFERSIZE, -b BUFFERSIZE*
taille de la requête HTTP (certaines webshells ont des limitations de taille)
Les options sont ignorées si un proxy SOCKS est utilisé
--no-socks, -n Ne pas utiliser de proxy Socks
--rport=REMOTE_PORT, -r REMOTE_PORT
port distant du service auquel la webshell doit se connecter
--addr=REMOTE_IP, -a REMOTE_IP
adresse pour que la webshell distante se connecte (par défaut =
127.0.0.1)
Tunnellise la connexion via un proxy local
--up-proxy=UPPROXY, -x UPPROXY
Proxy amont (http://proxyserver.com:3128)
--auth, -A Le proxy amont nécessite une authentification
--ping-interval=PING_DELAY, -q PING_DELAY
intervalle du thread de ping de webshprx (par défaut = 0.5)
--start-ping, -s Démarrer le thread de ping en premier - certains services envoient
des données en premier (ex. SSH)
--cookie, -C Cookies de requête
--authentication, -t Authentification de base
exemple d'utilisation :
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Cela démarrera un serveur proxy SOCKS local sur le port 8000
# Cette connexion sera encapsulée via HTTP et désencapsulée sur le serveur distant
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Cela démarrera un serveur proxy SOCKS local sur le port 8000
# Il se connectera via un proxy local (https://192.168.1.100:3128) qui nécessite une authentification
# à la webshell Tunna distante
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Cela initiera une connexion entre la webshell et le service RDP (3389) de l'hôte distant
# Le client RDP peut se connecter sur le port localhost 4444
# Cette connexion sera encapsulée via HTTP
La capacité de télécharger une webshell sur le serveur distant
Ceci est un code POC (Proof of Concept) et peut provoquer un déni de service (DoS) du serveur.
Tous les efforts ont été faits pour nettoyer après exécution ou en cas d'erreur (sans garantie)
Basé sur des tests locaux :
* Le tampon JSP doit être limité (option buffer) :
4096 a fonctionné sous Linux Apache Tomcat
1024 a fonctionné sous XAMPP Apache Tomcat (lent)
* Plus que cela a créé des problèmes de bytes manquants au niveau du socket distant
eg: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Sockets non activés par défaut :
php windows (IIS + PHP)
XAMPP Windows
php linux (PHP builtin web server/apache + PHP)
Si vous avez l'erreur Uncaught Error: Call to undefined function socket_create()
voir https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Retours chariot sur les webshells (en dehors du code) :
sont envoyés dans les réponses / sont écrits sur le socket local --> corrompt les paquets
* Webshell PHP pour Windows : la fonction de boucle cause un déni de service sur le socket distant :
fonction sleep ajoutée -> fonctionne mais un peu lent
* La webshell PHP nécessite que les caractères de nouvelle ligne soient supprimés à la fin du fichier (après "?>")
car ceux-ci seront envoyés dans chaque réponse et perturberont Tunna
Webshells :
conn.jsp Testé sur Apache Tomcat (windows + linux)
conn.aspx Testé sur IIS 6+8 (windows server 2003/2012)
conn.php Testé sur LAMP + XAMPP + IIS (windows + linux)
Serveur web :
webserver.py Testé avec Python 2.6.5
Proxies :
proxy.py Testé avec Python 2.6.5
Les données sont envoyées brutes dans le corps de la requête HTTP Post (aucune variable post)
Les instructions / configuration sont envoyées à la webshell en tant que paramètres d'URL (HTTP Get)
Les données sont envoyées dans le corps HTTP (HTTP Post)
Websockets non utilisés : non supportés par défaut par la plupart des serveurs web
Les réponses HTTP asynchrones ne sont pas vraiment possibles
Le proxy interroge le serveur constamment (par défaut 0.5 secondes)
1er paquet initie une session avec la webshell - reçoit un cookie en retour eg: http://webserver/conn.ext?proxy
2e paquet envoie les options de configuration de connexion à la webshell eg: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP et port auxquels la webshell doit se connecter
Il s'agit d'une requête avec threads :
En PHP, cette requête entrera dans une boucle infinie
pour maintenir la connexion socket de la webshell active
Dans les autres webshells, [OK] est reçu en retour
Un socket local va être créé auquel le programme client va se connecter Une fois le client connecté, le thread de ping est initié et l'exécution commence. Toutes les données sur le socket (en provenance du client) sont lues et envoyées sous forme de requête HTTP Post Toutes les données sur le socket de la webshell sont envoyées en réponse à la requête POST
Parce que les réponses HTTP ne peuvent pas être asynchrones. Ce thread effectuera des requêtes HTTP Get sur la webshell à intervalles réguliers (par défaut 0.5 sec) Si la webshell a des données à envoyer, elle les enverra (également) en réponse à cette requête Sinon, elle envoie une réponse vide