Société de Sécurité Informatique - Audit Firewall Appliances
La sécurité informatique - La sécurité des informations

Tunna, ensemble d'outils qui encapsulent et tunnellent toutes communications TCP via HTTP


Tunna est un ensemble d'outils qui encapsulent et tunnelent toute communication TCP via HTTP. Il peut être utilisé pour contourner les restrictions réseau dans les environnements protégés par des pare-feu.

Résumé


TLDR: Tunnels Connexions TCP sur HTTP

Dans un environnement entièrement protégé par un pare-feu (connexions entrantes et sortantes restreintes - sauf le port du serveur Web)
Le webshell peut être utilisé pour se connecter à n'importe quel service de l'hôte distant.
Ce serait une connexion locale sur un port local de l'hôte distant et devrait être autorisé par le pare-feu.
Le webshell lira les données du port de service et les enverra sur HTTP et les renverra en réponse HTTP au proxy local.
Le proxy local va dérouler et écrire les données sur son port local où le programme client sera connecté.
Lorsque le proxy local reçoit des données sur le port local, il les envoie à la webshell en tant que message HTTP Post.
Le webshell lira les données de HTTP Post et les placera sur le port de service
et on 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

Utilisation


python proxy.py -u -l [options]

Options


--help, -h : affiche ce message d'aide et quitte
--url=URL, -u URL : URL du webshell distant
--lport=LOCAL_PORT, -l : LOCAL_PORT port d'écoute local
--verbose, -v : Mode verbeux (sorties de taille de paquet)
--buffer=BUFFERSIZE, -b BUFFERSIZE* : Taille de la requête HTTP (certains webshells ont des limitations de taille)

Options No SOCKS


Les options sont ignorées si le proxy SOCKS est utilisé
--no-socks, -n : Ne pas utiliser Socks Proxy
--rport=REMOTE_PORT, -r REMOTE_PORT : port de service distant pour que la webshell se connecte à
--addr=REMOTE_IP, -a REMOTE_IP : adresse pour le webshell distant auquel se connecter (par défaut = 127.0.0.1)

Options du proxy en amont


Connexion par tunnel via un proxy local
--up-proxy=UPPROXY, -x : UPPROXY Proxy en amont (http://proxyserver.com:3128)
--auth, -A Le proxy en amont nécessite une authentification

Options avancées


--ping-interval=PING_DELAY, -q PING_DELAY : intervalle de thread webshprx ping (par défaut = 0.5)
--start-ping, -s : Démarrez le thread ping en premier - certains services envoient des données en premier (par exemple, SSH)
--cookie, -C : Demander des cookies
--authentication, -t Basic : Authentication Basic
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 sur HTTP et déballé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) nécessitant une authentification
# vers la webshell distante de Tunna

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 le service 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 intégrée à HTTP


Prérequis


La possibilité de télécharger un webshell sur le serveur distant

LIMITATIONS / BOGUES CONNUS / HACKS


Ceci est un code POC et peut provoquer DoS du serveur.
Tous les efforts pour nettoyer après l'exécution ou par erreur ont été faits (pas de promesses)

Basé sur des tests locaux:
* Le tampon JSP doit être limité (option de tampon):
4096 sous Linux Apache Tomcat
1024 ont travaillé dans XAMPP Apache Tomcat (lent)
* Plus que cela a créé des problèmes avec les octets manquants sur le socket distant
ex: ruby ​​proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v

* Sockets non activées par défaut par les fenêtres php (IIS + PHP)

* Retourner les cariages sur les webshells (en dehors du code):
être envoyé sur les réponses / obtenir écrit sur le socket local -> corrompre les paquets

* PHP webshell pour windows: la fonction loop DoS'es la socket distante:
fonction sommeil ajoutée -> fonctionne mais un peu lent
* PHP webshell a besoin de nouveaux caractères de ligne supprimés à la fin du fichier (après "?>")
comme ils seront envoyés dans toutes les réponses et confondre Tunna

FILES


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

Technical Details


Décisions d'architecture


Les données sont envoyées brutes dans le corps de publication HTTP (pas de variable Post)

Les instructions / configuration sont envoyées à la webshell en tant que paramètres URL (HTTP Get)
Les données sont envoyées dans le corps HTTP (HTTP Post)

Websockets non utilisés: non pris en charge par défaut par la plupart des serveurs Web
Des réponses HTTP asyncronantes pas vraiment possibles
Proxy interroge le serveur en permanence (0,5 seconde par défaut)

PHASE D'INITIATION


