Man-in-the-Middle Server Impersonation

The Challenge
Over the years I’ve seen many presentations on Main-in-the-Middle (MitM) attacks via ARP poisoning and have found a number of tools that can do this, but I’ve never seen anyone present this technique targeting a specific server-client connection with the aim of testing the client side. Recently I was given the task to audit a piece of software that makes a secure connection (HTTPS) to a server and transfers data back and forward. This brings up a number of challenges: first and foremost is traffic redirection, i.e., getting in the middle, getting in the middle is trivial if the attack machine resides on the same network as the victim machine, any of these tools can perform ARP poisoning: Cain, Ettercap, Dsniff, etc. The second challenge is to impersonate a specific server, i.e., respond only to traffic destined to the server that is to be impersonated, and last but not least is to break or bypass SSL encryption.

I initially began testing by using Cain to perform ARP poisoning. Cain is a feature-full penetration testing application, which I used to perform the MitM attack. So being able to redirect traffic, the task of bypassing SSL can also be done with Cain right? Not so fast. Cain does have the ability to proxy SSL connections; it generates certificates for any SSL connection it sees and replies to the client with the generated certificates while at the same time connecting to the server side, relaying the connection. This worked great when I was testing SSL connections with a Web browser to a number of sites, but Cain failed when attempting to proxy connections for the server I was interested in impersonating. I am not sure exactly why Cain failed (“Couldn’t accept SSL connection from the client”), it may have to do with SSL cipher strength, or somehow the client knew that the certificate that Cain generated was invalid, whatever the case, Google was not much help. Even if this had worked, I wanted to reply to a specific outbound connection, but Cain simply allowed me to eavesdrop (snoop) on traffic, not to impersonate a server.

The second challenge of replying to a specific connection (server impersonation) seemed a bit tough at first since I’ve never heard of a tool to do this, or so I thought. I was a bit puzzled until I figured that all I need to do was to masquerade packets forwarding them to my target machine and reply to the connection as if the request was being made directly to my attack machine. Now what tool can I use to masquerade packets? Iptables? Of course, using Iptables I was able to reply only to a specific server from a specific client.

First we need to be able to forward packets:

echo 1 > /proc/sys/net/ipv4/ip_forward

Then we need to masquerade packets:

iptables -t nat -A PREROUTING -i eth0 -p tcp -s victim -d server –dport 443 -j REDIRECT –to-port 443

So at this point I am redirecting all traffic from the victim through my attack machine and impersonating the target server. I used Ettercap (switched from Cain since Cain only runs on Windows) to redirect traffic through the attack machine via ARP poisoning, and Iptables to change the destination IP address of the target server. At this point, I setup Apache to make the SSL connection and server data to the client. I wrote a quick and dirty PHP script to fuzz the client, but Apache kept on giving me some out of memory errors when my responses got too big. So I then wrote a couple of one-line fuzzers that did not use Apache:

Fill up memory with AAA…:

ruby -e ‘while true; print “A”; end’ | nc -l -p 80

Fill up memory with random data:

ruby -e ‘while true; print rand(127).chr; end’ | nc -l -p 80

Now the only challenge was to feed this data through an SSL channel. While searching for other SSL proxies, since Cain proved to be the wrong tool, I ran into this little tool called Stunnel, universal SSL tunnel. By simply setting three options in its configuration file (client=no, accept=80, connect=443) I was able to setup a listener on port 443, which is redirects traffic to port 80.

Not too bad eh…

Assumptions

  • Attack machine is on the same network as victim machine
  • Client does not perform SSL verification

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.