mitm

Tapping 802.1x Links with Marvin

abb — Sat, 15 Jan 2011 03:35:27 +0000

Tapping 802.1x Links with Marvin

While testing fat clients and appliances for resistance against man-in-the-middle attack I always had to mess with iptables/ebtables/socat to divert network connections. It is enough in most cases, but sometimes the setup gets too elaborate. To make my life easier, I have decided to write a tool, capable to divert and re-inject a network connections while preserving the original network addresses, including layer 2 ones. The tool is not complete yet, but it already can be used to tap into a wired network protected with 802.1x, so I've decided to publish it anyway.

Update 15/01/2011: Initially the tool has been published under the name of Mallory, but it turned out there is a TCP/UDP mitm tool with this name, so I had to change the name to Marvin.

Update 27/01/2011: New version of the tool, Marvin 0.91, can be downloaded from here. It supports connection interception and includes numerous GUI improvements. Unfortunately as of now it is not extensively tested nor documented. It should be reasonably straightforward though -- just click on 'Intercept' button in 'Conversations' table. If you have any questions or problems feel free to comment here.

Intended Use

I have to say upfront that Marvin has nothing to do with ARP poisoning or similar techniques. It will not impact any remote traffic flow. The assumption is that the pen-tester cuts the link and connect two cables to the host running Marvin. The diagram below illustrates the tapping:

The tool will bridge the traffic between the first and the second interface and inject traffic it receives from the third interface into the first two. The pen-tester is expected to connect another host to the third network interface to enjoy ICMP/TCP/UDP connectivity to the bridged network. The source addresses of the injected frames/packets will be masqueraded (on IP and Ethernet levels), as configured by the user.

Step 1. Install and Run

The simplest way to run Marvin is on a box with three physical network interfaces. It must be Linux with Java JRE, and you must have root privileges there. The tool is self-contained, all libraries it needs are bundled with it.

The latest build can be downloaded from here. The tarball contains a sample config file marvin.properties, and a script called marvin.sh which should be used to launch the tool.

Marvin uses JPcap (wrapper around libpcap) to receive and send Ethernet frames, so you have to run it as root. Run it with '-t' option to disable GUI, add '-d' option to increase the logging level, set '-l marvin.log' to redirect all logging output into a file. Use '-f configfile' to specify path to a config file explicitly (marvin.properties from the same directory as marvin.sh is the default choice).

I will assume you wire the first interface (eth1) to the legitimate client, the second (eth2) -- to the switch, and the third (eth3) -- to the tap client. (Alternatively you can also run Marvin in VM and use host OS as tap client. This way you will need only one computer with two physical network interfaces. I can write the instructions for this use case if someone is interested).

The configuration file bundled with the tool is relevant to my testbed only. Unless you have very similar setup, you will have to reconfigure to fit your environment before it does anything useful. You can do it by manually editing the config file or via GUI.

Just as an example, the IP addressing scheme of my testbed (which corresponds to the default config bundled with Marvin) looks like following:

Step 2: Make Bridging Work

On startup Marvin reads the config and, if the config was correct, starts working right away. Unless you run Marvin with '-t' flag, the following GUI will appear:

There you can change any parameter in runtime and click 'Apply' button.

At the very minimum you have to select the interfaces Marvin will send and receive network traffic. For example:

Set br1if.interface parameter to the interface name facing the client (eth1)
Set br2if.interface parameter to the interface name facing the switch (eth2)
Set tapif.interface parameter to the interface name facing the tap client (eth3)

Now the bridge between eth1 and eth2 is active, all traffic being forwarded transparently. The legitimate 802.1x client should be able to authenticate towards the network and have network access as usual.

Step 3. Configure Tap Interface and Masquerading

Now let's finish off the config file and set parameters necessary for tap clients to access the bridged network. If you use GUI, you can click on 'Select ...' button to access the list of suitable candidates to use for masquerading addresses. For the first interface Marvin will suggest to use stations connected to the second interface, and visa versa. The list of candidates may appear empty if Marvin has not seen any ARP messages yet.

The following parameters have to be set, via GUI or in the config filie:

MAC and IP address of the legitimate client. Marvin will use it to masquerade the tap client when it accesses the network. Set br2if.smac and br2if.saddr accordingly.
MAC and IP address of some host on the network (i.e. default gateway). Marvin will use it to masquerade the tap client when it accesses the legitimate client. Default gateway seems to be an adequate choice here, but it can be absolutely anything as long as the legitimate client swallows it. Set br1if.smac and br1if.saddr accordingly.
IP address of the default gateway and the netmask. Have a look at the content of DHCP Offer message, if any. Marvin needs this information to route traffic to non-directly connected hosts. Set br.netmask and br.gateway accordingly.