1er paquet initie une session avec le webshell - récupère un cookie
par exemple: http://webserver/conn.ext?proxy
2ème paquet envoie des options de configuration de connexion à la webshell
ex: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP et port pour que le webshell se connecte à
Ceci est une requête threadée:
En php cette requête ira dans une boucle infinie
conserver la connexion socket webshell en vie
Dans d'autres webshells, [OK] est renvoyé

CLIENT TUNNA


Un socket local va être créé là où le programme client va se connecter
Une fois le client connecté, le thread de ping est lancé et l'exécution commence.
Toutes les données sur le socket (du client) sont lues et envoyées en tant que requête HTTP Post
Toutes les données sur le socket webshell sont envoyées en réponse à la requête POST

THREAD DE PING


Parce que les réponses HTTP ne peuvent pas être asynchrones.
Ce thread effectuera les requêtes HTTP Get sur la webshell en fonction d'un intervalle (par défaut, 0,5 seconde)
Si la webshell a des données à envoyer, elle l'enverra (aussi) en réponse à cette requête
Sinon, il envoie une réponse vide
En général:
Les données du proxy local sont envoyées avec HTTP Post
Il y a des requêtes Get toutes les 0,5 secondes pour interroger la webshell pour des données
S'il y a des données du côté de la webshell, envoyez-les en réponse à l'une de ces requêtes

WEBSHELL


La webshell se connecte à un socket sur un hôte local ou distant.
Toute donnée écrite sur le socket est renvoyée au proxy en réponse à une requête (POST / GET)
Toutes les données reçues avec un message sont écrites sur le socket.

NOTES


Toutes les demandes doivent avoir le paramètre URL "proxy" défini pour être géré par le webshell (http://webserver/conn.ext?proxy)

A LA SORTIE DU PROGRAMME OU EN CAS D'ERREUR


Tue tous les threads et ferme le socket local, envoie proxy&close au webshell : Kills all threads and closes local socket Sends proxy&close to webshell: Tue les threads distants et ferme le socket

SOCKS


Le support SOCKS est un module addon pour Tunna. Localement est un thread séparé qui gère la connexion les demandes et le trafic ajoute un en-tête qui spécifie le port et la taille du paquet et le transmet à Tunna. Tunna l'envoie au serveur Web distant, supprime les en-têtes HTTP et transmet le paquet à le proxy SOCKS distant. Le proxy SOCKS distant lance la connexion et mappe le port reçu sur le port local. Si le proxy SOCKS distant reçoit des données du service, il examine la table de mappage et trouve le port auquel il doit répondre, ajoute le port en tant qu'en-tête pour que le proxy SOCKS local sache où transmettre les données. Tout trafic provenant du port reçu sera transmis au port local et inversement.

DROIT D'AUTEUR ET EXCLUSION DE RESPONSABILITÉ


Tunna, TCP Tunneling sur HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Cet outil est uniquement à des fins légales.
Ce programme est un logiciel libre: vous pouvez le redistribuer et / ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation, soit la version 3 de la Licence, soit (à votre choix) toute version ultérieure.
Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE; sans même la garantie implicite de QUALITÉ MARCHANDE ou D'ADÉQUATION À UN USAGE PARTICULIER. Voir la Licence publique générale GNU pour plus de détails.
Vous devriez avoir reçu une copie de la licence publique générale GNU avec ce programme. Sinon, voir http://www.gnu.org/licenses/

Avertissement


L'utilisation de ce programme ne peut se faire que dans le cadre légal d'un audit de vulnérabilités, basé sur le consentement mutuel. Il est de la responsabilité de l'utilisateur final de ne pas utiliser ce programme dans un autre cadre. SecuriteInfo.com n'assume aucune responsabilité et n'est pas responsable de toute mauvaise utilisation ou de tout dommage causé par ce programme.

Téléchargement



Partager cet article

Envoyer cet article par Email ! Imprimer cet article ! Exporter cet article en PDF ! Facebook Twitter Google Bookmarks

SecuriteInfo.com est une entreprise française de sécurité informatique. Nous proposons différentes solutions matérielles et prestations de services permettant de sécuriser les données des Systèmes d'Information d'entreprises ou de collectivités. Notre périmètre d'intervention couvre l'intégralité de votre système d'information : Sécurité périmétrique, réseaux, accès distants, VPN, solutions anti-spam et anti-malwares, différents audits réseaux et systèmes, vérification de la politique de sécurité, hébergement sécurisé ...
Facebook SecuriteInfo.com
Twitter de SecuriteInfo.com
Github de SecuriteInfo.com
Calculs scientifiques distribués contre les maladies, équipe SecuriteInfo.com
Profil Virustotal de SecuriteInfo.com
© 2004-2019 - Tous droits réservés - SecuriteInfo.com