secforce/tunnaTunna es un conjunto de herramientas que encapsulan y tunelizan cualquier comunicación TCP a través de HTTP. Puede utilizarse para evadir restricciones de red en entornos completamente cortafuegados.
Tunna es un conjunto de herramientas que envolverán y tunelizarán cualquier comunicación TCP sobre HTTP. Se puede utilizar para eludir restricciones de red en entornos completamente protegidos por firewall.
v1.1 Versión Alpha
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, para tunelizar conexiones TCP sobre HTTP por Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Tuneliza conexiones TCP sobre HTTP
En un entorno completamente protegido por firewall (conexiones entrantes y salientes restringidas - excepto el puerto del servidor web)
La webshell se puede usar para conectarse a cualquier servicio en el host remoto. Esto sería una conexión local en un puerto local en el host remoto y debería estar permitida por el firewall.
La webshell leerá datos del puerto del servicio, los envolverá sobre HTTP y los enviará como respuesta HTTP al proxy local.
El proxy local desempaquetará y escribirá los datos en su puerto local donde el programa cliente estaría conectado.
Cuando el proxy local recibe datos en el puerto local, los enviará a la webshell como una petición HTTP Post.
La webshell leerá los datos del HTTP Post y los colocará en el puerto del servicio y repite --^
Solo el puerto del servidor web necesita estar abierto (generalmente 80/443) Toda la comunicación (externamente) se realiza sobre el protocolo HTTP
python proxy.py -u <remoteurl> -l <localport> [options]
--help, -h muestra este mensaje de ayuda y sale
--url=URL, -u URL url de la webshell remota
--lport=LOCAL_PORT, -l LOCAL_PORT
puerto de escucha local
--verbose, -v Verboso (muestra tamaño de paquete)
--buffer=BUFFERSIZE, -b BUFFERSIZE*
Tamaño de la petición HTTP (algunas webshells tienen limitaciones en
el tamaño)
Las opciones se ignoran si se usa un proxy SOCKS
--no-socks, -n No usar Proxy SOCKS
--rport=REMOTE_PORT, -r REMOTE_PORT
puerto remoto del servicio al que se conectará la webshell
--addr=REMOTE_IP, -a REMOTE_IP
dirección para que la webshell remota se conecte (por defecto =
127.0.0.1)
Tunelizar conexión a través de un proxy local
--up-proxy=UPPROXY, -x UPPROXY
Proxy ascendente (http://proxyserver.com:3128)
--auth, -A El proxy ascendente requiere autenticación
--ping-interval=PING_DELAY, -q PING_DELAY
Intervalo del hilo de ping de webshprx (por defecto = 0.5)
--start-ping, -s Iniciar primero el hilo de ping - algunos servicios envían
datos primero (ej. SSH)
--cookie, -C Cookies de solicitud
--authentication, -t Autenticación básica
ejemplo de uso:
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Esto iniciará un Servidor Proxy SOCKS Local en el puerto 8000
# Esta conexión se envolverá sobre HTTP y se desempaquetará en el servidor remoto
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Esto iniciará un Servidor Proxy SOCKS Local en el puerto 8000
# Se conectará a través de un Proxy Local (https://192.168.1.100:3128) que requiere autenticación
# a la webshell remota de Tunna
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Esto iniciará una conexión entre la webshell y el servicio RDP (3389) del host remoto
# El cliente RDP puede conectarse en localhost puerto 4444
# Esta conexión se envolverá sobre HTTP
La capacidad de subir una webshell en el servidor remoto
Este es un código POC y puede causar DoS del servidor.
Se han hecho todos los esfuerzos para limpiar después de la ejecución o en caso de error (sin promesas)
Basado en pruebas locales:
* El buffer JSP necesita ser limitado (opción buffer):
4096 funcionó en Linux Apache Tomcat
1024 funcionó en XAMPP Apache Tomcat (lento)
* Más que eso creó problemas con bytes faltantes en el socket remoto
ej: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Sockets no habilitados por defecto:
php windows (IIS + PHP)
XAMPP Windows
php linux (servidor web integrado de PHP/apache + PHP)
Si tienes el error Uncaught Error: Call to undefined function socket_create()
ver https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Retornos de carro en webshells (fuera del código):
se envían en las respuestas / se escriben en el socket local --> corrompen los paquetes
* PHP webshell para windows: la función de bucle DoS el socket remoto:
se agregó la función sleep -> funciona pero un poco lento
* PHP webshell necesita eliminar los caracteres de nueva línea al final del archivo (después de "?>")
ya que estos se enviarán en cada respuesta y confundirán a Tunna
Webshells:
conn.jsp Probado en Apache Tomcat (windows + linux)
conn.aspx Probado en IIS 6+8 (windows server 2003/2012)
conn.php Probado en LAMP + XAMPP + IIS (windows + linux)
Servidor Web:
webserver.py Probado con Python 2.6.5
Proxies:
proxy.py Probado con Python 2.6.5
Los datos se envían sin procesar en el cuerpo del HTTP Post (sin variable post)
Las instrucciones/configuración se envían a la webshell como parámetros de URL (HTTP Get)
Los datos se envían en el cuerpo HTTP (HTTP Post)
Websockets no usados: No soportados por defecto por la mayoría de servidores web
Respuestas HTTP asíncronas no realmente posibles
El proxy consulta el servidor constantemente (por defecto 0.5 segundos)
El primer paquete inicia una sesión con la webshell - recibe una cookie ej: http://webserver/conn.ext?proxy
El segundo paquete envía opciones de configuración de conexión a la webshell ej: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP y puerto para que la webshell se conecte
Esta es una solicitud con hilos:
En php esta solicitud entrará en un bucle infinito
para mantener viva la conexión del socket de la webshell
En otras webshells se recibe [OK]
Se va a crear un socket local donde el programa cliente se va a conectar Una vez que el cliente está conectado, se inicia el hilo de ping y comienza la ejecución. Cualquier dato en el socket (del cliente) se lee y se envía como una petición HTTP Post Cualquier dato en el socket de la webshell se envía como respuesta a la petición POST
Debido a que las respuestas HTTP no pueden ser asíncronas. Este hilo hará peticiones HTTP Get a la webshell basadas en un intervalo (por defecto 0.5 seg) Si la webshell tiene datos para enviar, los enviará (también) como respuesta a esta petición De lo contrario envía una respuesta vacía
En general: Los datos del proxy local se envían con HTTP Post Hay peticiones Get cada 0.5 seg para consultar la webshell por datos Si hay datos en el lado de la webshell, se envían como respuesta a una de estas peticiones
La webshell se conecta a un socket en el host local o remoto. Cualquier dato escrito en el socket se devuelve al proxy como respuesta a una petición (POST/GET) Cualquier dato recibido con un post se escribe en el socket.
Todas las peticiones deben tener el parámetro de URL "proxy" establecido para ser manejadas por la webshell (http://webserver/conn.ext?proxy)
Mata todos los hilos y cierra el socket local Envía proxy&close a la webshell: Mata los hilos remotos y cierra el socket
El soporte SOCKS es un módulo adicional para Tunna. Localmente es un hilo separado que maneja las solicitudes de conexión y el tráfico agrega un encabezado que especifica el puerto y el tamaño del paquete y lo reenvía a Tunna. Tunna lo envía al servidor web remoto, elimina los encabezados HTTP y reenvía el paquete al proxy SOCKS remoto. El proxy SOCKS remoto inicia la conexión y mapea el puerto recibido al puerto local. Si el proxy SOCKS remoto recibe datos del servicio, busca en la tabla de mapeo y encuentra el puerto al que necesita responder, agrega el puerto como encabezado para que el proxy SOCKS local sepa dónde reenviar los datos. Cualquier tráfico del puerto recibido se reenviará al puerto local y viceversa.
Tunna, Tunelización TCP sobre HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Esta herramienta es solo para fines legales.
Este programa es software libre: puedes redistribuirlo y/o modificarlo bajo los términos de la Licencia Pública General de GNU publicada por la Free Software Foundation, ya sea la versión 3 de la Licencia, o (a tu elección) cualquier versión posterior.
Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin siquiera la garantía implícita de COMERCIABILIDAD o IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Consulte la Licencia Pública General de GNU para obtener más detalles.
Deberías haber recibido una copia de la Licencia Pública General de GNU junto con este programa. Si no, consulta http://www.gnu.org/licenses/.