First: the following attack is not a real (at least not a perfect) man-in-the-middle attack, since the target will get a warning about the altered SSH server footprint and the attacker needs to “hijack” the communication between the target and the SSH server (ARP cache poisoning for example…), but I think the tool deserves a note (all the credits for the software goes to David Gümbel).

I remember, the first time I downloaded JMITM2 from http://www.david-guembel.de/index.php?id=6I was sitting in a web cafe near to the university with a friend trying to “attack” each others SSH2 connection. Tonight I am alone, so I started two Damn Small Linux (DSL) in Virtualbox. One will be the SSH server (192.168.56.101), other will be the attacked client (192.168.56.102) and the host will be the attacker (192.168.56.1).

After starting the SSH server on 192.168.56.101 with the commands “sshstart” and “/etc/init.d/ssh start” and connecting to the service from the client machine (192.168.56.102) to get the RSA fingerprint it is time to prepare the attacker machine.

I will start with JMITM2 since it needs some configuring and arpspoof is pretty simple to use…

First we need to edit JMITM2′s bin/conf/server.xml file and change the “ListenAddress” to our IP (192.168.56.1 in this case) and “Port” to the standard SSH port (22).

Now let’s edit the bin/runm.sh script and set the SSH server’s IP address (192.168.56.101) as the first parameter:

JMITM2 is set up, for arpspoof we just need a few iptables rules:

We need to spoof “two-ways” so two arpspoof will be running (the attacked machine must think we are the SSH server and normally the SSH server should think we are the attacked machine), so we should run “arpspoof -i vboxnet0 -t 192.168.56.101 192.168.56.102″ as well.

After these steps when the target tries to connect to the SSH server he will connect to us (hopefully provide us a password  ) and we will build a new connection to the SSH server in his name (just like a proxy). Of course the situation is not that simple. When the attacked machine connects to us JMITM2 will start connecting to the SSH server and ask us if we accept the provided fingerprint (this is necessary only first time) – of course we accept it. JMITM2 sends a login prompt to the attacked machine, but the SSH client will warn the user, that the fingerprint sent by us is not the same as the “original” SSH server’s:

If the user “wants to continue connecting” (which he really should not!) we will get his/her credentials:

(by the way as you can see JMITM2 generates a lot of output, “grep” is recommended  )

The session for the attacked user of course will work correctly, we will “proxy” every command and result.

Some things to notice:

• the attack absolutely depends on the attacked user, if he doesn’t accept the changed RSA key fingerprint we are lost
• maybe I was not careful enough, but JMITM2 builds the connection to the SSH server in our name (from our IP), so the attacker IP will be logged on the server…  I will check soon if this is how it is meant to work.
• ARP spoofing is bad

Maybe later I will play with the plugin features of JMITM2, I think there will be some more fun to discover.

// I welcome every comment or observation…