Man-in-the-Middle Attacks

Man-in-the-middle (MITM) attacks are named for the attacker’s position as quite literally the man in the middle. The attacker site between two other parties, and both of them believe they are talking to each other but , instead, they are really talking to the man in the middle, the attacker.

To accomplish the classic version of this attack, the attacker must either be located between the two communicating systems or must share a network Path with one of them.

When encrypted connections are set up, a secret key is generated between the two parties and transmitted.

This key is used to encrypt any communications between two parties is not readable by would-be attackers who may be sniffing the network, because the key is sent securely and used to encrypt the subsequent traffic.

In an MITM attack, the two parties trying to communicate securely are tricked. Although the server thinks it is talking to the user, and the user thinks it is talking to the server, they are both wrong; they are really talking to the attacker.

The original request to open a secure connection was intercepted by the attacker, and the attacker is maintaining the originally requested secure connection with the server and a separate secure connection with the user.

Packets from the server are encrypted with the first key and sent to the attacker, which the server actually thinks is the user. The attacker then decrypts these packets with the first key and encrypts them with the second key. Then the attacker sends the newly encrypted packets to the user, who believes these packets are actually being sent by the server.

By sitting in the middle and maintaining these two separate keys, the attacker is able to sniff and even modify traffic between the server and the user without either side being the wiser.

The attacker is sitting on the same network as the server and the victim but wants to intercept the traffic between the two. In preparing for the attack, the attacker has routed the network traffic through itself so that the attacker can see the traffic.

The user now tries to open a Secure Sockets Layer (SSL) conversation with the server, but the attacker intercepts the traffic and responds as if he were the server, issuing a key with which to encrypt the traffic between itself and the user. The user responds with its key and a two-way SSL conversation is now in place between the user and the attacker, but because the attacker responded to a request made to the server, the user thinks he is talking directly to the server.

At the same time, the attacker opens an SSL conversation with the server itself as if it were actually the user. The server responds to the request with a key with which to encrypt the data between the attacker and the sever. The attacker responds with its own key, and there is now a two-way SSL conversation in place between the attacker and the server.

At this point, the server and the user think they are talking to each other, but the attacker is actually sitting between them, holding a secure connection to both of them. When data is sent, the attacker takes the data, decodes it with the appropriate key and then reencodes it with the other key and sends it on to the intended recipient. The attacker now has the transmitted data as unencoded to use as it wishes.

An interesting variation of the MITM attack was reported in July 2006. This attack targeted the users of CitiBank's CitiBusiness functionality. This attack was carried out by sending to Citibank customers an e-mail that claimed to be from Citibank. The e-mail informed the victims that someone attempted to log onto their account, and they need to confirm their account information. The e-mail included a link to do so. This is a fairly standard phishing email.

Now CitiBusiness customers are required to use one of the seldom supplied security token to access their account online. This is one of the little fobs generating a password that changes frequently (every minute perhaps). This is a much-touted way to improve security.

Once the victim clicks on the link in the e-mail, they are taken to a very well-done spoof of the Citibusiness login page. Even its address appears believable as it ends with Citibank.com. However it is really a web site in Russia.

This spoofed Web site is set up to act as the MITM between the victim and the real Citibusiness login site. When victims enter their username. password. and token-generated key, the Russian server forwards that information to the real Web site to validate it. If an error is generated by the real Citibank Web site, the spoofed Web site also generates an error.

Now the Russian site is logged into the Citibusiness site with the victim's credentials and can do whatever it wants.

Most testing of MITM attack vulnerabilities is begun by looking carefully at all protocols in use in your system to determine what information they exchange and how. In the clear? How is the remote server identified.

If your method of identification is to put out a call and trust whatever system answers to he the correct one, you are most likely vulnerable to an MITM attack.

Once you find a likely candidate to test, you can use one of the session-hijacking and MITM tools available to see if you can demonstrate the vulnerability.

https://www.owasp.org/index.php/Man-in-the-middle_attack