Donnerstag, 16. August 2012


In WATOBO version 0.9.9 I introduced a new plugin which builds a bridge between WATOBO and sqlmap (

To bring up the plugin right-click on the request you want to test and select 'Send to' -> SQLmap:

The plugin provides an easy to use interface:

There are predefined menus for typical sqlmap options like Technique, Risk and Level. You also can add any command line option manually, e.g. for further enumeration tasks.

When you press the start button WATOBO will first write the request to a file in the temp directory which will be parsed by sqlmap (-r option). Then it opens a new command window and runs sqlmap.

Have Phun!

WATOBO 0.9.9 Supports Transparent Mode

"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.

Running Transparent

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:
- intercept the request before the request arrives at the proxy
- keep track of the original destination of the request
- get the certificate of the original destination to extract the CommonName
- create a fake certificat with the correct CommonName
- redirect the request to the proxy
- proxy must lookup the original destination
- lookup for the correct certificate
- do the SSL handshake

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.

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.

Lab Setup

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:
- BackTrack 5R2
- DHCPD (dhcp3-server)
- DNS (bind9) server
- HostAP Daemon up and running to connect your mobile device

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):
auto eth0
iface eth0 inet dhcp

auto wlan0
iface wlan0 inet static

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.

Testing Basic Communication

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:
echo "Turn on NATing"
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo "Enable IP forwarding"
echo 1 > /proc/sys/net/ipv4/ip_forward

Now you should have a working internet connection with your mobile device. If not, you must work on your setup - try harder ;)

Time To Install WATOBO

 Just download and run the installer script.


Start And Configure WATOBO 

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  => 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.

Import The WATOBO CA Certificate

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.

Start Netfilter Server

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:

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? ;)

Configure IPTables

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:

iptables -t mangle -A PREROUTING -p tcp -m state --dport 443 --state NEW -j NFQUEUE --queue-num 0

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:

iptables -t nat -A PREROUTING -i wlan0 -p tcp -m tcp -j REDIRECT --dport 443 --to-ports 8081
iptables -t nat -A PREROUTING -i wlan0 -p tcp -m tcp -j REDIRECT --dport 80 --to-ports 8081

You can download a little script which does all the necessary IPTables commands for you here or using wget:


 Start Analyzing Your App

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 ;)

Have Phun!