Man-in-the-Middle Attack

A man-in-the-middle attack (MITM) is an attack against a cryptographic protocol. As the name implies, in this attack the attacker sits in the middle and negotiates different cryptographic parameters with the client and the server.

Implications of the Attack

A man-in-the-middle attack may permit the attacker to completely subvert encryption and gain access to the encrypted contents, including passwords. A successful attacker is able to inject commands into terminal session, to modify data in transit, or to steal data.

The attack also allows injecting malware into any binaries and software updates downloaded through the system. Several attack groups and malware packages have used this technique in the past.

For web traffic, the attack allows utilizing browser vulnerabilities for breaking into the computers running the browsers or completely subverting any browser-based application and stealing passwords and other confidential data from them.

How to Do a Man-in-the-Middle Attack

Technically, performing a successful man-in-the-middle attack is rather complex. However, sophisticated tools for performing them are readily available, and they are very commonly used by hackers and malware. For example, Metasploit supports many kinds of man-in-the-middle attacks out-of-the-box and tools like Armitage provide a graphical user interface for performing many kinds of man-in-the-middle attacks remotely.

Performing a man-in-the-middle attack generally requires being able to direct packets between the client and server to go through a system the attacker controls. Arp spoofing is commonly used for redirecting traffic in a local network to the attacker's system. Various routing attacks can be used to perform the attack remotely. It is also common for hackers and malware to attack routers, DSL modems, and WiFi base stations to install malware on them that performs the man-in-the-middle attack.

The attack software then implements both the client and server sides for the protocol being attacked. When the client connects, the attack tool acts as a server, and negotiates a session with the client. It then acts as a client, and negotiates another encrypted connection with the server.

Server Keys in Man-in-the-Middle Attacks

There are basically three different modes for performing a man-in-the middle attack as it comes to keys:

  • The man in the middle may use a newly generated server key, or a self-signed certificate. Many people will automatically accept changed keys, and thus enable the attacker to do anything to their connection.
  • The attacker may have been able to penetrate the server earlier and steal its server key. The attacker may also have obtained the key in other ways, such as from decommissioned equipment that was not properly wiped. A stolen key may have also been purchased from cybercriminals.
  • The attacker may be able to generate certificates from a certificate authority trusted by the client. This is a typical attack mode used by governments against HTTPS.

Protection Against Attacks

To protect against man-in-the-middle attacks, there needs to be some kind of shared trust or shared secret between the client and server. The most commonly used methods are:

  • An X.509 certificate (as in Tectia SSH and SSL/TLS)
  • Some kind of proprietary certificate mechanism (e.g., OpenSSH)
  • A public key on the client and a private key on the server (e.g., SSH)
  • A shared secret value (e.g., IPSec with preshared keys).

In the SSH protocol, the traditional method is to use public keys. Most SSH clients will trust the server's key during the first connection, on the theory that at any given time a man-in-the-middle attack on the network is unlikely, and it provides the best possible tradeoff between usability and security for grass-roots deployment.

Managing Host Keys in SSH

In SSH, host keys protect against man-in-the-attacks, but they need to be properly managed, they need to be unique for each server, and they need to be changed periodically and whenever a compromise is suspected.

Host certificates (standard X.509 certificates in Tectia SSH and proprietary certificates in OpenSSH) are very helpful in achieving this goal.