secforce/tunnaTunna ist eine Sammlung von Werkzeugen, die jede TCP-Kommunikation über HTTP verpackt und tunnelt. Sie kann verwendet werden, um Netzwerkbeschränkungen in vollständig durch Firewalls geschützten Umgebungen zu umgehen.
Tunna ist eine Sammlung von Werkzeugen, die jede TCP-Kommunikation über HTTP verpacken und tunneln. Es kann verwendet werden, um Netzwerkbeschränkungen in vollständig durch Firewalls geschützten Umgebungen zu umgehen.
v1.1 Alpha-Version
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, für HTTP-Tunneling von TCP-Verbindungen von Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Tunnelt TCP-Verbindungen über HTTP
In einer vollständig durch Firewalls geschützten Umgebung (ein- und ausgehende Verbindungen sind eingeschränkt – außer dem Webserver-Port)
Die Webshell kann verwendet werden, um eine Verbindung zu einem beliebigen Dienst auf dem entfernten Host herzustellen. Dabei handelt es sich um eine lokale Verbindung auf einem lokalen Port des entfernten Hosts, die sollte von der Firewall erlaubt sein.
Die Webshell liest Daten vom Dienst-Port, verpackt sie über HTTP und sendet sie als HTTP-Antwort an den lokalen Proxy.
Der lokale Proxy entpackt die Daten und schreibt sie auf seinen lokalen Port, mit dem das Client-Programm verbunden ist.
Wenn der lokale Proxy Daten auf dem lokalen Port empfängt, sendet er sie als HTTP-Post an die Webshell.
Die Webshell liest die Daten aus dem HTTP-Post und legt sie auf dem Dienst-Port ab.
und wiederhole --^
Es muss nur der Webserver-Port geöffnet sein (normalerweise 80/443) Die gesamte Kommunikation (extern) erfolgt über das HTTP-Protokoll
python proxy.py -u <remoteurl> -l <localport> [optionen]
--help, -h Diese Hilfe anzeigen und beenden
--url=URL, -u URL URL der entfernten Webshell
--lport=LOCAL_PORT, -l LOCAL_PORT
lokaler Listening-Port
--verbose, -v Ausführlich (zeigt Paketgrößen an)
--buffer=BUFFERSIZE, -b BUFFERSIZE*
HTTP-Anfragegröße (manche Webshells haben Einschränkungen
bezüglich der Größe)
Optionen werden ignoriert, wenn ein SOCKS-Proxy verwendet wird
--no-socks, -n Keinen SOCKS-Proxy verwenden
--rport=REMOTE_PORT, -r REMOTE_PORT
entfernter Port des Dienstes für die Webshell zum Verbinden
--addr=REMOTE_IP, -a REMOTE_IP
Adresse für die entfernte Webshell zum Verbinden (Standard =
127.0.0.1)
Tunnel-Verbindung durch einen lokalen Proxy
--up-proxy=UPPROXY, -x UPPROXY
Upstream-Proxy (http://proxyserver.com:3128)
--auth, -A Upstream-Proxy erfordert Authentifizierung
--ping-interval=PING_DELAY, -q PING_DELAY
Intervall des Webshprx-Ping-Threads (Standard = 0.5)
--start-ping, -s Ping-Thread zuerst starten – manche Dienste senden
Daten zuerst (z. B. SSH)
--cookie, -C Anfrage-Cookies
--authentication, -t Basisauthentifizierung
Beispielverwendung:
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Dies startet einen lokalen SOCKS-Proxy-Server auf Port 8000
# Diese Verbindung wird über HTTP verpackt und auf dem entfernten Server entpackt
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Dies startet einen lokalen SOCKS-Proxy-Server auf Port 8000
# Es verbindet sich über einen lokalen Proxy (https://192.168.1.100:3128), der eine Authentifizierung erfordert,
# mit der entfernten Tunna-Webshell
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Dies initiiert eine Verbindung zwischen der Webshell und dem Remote-Host-RDP-Dienst (3389)
# Der RDP-Client kann sich auf dem lokalen Host Port 4444 verbinden
# Diese Verbindung wird über HTTP verpackt
Die Möglichkeit, eine Webshell auf dem entfernten Server hochzuladen
Dies ist ein Proof-of-Concept-Code und kann zu einem DoS des Servers führen.
Es wurden alle Anstrengungen unternommen, um nach der Ausführung oder bei Fehlern aufzuräumen (keine Garantie)
Basierend auf lokalen Tests:
* JSP-Puffer muss begrenzt werden (Puffer-Option):
4096 funktionierte unter Linux Apache Tomcat
1024 funktionierte unter XAMPP Apache Tomcat (langsam)
* Größere Werte verursachten Probleme mit fehlenden Bytes auf dem entfernten Socket
z. B.: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Sockets sind standardmäßig nicht aktiviert:
PHP Windows (IIS + PHP)
XAMPP Windows
PHP Linux (PHP Built-in-Webserver/Apache + PHP)
Wenn der Fehler "Uncaught Error: Call to undefined function socket_create()" auftritt,
siehe https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Wagenrückläufe in Webshells (außerhalb des Codes):
werden in Antworten gesendet / auf lokalen Socket geschrieben --> korrumpieren die Pakete
* PHP-Webshell für Windows: Die Schleifenfunktion verursacht DoS auf dem entfernten Socket:
Schlaf-Funktion hinzugefügt -> funktioniert, aber etwas langsam
* PHP-Webshell benötigt, dass Zeilenumbrüche am Ende der Datei (nach "?>") entfernt werden,
da diese in jeder Antwort gesendet werden und Tunna verwirren.
Webshells:
conn.jsp Getestet auf Apache Tomcat (Windows + Linux)
conn.aspx Getestet auf IIS 6+8 (Windows Server 2003/2012)
conn.php Getestet auf LAMP + XAMPP + IIS (Windows + Linux)
Webserver:
webserver.py Getestet mit Python 2.6.5
Proxies:
proxy.py Getestet mit Python 2.6.5
Daten werden roh im HTTP-Post-Body gesendet (keine Post-Variable)
Anweisungen / Konfiguration werden als URL-Parameter an die Webshell gesendet (HTTP-Get)
Daten werden im HTTP-Body gesendet (HTTP-Post)
Websockets werden nicht verwendet: Standardmäßig von den meisten Webservern nicht unterstützt
Asynchrone HTTP-Antworten sind nicht wirklich möglich
Proxy fragt den Server ständig ab (Standard 0,5 Sekunden)
Paket initiiert eine Sitzung mit der Webshell – erhält ein Cookie zurück z. B.: http://webserver/conn.ext?proxy
Paket sendet Verbindungskonfigurationsoptionen an die Webshell z. B.: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP und Port, mit dem die Webshell verbunden werden soll Dies ist eine Thread-gesteuerte Anfrage: In PHP läuft diese Anfrage in einer Endlosschleife, um die Socket-Verbindung der Webshell am Leben zu erhalten In anderen Webshells wird [OK] zurückgegeben
Ein lokaler Socket wird erstellt, mit dem sich das Client-Programm verbindet. Sobald der Client verbunden ist, wird der Ping-Thread gestartet und die Ausführung beginnt. Alle Daten auf dem Socket (vom Client) werden gelesen und als HTTP-Post-Anfrage gesendet. Alle Daten auf dem Webshell-Socket werden als Antwort auf die POST-Anfrage gesendet.
Da HTTP-Antworten nicht asynchron sein können. Dieser Thread führt HTTP-Get-Anfragen an die Webshell in einem Intervall (Standard 0,5 Sekunden) durch. Wenn die Webshell Daten zu senden hat, sendet sie diese (auch) als Antwort auf diese Anfrage. Andernfalls sendet sie eine leere Antwort.
Im Allgemeinen: Daten vom lokalen Proxy werden mit HTTP-Post gesendet. Es werden alle 0,5 Sekunden Get-Anfragen gestellt, um die Webshell nach Daten abzufragen. Wenn auf der Webshell-Seite Daten vorhanden sind, werden diese als Antwort auf eine dieser Anfragen gesendet.
Die Webshell verbindet sich mit einem Socket auf dem lokalen oder einem entfernten Host. Alle Daten, die auf den Socket geschrieben werden, werden als Antwort auf eine Anfrage (POST/GET) an den Proxy zurückgesendet. Alle Daten, die mit einem Post empfangen werden, werden auf den Socket geschrieben.
Alle Anfragen müssen den URL-Parameter "proxy" gesetzt haben, um von der Webshell verarbeitet zu werden. (http://webserver/conn.ext?proxy)
Alle Threads beenden und lokalen Socket schließen. Sendet proxy&close an die Webshell: Entfernte Threads beenden und Socket schließen
Der SOCKS-Support ist ein Addon-Modul für Tunna. Lokal läuft ein separater Thread, der die Verbindungsanfragen und den Datenverkehr verwaltet, einen Header hinzufügt, der den Port und die Paketgröße angibt, und ihn an Tunna weiterleitet. Tunna sendet ihn an den entfernten Webserver, entfernt die HTTP-Header und leitet das Paket an den entfernten SOCKS-Proxy weiter. Der entfernte SOCKS-Proxy initiiert die Verbindung und bildet den empfangenen Port auf den lokalen Port ab. Wenn der entfernte SOCKS-Proxy Daten vom Dienst empfängt, sucht er in der Mapping-Tabelle und findet den Port, auf den er antworten muss, fügt den Port als Header hinzu, damit der lokale SOCKS-Proxy weiß, wohin die Daten weitergeleitet werden sollen. Jeglicher Datenverkehr vom empfangenen Port wird an den lokalen Port weitergeleitet und umgekehrt.
Tunna, TCP-Tunneling über HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Dieses Werkzeug ist nur für legale Zwecke bestimmt.
Dieses Programm ist freie Software: Sie können es unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veröffentlicht, entweder Version 3 der Lizenz oder (nach Ihrer Wahl) jeder späteren Version weitergeben und/oder modifizieren.
Dieses Programm wird in der Hoffnung verbreitet, dass es nützlich sein wird, jedoch OHNE JEGLICHE GEWÄHRLEISTUNG; sogar ohne die stillschweigende Garantie der MARKTGÄNGIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK. Siehe die GNU General Public License für weitere Details.
Sie sollten zusammen mit diesem Programm eine Kopie der GNU General Public License erhalten haben. Falls nicht, siehe http://www.gnu.org/licenses/.