Now, connect you tap client host to the third interface and restart Marvin (or apply the config). If you haven't modified the default values, set tap client to use 10.0.1.2 as IP address, 255.255.255.252 as netmask, and 10.0.1.1 as default gateway. Try to ping the hosts on the bridged link, it should work.

Information About the Relayed Connections

Marvin GUI has several tabs which contain information about ARP/ICMP/TCP/UDP flows and conversations it relays/translates (a conversation is a pair of unidirectional flows). You can peek there for troubleshooting purposes, but under high load you can experience inconsistency in the displayed information. I don't have documentation for these screens yet, only a screenshot of Marvin masquerading TAP client traffic. Here tap client (10.0.1.2) is pinging the legitimate client (172.16.208.148). Marvin translates the source IP address of a tap client (10.0.1.2) into IP address of the default gateway (172.16.208.2). MAC addresses get translated too, but you can't see it on this screen.

Performance

The performance is not bad at all. Marvin is multi-thraded and will benefit from multi-core CPUs. It can certainly handle nmap SYN scan in normal mode, but will die soon if you try to run nmap at wire speed (-T insane). Obviously, it has to keep connection states for every TCP SYN and expire them. If you have hundreds thousands of active connections these tasks will start to take quite a bit of memory and CPU. Running in VM with two CPUs and relaying a SYN scan, it will let nmap go up to 3kpps.

Additional Information

I know the explanations could be more clear, I will certainly write better docs in the future. If you have any problems or questions, just post a comment here and I will reply. Again, the download is here.

For now the project is closed source. More likely than not 1.0 release will be open source under GNU or Apache License.

There is a couple of PDF documents which may shed some light on how the tool is working. These slides contain more less the same info as this post. This table explains the packet manipulation process in some more details.

The following features will be added in the future (higher priority first):

Make a better package
~~Fix stats display inconsistencies~~ (done in 0.91)
NAPT (now ports are not translated)
Enqueue IP packets pending ARP resolution (now they are dropped)
~~Connection interception rules~~ (done in 0.91)
Automatically prepare connection re-injection rules
Save the config, retain the interception rules between restarts
802.1q
Full ICMP support (now only ICMP echo is supported)
Move to JNetPcap
IP packet reassembly (now fragmented packets are dropped)
ARP entry expiration (now learned IP-MAC resolution remains forever)

abb Sat, 01/15/2011 - 04:35

SSH Man-in-the-Middle Attack and Public-Key Authentication Method

abb — Sat, 25 Dec 2010 21:44:44 +0000

SSH Man-in-the-Middle Attack and Public-Key Authentication Method

SSH is a protocol for secure remote login and other secure network services over insecure networks. To detect man-in-the-middle attacks SSH clients are supposed to check the host key of the server, for example by comparing it with a known good key. Should the client neglect to check the server key (or an attacker manage to steal the private key of the server) the connection becomes vulnerable to active man-in-the-middle attacks, according to RFC 4251, The Secure Shell (SSH) Protocol Architecture (section 4.1) and other resources.

The above statement is indeed true for password-based authentication. There are some tools implementing the attack, for example MITM-SSH. However, there are no tools implementing MITM against an SSH connection authenticated using public-key method (this feature is in TODO list of the above mentioned tool though). Being pressed to produce a PoC for this attack, I have attempted to implement it only to discover it is quite impossible and here is why.

During SSH connection setup the peers use Diffie-Hellman to generate encryption keys and a session ID. We assume that MITM attacker has already managed to circumvent the server host key validation and tricked the peers into establishing the connection. Effectively, there are two connections: first between the client and the attacker, and second between the attacker and the server. In case of password authentication the game is over: the attacker can see the password sent by the client, relay it to the server, and basically do whatever he or she wants.

The things are a bit more complicated in case of the public key authentication method. The client uses its private key to generate a signature and submits the signature to the server. RFC 4252, The Secure Shell (SSH) Authentication Protocol (section 7) tells us exactly how the signature is generated:

   To perform actual authentication, the client MAY then send a
   signature generated using the private key. ... The signature is sent
   using the following packet:

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "publickey"
      boolean   TRUE
      string    public key algorithm name
      string    public key to be used for authentication
      string    signature

   The value of 'signature' is a signature by the corresponding private
   key over the following data, in the following order:

      string    session identifier
      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "publickey"
      boolean   TRUE
      string    public key algorithm name
      string    public key to be used for authentication

Now the attacker has a problem, as the client and the server have different ideas about what session identifier is supposed to be. Obviously, the server will reject the signature supplied by the client and public-key authentication will fail.

The session identifier is calculated based on (among other things) the shared secret negotiated by the peers using Diffie-Hellman algorithm. The algorithm itself does not protect against active MITM attack, but it makes it impossible for MITM attacker to influence the choice of the shared key (and by extension the session ID) by the victims.

So public-key authentication has somewhat unexpected side effect of preventing MITM. Nice to know.

abb Sat, 12/25/2010 - 22:44

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