In light of John Strand’s newest demonstration, I thought I would come up with some methods for keeping your SSHv2 password safe from this attack.

Firstly, on the broadcast network that you’re going to authenticate over, keep an eye on the MAC addresses at work here. Make sure that there are no duplicate MAC addresses on the network. What you’re ideally doing here, is keeping an eye out for ARP spoofing.

Secondly, before authenticating, use host to check out the IP address of the domain your SSH server is on. For example:

~$ host zitstif.no-ip.org
zitstif.no-ip.org has address 69.209.112.233

Remembering at least part of your IP address will help mitigate the risk. However, if you use the host command and then notice output that looks like this:

~$ host zitstif.no-ip.org
zitstif.no-ip.org has address 192.168.1.104

You may be on your local area network, (which in this case, you should know your server’s LAN IP). However, if you’re not in your own network, then chances are dnsspoof, may be in use or some other tool.

Another method of mitigating the risk of this attack is by using an ssh key. By using an ssh key and password-less authentication, you can essentially remove the risk of dictionary attacks. However, my argument against using ssh keys, is that they can be copied if a computer that has the ssh key is compromised. I still stand by password authentication, because the ‘key’ is essentially in your head, unless you write down your passwords and with the exception of your password being stored on a remote server, which you hope the remote server’s owner took the necessary precautions to encrypt the password.

However, this all depends on the strength of your password policy.

More to come…