Man-in-the-middle Attack

Overview

A man-in-the-middle attack is an active wiretapping in which the attacker catches and replaces a communication between two endpoints without either endpoint knowing the transmission is modified.

Diffie-Hellman Key Exchange

Recall the Diffie-Hellman key exchange protocol.

Let \(p\) be a (safe) prime number.
Let \(g\) be a generator for the multiplicative group \(\mathbb{Z}_p^*\).

Then the protocol proceeds as follows:

Alice chooses a random exponent \(a\) from \(\{1, ..., p-1\}\), and computes \(A = g^a \bmod p\). Alice sends \(A\) to Bob.
Bob also chooses a random exponent \(b\) from \(\{1, ..., p-1\}\), and computes \(B = g^b \bmod p\). Bob sends \(B\) to Alice.

The common secret key is computed as follows:

Note that Alice has chosen \(a\), using which she can compute the key as \(B^a \bmod p\).
Note that Bob has chosen \(b\), using which he can compute the key as \(A^b \bmod p\).

Note that \(B^a = (g^b)^a = g^{ab}\), and \(A^b = (g^a)^b = g^{ab}\). Therefore, Alice and Bob will share the same key.

Quick check

The following shows an execution of the Diffie-Hellman key exchange protocol. Fill in the blanks.

prime number p = 23
generator g = 4



Alice:                                  A = ____                  Bob:
exponent a = 4                      --------------->              exponent b = 6             


                                        B = ____
                                   <---------------

Ka = (___)^(___) mod ___ = ____                                   Kb = (___)^(___) mod ___ = ____

------
* Ka must be equal to Kb.

Check the answer.

Man-in-the-middle attack

DH key exchange protocol is vulnerable to a man-in-the-middle attack.

In the picture above, the attacker sits in the middle, and runs two separate key-exchange protocols, one with Alice and the other with Bob. Then, it obtains key, say \( K_1 \), shared with Alice and another key, say \( K_2 \), shared with Bob.

Alice sends an encryption of message using \(K_1\), thinking that only Bob can decrypts the message. However, it's actually the attacker who will decrypt the message. (The same situation goes for Bob as well.)
The attacker may forward the message from Alice to Bob to avoid detection by re-encrypting the message using \(K_2\) so that Bob's decryption may work fine.

Fix: So, The DH key exchange protocol needs an authentication mechanism that confirms that a message really comes from Alice or Bob instead of some other parties. One popular mechanism is PKI + digital signature.

MiM Attack through DNS Spoofing

Domain Name System (DNS) protocol resolves the name to an address. For efficiency, a DNS server builds a cache of recently used domain names.

A standard DNS query looks as above.

A user requests a translation of URL.
The name server responds with the address of URL.

DNS spoofing

The DNS spoofing attack proceeds as follows:

The attacker sniffs the DNS query from the user.
The attacker quickly responds with address 20.20.20.20 (perhaps an address over which the attcker has control).
Since the user already received and cached the response, the response from the actual name server will be ignored.

Man in the middle

With the change of the incorrect translation, the attacker can enter into the middle of the user's communication with www.microsoft.com.

Fix

The DNSSEC protocol has been developed to address the insecurity of the traditional DNS protocol. With DNSSEC, nameservers use digital signatures to authenticate the senders of mapping information.

Greek Cell Phone Interception

Vodafone Greece is that country's largest cell phone provider.

The Greek wiretapping case of 2004-2005, also referred to as Greek Watergate, involved the illegal tapping of more than 100 mobile phones on the Vodafone Greece network belonging mostly to members of the Greek government and top-ranking civil servants.

Ericsson switch and the legal wiretaps

Vodafone Greece uses electronic switches and software by Ericsson, a Swedish manufacturer of telecommunication equipment.
In modern mobile telecommunication networks, legal wiretaps are performed at the switch, and some countries ask telecommunication equipment companies for an extra feature that implements court-ordered wiretaps. The Ericsson switch provides an add-on for lawful intercepts as well.
However, Vodafone didn't obtain this add-on since it did not want to implement that feature. So, the delivered switches did not contain that code.

Exploit through upgrade

In 2003, Ericsson upgraded the software in its switches, and inadvertently included the malicious code performing illegal wiretaps in the switches delivered to Vodafone. The code was there but Vodafone didn't know of it!

Discovery of illegal taps

In 2005, an intruder update of exchange software resulted in customer text messages not being sent. Vodafone Greece sent firmware dumps of the affected exchanges to Ericsson for analysis. Ericsson located the rogue code, 6500 lines of very sophisticated code written in the PLEX programming language used by the Ericsson switches.

Who did it?

On September 2011, new evidence emerged indicated the US Embassy in Athens was behind the telephone interceptions. The key evidence was as follows:

A person purchased 4 anonymous prepaid mobile phones used for the interception.
There was a phone call from one of the above phones to the US Embassy in Athens.
The phone had a sim card registered to the US Embassy,
The phone also had two telephone numbers in Ellicott City and Catonsville, Maryland, both NSA bedroom communities.

In 2015, Greek investigators were finally able to finger a suspect, William George Basil, a NSA operative from a Greek immigrant background. Greek authorities have issued a warrant for Basil's arrest, who has since gone into hiding.

Man in the Browser Attack

A man-in-the-browser attack is a malware that infects a browser. Code inserted into the browser can read what the user enters in a browser.

The threat here is that the attacker will intercept and reuse credentials to access finalcial accounts and other sensitive things.

SilentBanker

For example, SilentBanker is a Trojan horse that links to a victim's browser as an add-on or browser helper object. As a helper object, it sets itself to intercept internal browser calls, receiving data from the keyboard, sending data to a URL, generating or importing a cryptographic key, reading a file, etc.

SilentBanker starts with a list over 400 URLs of popular banks throughout the world. Whenever it sees a user going to one of those sites, it redirects the user's banking activity through the Trojan horse and records customer details that it sends to the remote attacker.

Encryption doesn't help

Banking and other financial transactions are ordinarily protected in transit by an encrypted session using HTTPS. However, the SilentBanker embedded within the browser, SilentBank effectively key-logged credentials and user information even before the browser could encrypt its data to transmit to the bank,

Data manipulation

If a customer tells the bank to transfer money to an account at bank A, SilentBanker converted that request to make the transfer go to its own account at Bank B. When the bank returned its confirmation, SilerBanker changed the details before displaying them on the screen, in order to delay the time that the customer would find out the attack.