SSL MiM proxy
-------------

legal stuff:

By running this program you maybe break law in your country.
This program is ment to understand how crypto (and SSL in special)
works and how it can be disabled. You should never mount the attack
on other persons connections.

This program uses library (OpenSSL) Copyright by Eric Young. 


How to install
-------------

mimd/filterd runs only on linux 2.2 to 2.4 (and probably FreeBSD)
by now.
This is due to the way of getting the real destination of
a redirected connection.
Make sure you installed openssl and its accessible by gcc
(libs and includes). Then just type 'make' and watch
whats coming. Play with -I switches until it works. :)

Edit Makefile and say which OS you are going to run mimd on.
Add LINUX22 for Linux w/ kernel 2.2, LINUX24 and FREEBSD
for kernel 2.4 and FreeBSD respectively. 

How to run
----------

This program allows you to mount the so called "Man in the Middle"
attack against SSL connections. By doing that, "mimd" acts
as fake-server for the attacked connection. It silently
records the data sent and forwards it to its real destination
(probably some https-server). To get in between the two parties,
you need to set up a port forwarding rule on a machine that
sits either directly between the two parties (so calld gateway)
or that is 'made' the gateway by poisoning the arp-cache
of the client. The rules look like

(Linux, kernel 2.2)

ipchains -A input -s 192.168.0.2 -d 0/0 -j REDIRECT 10000 -p tcp 

as shell command for linux. This will redirect all traffic from 192.168.0.2
to our so called "filterd" program which sits on port 10000 and looks
for SSL handshakes (that is when someone tries to start a SSL session).
So, fire up filterd by

filterd -p 10000

It is now ready to watch whats coming. Add a new rule like

(Linux, kernel 2.2)

ipchains -A input -s 0/0 8888:10000 -d 0/0 994 -j REDIRECT 10001 -p tcp 

which will redirect all traffic sourced from port 8888 up to 10000 and 
destinated to port 994 (we expect a stunnel server on port 994 for
example) to local
port 10001. That are the connections which "filterd" recognized as SSL
sessions. On port 10001 now we make the real "mimd" listen:

mimd -p 10001 -C certfile -K keyfile

which does the MiM attack itself. For that matter you need to create
your own private key which is used during attack:

CA.pl -newcert

Which will put the (private) key and the certificate (containing public
key) into file newreq.pem. So, in most cases certfile equals keyfile.
CA.pl is shipped with OpenSSL package. Anyway, you need SSL thats clear.
Make sure you enabled firewalling, forwarding
and all the neat things in your kernel.
In the current working directory of "mimd" you will find files
"mim.*.*.*" which contain the decrypted data (client and server side).

Recognized connections and errors are sys-logged.

Since filterd only understands SSLv3 handshakes you may want
to run mimd against your own https sessions directly to get SSLv2 too.
Just set up the firewall-rules propperly and it works very well
without filterd. I think its clear how to do ...

You may want to see what your netescape is sending along the SSL stream
to the https-server. 'mimd' is the perfect tool to monitor that
session, (and its still encrypted by mimd!) and to look
for suspicious data.

For localhost-testing, you'd need to add rules like this:

ipchains -A input -p tcp -d 0/0 443 -s 0/0 1000:3000 -j REDIRECT 10000

for 2.2 kernels and

iptables -t nat -A OUTPUT -p tcp --sport 1000:3000 --dport 443 -j REDIRECT --to-port 10000

for 2.4 kernels

and start mimd for port 10000. Because of localhost,
you only redirect ports 1000 to 3000 (which you suspect to come
from netescape) to mimd. Mimd itself binds to port 8888 and up
and thus it doesn't loop!

You can use the tool 'cf' to fetch the certificate of a SSL capable server.
To analyze it, type smt. like 

cf 127.0.0.1 443|openssl x509 -text

which gives you complete certificate text.


FreeBSD 4.0 rule looks like

ipfw 200 add fwd 127.0.0.1,10000 tcp from any to any 443

to redirect https traffic to local port 10000.
(Thanks to smiler.)

DCA
---

Dynamic Certificate Assembly allows to place
'apropriate' subject/issuer and serialnumber into X509-certificate
upon HTTPS-request.
At best create a certificate/key as described above
and just fill in Country (C-field). For the rest
give it a "." which leaves it empty. 'mimd' will
put in the right data on the fly when invoked with -D switch.
When using -D without -I, mimd will use subject name etc.
and put it into corresponding issuer fields. This is good
to remove issuers where netescape has apropriate public key.
You can force using real issuer with -I switch. Mimd will then append
a " " to the OU field, thus making it differ from real
issuers and most clients won't use the saved key for
verifying and accept the cert. This way you can tamper with
connections which are 'protected' by commercial signers.

AGAIN, I ASSUME YOU DO THAT IN YOUR OWN TEST-LABS TO STRENGTH
SECURITY OR YOU USE THIS DURING PENETRATION TESTINGS.
IT IS NOT ALLOWED TO MOUNT THIS ATTACK TO OTHER USERS
CONNECTIONS IF THEY DO NOT AGREE.




CREDITS
-------

Smiler for BSD firewalling stuff
anonymous@segfault.net for secnet testlab.


