Die siberas GmbH ein auf Sicherheitsanalysen und Penetrationstests spezialisiertes Beratungsunternehmen, welches Sie herstellerunabhängig und kompetent im Bereich IT-Sicherheit berät.
“Cool, WATOBO can act as a transparent proxy. But why do I need this feature?” Right, most of the time when you’re pentesting a web application you only have to configure your browser to use a proxy. This will work for most of the applications designed for web browsers.
But there are more and more apps for mobile devices, e.g. iPhones or Androids which also rely on web based applications. Sometimes these apps are not able to use a proxy or even refuse to use one.
For these special cases a transparent proxy is the only way to intercept and modify the communication - beside modifying or hooking the app itself.
Some very special requirements must be met by the proxy and by the Operating System (IP Stack) in order to run a web proxy in transparent mode - especially when SSL connections must be handled.
These are the main tasks which have to be fulfilled:
Because some of these tasks need a direct access to the routing process of the operating system it is only possible (with a minimum effort) on a Linux system. Most of this magic is done with IPTables and NetfilterQueues. The later is an IPTables interface to analyze and modify IP packets from within the userland.
Note: At the time of this writing I’m not aware of any other web testing proxy supporting transparent mode. If you know one, please let me know.
The folling steps will show you how to setup a system running WATOBO as a transparent proxy.
You must met some requirements before working with this tutorial:
The following link might help you if you have problems installing bind9 or dhcp3-server.
Our lab setup is as follows:
Here’s the interface configuration (/etc/network/interfaces):
Note: If you only want to test the transparent feature without a mobile device you don’t need hostapd. Any other additional interface, e.g. eth1 will also work. But don’t forget to adjust the example scripts and commands.
Before you continue with setting up WATOBO this would be a good time to test your general network setup. So, we first convert our system into a simple router which hides our internal IP addresses (NAT). For this, we have to enable IP forwarding and NATing:
Now you should have a working internet connection with your mobile device. If not, you must work on your setup - try harder ;)
Just download and run the installer script.
After the installation script finished open a new shell and type watobo_gui.rb. Then start a new project and open the Interceptor settings menu (Settings -> Interceptor).
Enable the transparent mode and don’t forget to change the Bind Address to make WATOBO listening on the correct interface. In our lab we set it to 0.0.0.0 => listen on all interfaces.
You must restart WATOBO after changing the interceptor settings. After re-open the project the port information in the statusbar should be highlighted in red.
To prevent your app or your browser from complaining (or even stop working) about a wrong certificate you should make your device trust the WATOBO CA. This CA is used to generate the fake server certificates. The CA certificate is generated the first time you start WATOBO and is written to /root/.watobo/CA/cacert.pem
To make your iPhone trust this certificate, send the cacert.pem file via email to your device and install it.
Next we have to start the Netfilter Server. This is our userland process which handles incoming requests before they are redirected to the proxy necessary to keep track of the original destination. I first tried to implement this service inside the WATOBO core process but I run into problems crashing WATOBO imediately. I guess there were some conflicts with other IO streams. My second attempt was to implement it as an XML/RPC service but the same problems occured. Now the process is implemented as a DRb (Distributed Ruby) service which seems to be much more stable. You can get more infos about DRb here.
So, to run this service type:
Note: Unfortunately this service also crashes or hangs from time to time. So just keep an eye on the shell where you started the service. If you see any error message or the service stopped working a simple restart will let the communication continue without any problems.
If I find some time I will write a watchdog service or maybe you want to do it? ;)
Ok, now IPTables comes on the scene. We use it for two tasks: First, we have to redirect incoming traffic imediatly to our Netfilter Server before routing takes place. This can be done with the mangle table of the pre-routing chain. You can find detailed information about IPTables packet-flow here.
In our lab setup we only redirect traffic using port 443 because we have to keep track of the original destination of encrypted connections - we don’t get a CONNECT request when running transparent. This is not necessary for regular HTTP traffic. Here we can extract the original destination from the HTTP Server Header. Anyway, to not slow down communication too much we only want to redirect SYN packets. This can be done with the following command:
After the packet has been processed by our Netfilter Server it’s passed back to the regular packet-flow of IPTables.
The second task is to redirect the traffic to the WATOBO proxy. We do this for the ports 80 and 443:
You can download a little script which does all the necessary IPTables commands for you here or using wget:
Finally just start the app you want to analyze. You don’t have to configure a proxy. If everything went well you should see all the requests in the conversation table of WATOBO - ready to perform some nice checks ;)