Cookies are harmless (and yummy!). We use them to improve your experience on our site. To find out more, read our updated privacy policy and cookie policy.
Tunna is a set of tools which will wrap and tunnel any TCP communication over HTTP.
Due to popular demand, in this new version, Tunna (v1.1a) can be set up to be a local SOCKS proxy, that will accept any TCP traffic and send over to the webserver using HTTP requests. The traffic will be unwrapped at the server and forwarded to the specified address/port. Tunna effectively pivots connections through a webserver; thus bypassing firewall restrictions.
Secondary functionality added in the new version:
Tunna is now able to connect to the local proxy (if exists) and through the internal proxy, then tunnel the connection to the webserver.
A standalone Tunna webserver has been added for situations were a webserver is not available.
Windows compiled binaries for both “Tunna Client” and “Tunna webserver” have been added.
Ping delay increases (up to 60 sec) whenever data is not received. This minimises network traffic to the webserver with a small hit on waiting time that should be unnoticeable.
Tunna v1.1a Changelog:
Added SOCKS4a support
Tunna webserver
Windows binaries
Support for UpStream Proxy
Removed Ruby version of Client
Usage:
python proxy.py -u <remoteurl> -l 8000
This will set up Tunna and start a SOCKS4a proxy server on port 8000
SOCKS Operation Details:
Local ports are mapped to remote ports. For this, a header is added in every HTTP packet sent to/from the webserver that shows the originating/remote port. Once the packet is received, the header port is read and the rest of the data gets redirected to the correct port on the local side.
Limitations:
The SOCKS server is a simple implementation based on SOCKS protocol version 4 RFC. Currently SOCKS BIND method is not supported and protocols such as FTP cannot be used.
Bypassing Firewall restrictions:
Inbound restrictions:
As in the previous version if inbound HTTP traffic is allowed a webshell or Tunna webserver can be used to pivot connections.
For example, an external user can upload a Tunna webshell (or use Tunna webserver) on a remote webserver and request a service on the local host or any other host that will normally be blocked by the firewall. The request will be forwarded to the webserver in the form of an HTTP request (must be allowed by the firewall). The webserver is going to establish the connection for the user and redirect all traffic to that service. Response data will be transferred back to Tunna’s client in the form of HTTP responses.
Outbound restrictions:
Tunna can be used in situations where the firewall restricts access to certain hosts or services.
A user controlled Tunna webserver is needed as well as HTTP access to the remote webserver.
For example, an internal user can set Tunna (client) as his system’s proxy and request any website/service that is blocked. The request will be forwarded to the webserver in the form of an HTTP request. The webserver will establish the connection to the requested service and redirect all traffic to that service. Response data will be transferred back to Tunna’s Client in the form of HTTP responses.
Up-stream proxy:
In many companies, internal connections to the internet go via an internal proxy that restricts access to certain services or websites. Tunna can be configured to use that proxy for requests to Tunna’s webserver.
Tunna will get the proxy settings from the system (internet) options and use them for all requests. If this is not possible, then the proxy parameters can be set up as an argument (currently DIGEST and BASIC authentications are supported)
Tunna webserver:
This is a python standalone webserver for Tunna. The functionality is the same as a webserver that has a Tunna webshell.
Usage:
python webserver.py -r 0.0.0.0:8000
Will start a Tunna webserver listening on port 8000
Append --ssl to add SSL support (https)
In Windows (webserver.exe) the certificate file (certificate.pem) needs to be present in the same folder as the executable
Tunna SOCKS webshells:
For Tunna to be used as a SOCKS server when webshells are used, an executable that will handle the SOCKS traffic will be uploaded to the remote webserver and executed.
Disclaimer:
As well as Tunna generating a massive overhead for every TCP packet, theconnections are tunnelled through a single channel using HTTP requests. Consequently, large amounts of traffic translate to large amounts of HTTP requests. When a Tunna webshell is used, then this can lead to a Denial of Service condition where the webserver will not be able to cope with all the requests.The standalone Tunna webserver is significantly less prone to DOS.
Some functionality is still experimental; therefore it is recommended that Tunna webshells are not to be used as a permanent solution.
Although the mechanisms for clean-up and graceful shutdown are in place, in certain situations,when a Tunna webshell is used andthe “SOCKS Server” executable is not properly stopped and/or removed from the disk; then it will require a manual clean-up.
