Transparent Connection Interception Trick

abb — Wed, 07 Jul 2010 17:09:31 +0000

Now when I have a blog for half a year I figured I should post something. So here goes description of using Linux (Ubuntu in my case) bridge configured to redirect selected TCP connections to intercepting proxy (Burp) and while letting the intercepting proxy communicate with the server. Quite useful when doing pentests of fat clients and appliances communicating over HTTP(S), especially in a situation when you can't tamper with client's /etc/hosts file or use other technique to redirect interesting traffic.

Assuming the networking and bridging are configured, there is one thing which needs to be done to start playing with traffic redirection. You should create a group which will be used to designate local processes exempt from traffic redirection. Here I use group name 'noredir' which is hardcoded in 'do_redirect.sh' script, so you have to alter it if you decide to use another group name.

$ sudo addgroup noredir
Adding group `noredir' (GID 1003) ...
Done.

Choose a password and generate a hash for it. You can also just take the one specified below, it corresponds to an empty password.

$ echo -n | mkpasswd 
Password: 
H4ueB58xqisRQ

Set the password for 'noredir' group. (Yes, groups can have passwords. You didn't know? Neither did I.) Edit /etc/gshadow file and change

noredir:!::

noredir:7eVADNYgCIWO6::

Now by issuing 'sg noredir' command you can easily spawn a new shell process with primary GID set to 'noredir'. You will need it to control what iptable rules get applied to traffic generated by programs I use.

$ id
uid=1000(abb) gid=1000(abb) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb)

$ sg noredir
Password: 

$ id
uid=1000(abb) gid=10000(noredir) groups=4(adm),20(dialout),24(cdrom),29(audio),46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(abb),10000(noredir)

Now run Burp under 'noredir' group.

$ sg noredir
Password: 
$ java -jar burpsuite_pro_v1.3.jar

Proxy options must be set as following:

loopback only = NO
support invisible = YES

Consider disabling interception until the networking part is working fine. If some of services under attack run over SSL, you may want to provide SSL keys as well. Having one listener for both HTTP and HTTPS traffic has worked out for me.

Now everything is ready to kick off traffic redirection. Create a shell script file like the one shown below and save it in the same directory as do_redirect.sh file available here.

#!/bin/sh -xe

snatip=XXX.YYY.64.57
burpport=8008

. `dirname $0`/do_redirect.sh

reset_redirects
redirect_tcp XXX.YYY.3.187 80 $burpport
redirect_tcp XXX.YYY.3.215 8088 $burpport
redirect_tcp XXX.YYY.8.57 80 $burpport

true

Some explanations regarding redirect_tcp() function are in order.

TCP connections (originated by from local programs and in bridged traffic) heading towards the selected TCP ports get redirected to local TCP port 8008. NB: this port has to be bound to *, ports bound to 127.0.0.1 will not receive redirected traffic. Don't ask me how I know.
Connections originated by Burp (and other programs running under 'noredir' group) don't get redirected. You will know something goes wrong here if Burp hangs and eventually run out of file handles. If you get this it is better to restart Burp.
Connections exempt from redirection get SNAT'ed to the specified IP address. You should manually set 'snatip' to the IP address of the client under attack. This is done to prevent server from noticing requests are coming from another IP address. (The same can be done with source MAC address if needed.) If SNAT'ting is not required, don't set this variable.
All other traffic gets bridged. One notable exception is link-local traffic such as 802.1x. You have to tweak the kernel a bit to make the described approach work on 802.1x-enabled links, check this article for details.

All this is implemented in do_redirect.sh file using iptables and ebtables. Have a look inside if you are interested in how it is actually done.

The end.

abb Wed, 07/07/2010 - 19:09

connection interception

Transparent Connection Interception Trick