Making Linux network bridge transparent for 802.1x packets

abb — Tue, 31 Aug 2010 09:33:58 +0000

Update 17/01/2011: If you are interested in 802.1x bridging, have a look at my Tapping 802.1x Links with Marvin blog post.

802.1x authentication messages are sent in Ethernet frames with destination MAC address set to 01:80:C2:00:00:03. This address belongs to “IEEE 802.1D MAC Bridge Filtered MAC Group Addresses” (01:80:C2:00:00:00 to 01:80:C2:00:00:0F) and such frames are not supposed to be relayed by bridges conforming to IEEE 802.1D [2]. For a number of reasons, you may want these frames to go through your bridge.

The quick and dirty way to solve the problem is to hack the Linux kernel – just comment out the “unnecessary” functionality. To do so:
1) Unpack your kernel sources and prepare for compilation
2) Apply a patch.
3) Compile and install the kernel

Steps 1 and 3 are specific to your distribution, these instructions works file for my Ubuntu. Step 2:

abb@d820:~/build$ cd linux-2.6.27/
abb@d820:~/build/linux-2.6.27$ patch -p0 < ~/br_input.patch
patching file net/bridge/br_input.c

abb Tue, 08/31/2010 - 11:33

Transparent Connection Interception Trick

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

Transparent Connection Interception Trick

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