Que es Tunna y cómo funciona?

Tunna es un conjunto de herramientas que envolverá cualquier comunicación TCP a través de HTTP. Se puede usar para eludir las restricciones de red en entornos completamente protegidos por cortafuegos.

RESUMEN

TLDR: realiza un túnel de conexiones TCP a través de HTTP

En un firewall completamente cerrado, conexiones entrantes y salientes restringidas, excepto el puerto del servidor web, nos explica un experto en seguridad de datos. El webshell se puede usar para conectarse a cualquier servicio en el host remoto. Esta sería una conexión local en un puerto local en el host remoto y debería ser permitida por el firewall.

El webshell leerá los datos del puerto de servicio los envolverá a través de HTTP y los enviará como una respuesta HTTP al proxy local.

El proxy local desenvolverá y escribirá los datos en su puerto local donde se conectará el programa cliente. Cuando el proxy local recibe datos en el puerto local, los enviará a la webshell como una publicación HTTP. Webshell leerá los datos de la publicación HTTP y los colocará en el puerto de servicio y repite.

Solo el puerto del servidor web debe estar abierto (normalmente 80/443). Toda la comunicación (externa) se realiza a través del protocolo HTTP.

USO

Python proxy.py -u <remoteurl> -l <localport> [options]

Opciones

–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 Verbose tamaño del paquete de salidas.

–buffer = BUFFERSIZE, -b BUFFERSIZE * Tamaño de solicitud HTTP

 Sin opciones de SOCKS

De acuerdo con un profesional en seguridad cibernética, las opciones se ignoran si se utiliza el proxy SOCKS.

–no-socks, -n No use Socks Proxy

–rport = REMOTE_PORT, -r REMOTE_PORT puerto de servicio remoto para que webshell se conecte a –addr = REMOTE_IP, – una dirección REMOTE_IP para que se conecte webshell remoto (predeterminado = 127.0.0.1)

Opciones de Upstream proxy

Conexión de túnel a través de un Proxy local

–up-proxy = UPPROXY, -x UPPROXY Upstream proxy (https://proxyserver.com:3128)

–auth, – Un Upstream proxy requiere autenticación

Opciones avanzadas

–ping-interval = PING_DELAY, -q PING_DELAY intervalo de subproceso de ping webshprx (predeterminado = 0.5)

–start-ping, -s Inicia primero el hilo que hace ping – algunos servicios envían datos primero

–cookie, -C Solicitar cookies

–autenticación, -t autenticación básica

• Limitaciones

Ejemplo: python proxy.py -u https://10.3.3.1/conn.aspx -l 8000 -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Esta conexión se ajustará a través de HTTP y se desenvolverá en el servidor remoto.

python proxy.py -u https://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Se conectará a través de un Proxy local (https://192.168.1.100:3128) que requiere autenticación del remoto webshell de Tunna.

python proxy.py -u https://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v –no-socks

Esto iniciará una conexión entre el webshell y el servicio de host remoto RDP (3389). El cliente RDP se puede conectar en el puerto localhost 4444. Esta conexión se ajustará a través de HTTP.

Requisitos previos

La capacidad de cargar un webshell en el servidor remoto

LIMITACIONES / ERRORES CONOCIDOS / HACKS

Este es un código POC y podría causar DoS del servidor. Se han hecho todos los esfuerzos para limpiar después de la ejecución o por error, de acuerdo a un especialista en seguridad cibernética.

Basado en pruebas locales: El buffer JSP necesita ser limitado (opción buffer):

4096 trabajó en Linux Apache Tomcat

1024 trabajó en XAMPP Apache Tomcat, muy lento.

Más que eso creó problemas con la falta de bytes en el socket remoto, por ejemplo: ruby proxy.rb -u https://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v

Sockets no habilitados por ventanas php predeterminadas (IIS + PHP). Devuelve carias en webshells fuera del código: recibir respuestas enviadas / escritas en el socket local -> corromper los paquetes.

PHP webshell para Windows: la función de bucle hace el socket remoto: función de reposo añadida. PHP webshell necesita nuevos caracteres de línea eliminados al final del archivo después de “?>”  ya que estos serán enviados en cada respuesta y confundirán a Tunna, nos dice un experto en seguridad de datos.

ARCHIVOS

Webshells:

conn.jsp Probado en Apache Tomcat

conn.aspx Probado en IIS 6 + 8 (servidor de Windows 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

Detalles técnicos

Decisiones de arquitectura. Los datos se envían sin formato en el cuerpo de publicación de HTTP. Las instrucciones / configuración se envían a webshell como parámetros de URL (HTTP Get). Los datos se envían en el cuerpo HTTP.

Websockets no utilizados: la mayoría de los servidores web no los admiten por defecto.

Las respuestas HTTP asíncronas no son realmente posibles. El proxy consulta constantemente al servidor (por defecto 0.5 segundos)

FASE DE INICIACIÓN

El primer paquete inicia una sesión con webshell: recupera una cookie, por ejemplo: https: //webserver/conn.ext?proxy

El segundo paquete envía las opciones de configuración de conexión a la webshell, por ejemplo: https: //webserver/conn.ext?proxy & port = 4444 & ip = 127.0.0.1

IP y puerto para que la webshell se conecte. Esta es una solicitud enhebrada: En php esta solicitud entrará en un bucle infinito para mantener viva la conexión del socket webshell. También, nos dice el profesional en seguridad cibernética, en otras webshells [OK] se recibe de nuevo.

CLIENTE TUNNA

Se creará un socket local al que se conectará el programa de cliente. Una vez que el cliente está conectado, se inicia el hilo de ping y se inicia la ejecución. Todos los datos en el socket del cliente se leen y se envían como una solicitud HTTP Post. Todos los datos en el socket webshell se envían como respuesta a la solicitud POST.

PINGING THREAD

Porque las respuestas HTTP no pueden ser asincrónicas. Este hilo hará HTTP obtenga solicitudes en el webshell en función de un intervalo (predeterminado de 0,5 segundos). Si el webshell tiene datos para enviar, también lo enviará como respuesta a esta solicitud. De lo contrario, enviará una respuesta vacía.

En general: los datos del proxy local se envían con publicación HTTP. Hay solicitudes Get cada 0,5 segundos para consultar los datos de webshell si hay datos en el lado webshell enviados como respuesta a una de estas solicitudes

WEBSHELL

Webshell se conecta a un socket en el host local o remoto. Cualquier información escrita en el socket se envía de vuelta al proxy como respuesta a una solicitud (POST / GET) Cualquier información recibida con una publicación se escribe en el socket.

NOTAS

Todas las solicitudes deben tener el parámetro de URL “proxy” configurado para ser manejado por el webshell (https: //webserver/conn.ext?proxy)

AT EXIT / AT ERROR

Elimina todos los hilos y cierra el socket local. Envía el proxy y lo cierra a webshell: elimina los hilos remotos y cierra el socket

SOCKS

El soporte de SOCKS es un módulo de complemento para Tunna. Localmente hay 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. De acuerdo al experto en seguridad de datos, Tunna lo envía al servidor web remoto, elimina los encabezados HTTP y reenvía el paquete al proxy SOCKS remoto. El proxy remoto SOCKS inicia la conexión y asigna el puerto recibido al puerto local. Si el proxy SOCKS remoto recibe datos del servicio, mira la tabla de asignación y encuentra el puerto al que necesita responder, agrega el puerto como un encabezado para que el proxy SOCKS local sepa a dónde reenviar los datos. Cualquier tráfico del puerto recibido se enviará al puerto local y viceversa.