[aklug] SSL MITM Howto

From: Shane Spencer <shane@bogomip.com>
Date: Wed Dec 22 2010 - 21:15:42 AKST

Not sure if this will benefit anybody... but here it goes.

I've recently been reverse engine... analyzing some packets in order
to save money. yeh. Thankfully one of the few HTTP RPC protocols I'm
dissecting wasn't wrapped in SSL. The rest are which makes the
following more or less necessary.

First I'd like to point out that there are lots of programs out there
that can help out with this process.
  1. httpservers.py -
http://code.google.com/p/gnucitizen/source/browse/trunk/httpservers.py
  2. socat

Use option 1 if your application can actually use a proxy for HTTP(S)
traffic. Since I'm on an iPhone and Android doing all this the odds
of an application being Proxy aware are slim. The iPhone admittedly
has done a lot of work to make sure that little proxy setting means
something in their own products but 3rd party apps don't often honor
it. Option 1 is a bit buggy as well. Have fun.

Both options need a valid self signed SSL certificate:
  openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout
sslcert.pem -out sslcert.pem

When you sign this certificate make sure the Common-Name is the
address of the site you are trying to access to avoid invalid
certificate errors on the client. The easiest way to find this out is
to use a proxy server that logs SSL connections since it typically
logs the request hostname. Alternatively just run tcpdump and scan
for DNS requests.

Next... add the .pem to your CA trusts which there are tons of ways to
do depending on the whos and whats. For a recent iPhone I found out
through accident that if you just slap that .pem file on a web server
somewhere and browse to it in safari you can add the cert as a
"personality" which is apparently a codename for global or session CA
trust relationship as far as functionality is concerned.

Each system library and many applications handle CA trust in their own
special way.. your mileage may vary.

Option 2 is the most reliable but has heavier dependencies.

First off.. run socat somewhere on your network.. preferably somewhere
not already hogging port 443 on the interface you need to use. In
this example we want to connect to secure.baloogacity.com

  socat -v OPENSSL-LISTEN:443,fork,reuseaddr,verify=0,cert=sslcert.pem,key=sslcert.pem
\
    OPENSSL-CONNECT:secure.baloogacity.com:443,verify=0 2>&1 | tee -a
session.log

If you have control of the DNS for your network.. add the common-name
to a new DNS zone and do some test lookups.. the new A records should
point to your machine running socat.

You can also use DNAT or REDIRECT. I prefer iptables REDIRECT on the
gateway which is also running socat. In this case
secure.baloogacity.com has a server IP of 50.34.22.12

  iptables -t nat -A PREROUTING -p tcp -d 50.34.22.12 --dport 443 -j
REDIRECT --to-ports 443

At this point.. if iptables likes you.. and socat likes you.. and your
device/application lets you muck with its CA trust.. then you can sit
back and watch requests and responses fly around your screen as you
access the remote site.

Using another method earlier this year to deal with HTTPS traffic
snooping I learned how to interface to my banks web server now in
order to download transactions. I wonder if they even know how to do
that......

I guess what this points out is.. you're only as secure as your
keychain. I can see how on almost every platform, given a little root
access to mangle packet redirection, any virus type program could slip
in what it needs and glean your information. I suppose having a virus
that changes your internet proxy settings for your session (as you)
and changes your CA trust (as you) would work just as well.

- Shane
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Dec 22 21:15:49 2010

This archive was generated by hypermail 2.1.8 : Wed Dec 22 2010 - 21:15:49 AKST