A couple of months ago SECFORCE was set to create the ultimate webshell. The idea behind it was to include all the tools a pentester needs in one webshell and make our lifes easier by for example dropping a meterpreter shell on the remote webserver with as less user interaction as possible.
Soon it was apparent that it would be much “cooler” for the webshell to communicate with a meterpreter shell without the need for meterpreter to expose or bind an external port. The benefits of it are obvious – this would effectively bypass any firewall rules in place.
It was realised that this could be a nice tool on its own so the project was forked and development started. Some time later a set of webshells and the client proxies were created. The task was not as easy as it seems, mostly because it is hard to keep it simple and at the same time make the same code work across different languages. Still there are some “programming language” quirks that could not be bypassed or made transparent to the end user. Given the different technologies in play (web servers / web languages / client languages) and all the possible combinations it would be very hard to tackle some of the issues and make it seamless to the end user without loosing some of the tools flexibility. Having said that, Java proved to be the most problematic language of the whole bunch – this needs to be said. Java was eating bytes in large packets – reasons for this are still not obvious – making both debugging and optimisation a pain. Apart from that, the PHP webshell also works in a somehow different way where it stalls a thread on the remote server to keep the connection alive. However, the latter is seamless to the user.
What Tunna does is to open a TCP connection (socket) between the webserver (webshell) and a socket on the local machine (webserver). It is also possible to open a connection to any other machine but lets keep this example simple. The client also opens a local socket and starts listening for connections. When a connection is established on the local client any communication would be sent over to the webshell in an HTTP request. The webshell will extract the data and put write them its local socket (remote socket for the client). Now the problem with HTTP is that you cannot really have asynchronous responses. The easiest way to tackle this issue was to keep querying the webshell for data. This creates a lag but it is nothing a pentester cannot live with – at this point it must be noted once more that this is a tool “to get a remote meterpreter shell if the firewall is blocking external connections” and not for critical/real-time applications.
After that, we went back to the original idea and created the metasploit module. It is still under development and should be used with extreme caution. It is still recommended to upload a meterpreter shell and use Tunna main module to connect to it. The metasploit module can be summarised as a “half rewrite of the existing code to work with or around metasploit API” (mostly around). This means that “code hacks” were created as needed to make it work. To be architecturally correct with metasploit, the original idea was to create a new metasploit “handler” … however, this proved to be harder than expected and what you get is a bastardisation of handler-exploit … but it works.
Lastly, any comments, bugs or improvement ideas are welcome.
For more information, visit our Tunna Framework page.
Download: Tunna v0.1
