MAN IN THE MIDDLE (MITM) ATTACK

Man-in-the-Middle : Learn About Man-in-the-Middle Attacks, Vulnerabilities and How to Prevent MITM Attacks

What is MITM attack

A man in the middle (MITM) attack is a general term for when a perpetrator positions himself in a conversation between a user and an application — either to eavesdrop or to impersonate one of the parties, making it appear as if a normal exchange of information is underway.

The goal of an attack is to steal personal information, such as login credentials, account details and credit card numbers. Targets are typically the users of financial applications, SaaS businesses, e-commerce sites and other websites where logging in is required.

Information obtained during an attack could be used for many purposes, including identity theft, unapproved fund transfers or an illicit password change.

Additionally, it can be used to gain a foothold inside a secured perimeter during the infiltration stage of an advanced persistent threat (APT) assault.

Broadly speaking, a MITM attack is the equivalent of a mailman opening your bank statement, writing down your account details and then resealing the envelope and delivering it to your door.

Key Concepts of a Man-in-the-Middle Attack

• Man-in-the-middle is a type of eavesdropping attack that occurs when a malicious actor inserts himself as a relay/proxy into a communication session between people or systems.
• A MITM attack exploits the real-time processing of transactions, conversations or transfer of other data.
• Man-in-the-middle attacks allow attackers to intercept, send and receive data never meant to be for them without either outside party knowing until it is too late.

Man-in-the-Middle Attack Examples

In the image above, you will notice that the attacker inserted him/herself in-between the flow of traffic between client and server. Now that the attacker has intruded into the communication between the two endpoints, he/she can inject false information and intercept the data transferred between them.

Below is another example of what might happen once the man in the middle has inserted him/herself.

The hacker is impersonating both sides of the conversation to gain access to funds. This example holds true for a conversation with a client and server as well as person-to-person conversations. In the example above, the attacker intercepts a public key and with that can transpose his own credentials to trick the people on either end into believing they are talking to one another securely.

Interactions Susceptible to MITM Attacks

• Financial sites — between login and authentication
• Connections meant to be secured by public or private keys
• Other sites that require logins — where there is something to be gained by having access

Other Forms of Session Hijacking

Man-in-the-middle is a form of session hijacking. Other forms of session hijacking similar to man-in-the-middle are:

• Sidejacking — This attack involves sniffing data packets to steal session cookies and hijack a user’s session. These cookies can contain unencrypted login information, even if the site was secure.
• Evil Twin — This is a rogue Wi-Fi network that appears to be a legitimate network. When users unknowingly join the rogue network, the attacker can launch a man-in-the-middle attack, intercepting all data between you and the network.
• Sniffing — This involves a malicious actor using readily available software to intercept data being sent from, or to, your device.

MITM attack progression

Successful MITM execution has two distinct phases: interception and decryption.

Interception

The first step intercepts user traffic through the attacker’s network before it reaches its intended destination.

The most common (and simplest) way of doing this is a passive attack in which an attacker makes free, malicious WiFi hotspots available to the public. Typically named in a way that corresponds to their location, they aren’t password protected. Once a victim connects to such a hotspot, the attacker gains full visibility to any online data exchange.

Attackers wishing to take a more active approach to interception may launch one of the following attacks:

• IP spoofing involves an attacker disguising himself as an application by altering packet headers in an IP address. As a result, users attempting to access a URL connected to the application are sent to the attacker’s website.
• ARP spoofing is the process of linking an attacker’s MAC address with the IP address of a legitimate user on a local area network using fake ARP messages. As a result, data sent by the user to the host IP address is instead transmitted to the attacker.
• DNS spoofing, also known as DNS cache poisoning, involves infiltrating a DNS server and altering a website’s address record. As a result, users attempting to access the site are sent by the altered DNS record to the attacker’s site.

Decryption

After interception, any two-way SSL traffic needs to be decrypted without alerting the user or application. A number of methods exist to achieve this:

• HTTPS spoofing sends a phony certificate to the victim’s browser once the initial connection request to a secure site is made. It holds a digital thumbprint associated with the compromised application, which the browser verifies according to an existing list of trusted sites. The attacker is then able to access any data entered by the victim before it’s passed to the application.
• SSL BEAST (browser exploit against SSL/TLS) targets a TLS version 1.0 vulnerability in SSL. Here, the victim’s computer is infected with malicious JavaScript that intercepts encrypted cookies sent by a web application. Then the app’s cipher block chaining (CBC) is compromised so as to decrypt its cookies and authentication tokens.
• SSL hijacking occurs when an attacker passes forged authentication keys to both the user and application during a TCP handshake. This sets up what appears to be a secure connection when, in fact, the man in the middle controls the entire session.
• SSL stripping downgrades a HTTPS connection to HTTP by intercepting the TLS authentication sent from the application to the user. The attacker sends an unencrypted version of the application’s site to the user while maintaining the secured session with the application. Meanwhile, the user’s entire session is visible to the attacker.

Man in the middle attack prevention

Blocking MITM attacks requires several practical steps on the part of users, as well as a combination of encryption and verification methods for applications.

For users, this means:

• Avoiding WiFi connections that aren’t password protected.
• Paying attention to browser notifications reporting a website as being unsecured.
• Immediately logging out of a secure application when it’s not in use.
• Not using public networks (e.g., coffee shops, hotels) when conducting sensitive transactions.

For website operators, secure communication protocols, including TLS and HTTPS, help mitigate spoofing attacks by robustly encrypting and authenticating transmitted data. Doing so prevents the interception of site traffic and blocks the decryption of sensitive data, such as authentication tokens.

It is considered best practice for applications to use SSL/TLS to secure every page of their site and not just the pages that require users to log in. Doing so helps decreases the chance of an attacker stealing session cookies from a user browsing on an unsecured section of a website while logged in.

Types of Man-in-the-Middle Attacks

Email Hijacking — attackers gain access to a user’s email account and watch transactions to and from the account. When the time is right, for instance the user is exchanging funds with another party, the attacker takes advantage of the situation by attempting to intercept the funds by spoofing one or all members of the conversation.

Wi-Fi Eavesdropping — a passive way to deploy MITM attacks, Wi-Fi eavesdropping involves cyber hackers setting up public Wi-Fi connections, typically with an unsuspecting name, and gain access to their victims as soon as they connect to the malicious Wi-Fi.

Session Hijacking — session hijacking is when an attacker gains access to an online session via a stolen session key or stolen browser cookies.

DNS Spoofing — an attacker engages in DNS spoofing by altering a website’s address record within a DNS (domain name server) server. A victim unknowingly visits the fake site and the attacker will attempt to steal their information.

IP Spoofing — similar to DNS spoofing, IP Spoofing sees an attacker attempt to divert traffic to a fraudulent website with malicious intent. Instead of spoofing the website’s address record, the attacker disguises an IP (internet protocol) address.

Example for Man in the middle attack

Suppose Alice wishes to communicate with Bob. Meanwhile, Jeevan wishes to intercept the conversation to eavesdrop and optionally to deliver a false message to Bob.

First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, an MITM attack can begin. Mallory sends Alice a forged message that appears to originate from Bob, but instead includes Mallory’s public key.

Alice, believing this public key to be Bob’s, encrypts her message with Mallory’s key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key she intercepted from Bob when he originally tried to send it to Alice. When Bob receives the newly enciphered message, he believes it came from Alice.

1. Alice sends a message to Bob, which is intercepted by Mallory:Alice “Hi Bob, it’s Alice. Give me your key.” → Mallory Bob
2. Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:Alice Mallory “Hi Bob, it’s Alice. Give me your key.” → Bob
3. Bob responds with his encryption key:Alice Mallory ← [Bob’s key] Bob
4. Mallory replaces Bob’s key with her own, and relays this to Alice, claiming that it is Bob’s key:Alice ← [Mallory’s key] Mallory Bob
5. Alice encrypts a message with what she believes to be Bob’s key, thinking that only Bob can read it:Alice “Meet me at the bus stop!” [encrypted with Mallory’s key] → Mallory Bob
6. However, because it was actually encrypted with Mallory’s key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob’s key, and forward it to Bob:Alice Mallory “Meet me at the van down by the river!” [encrypted with Bob’s key] → Bob
7. Bob thinks that this message is a secure communication from Alice.

This example shows the need for Alice and Bob to have some way to ensure that they are truly each using each other’s public keys, rather than the public key of an attacker. Otherwise, such attacks are generally possible, in principle, against any message sent using public-key technology. A variety of techniques can help defend against MITM attacks.

Defense and detection

MITM attacks can be prevented or detected by two means: authentication and tamper detection. Authentication provides some degree of certainty that a given message has come from a legitimate source. Tamper detection merely shows evidence that a message may have been altered.

Authentication

All cryptographic systems that are secure against MITM attacks provide some method of authentication for messages. Most require an exchange of information (such as public keys) in addition to the message over a secure channel. Such protocols, often using key-agreement protocols, have been developed with different security requirements for the secure channel, though some have attempted to remove the requirement for any secure channel at all.

A public key infrastructure, such as Transport Layer Security, may harden Transmission Control Protocol against MITM attacks. In such structures, clients and servers exchange certificates which are issued and verified by a trusted third party called a certificate authority (CA). If the original key to authenticate this CA has not been itself the subject of a MITM attack, then the certificates issued by the CA may be used to authenticate the messages sent by the owner of that certificate. Use of mutual authentication, in which both the server and the client validate the other’s communication, covers both ends of a MITM attack, though the default behavior of most connections is to only authenticate the server.

Attestments, such as verbal communications of a shared value (as in ZRTP), or recorded attestments such as audio/visual recordings of a public key hash are used to ward off MITM attacks, as visual media is much more difficult and time-consuming to imitate than simple data packet communication. However, these methods require a human in the loop in order to successfully initiate the transaction.

In a corporate environment, successful authentication (as indicated by the browser’s green padlock) does not always imply secure connection with the remote server. Corporate security policies might contemplate the addition of custom certificates in workstations’ web browsers in order to be able to inspect encrypted traffic. As a consequence, a green padlock does not indicate that the client has successfully authenticated with the remote server but just with the corporate server/proxy used for SSL/TLS inspection.

HTTP Public Key Pinning (HPKP), sometimes called “certificate pinning,” helps prevent a MITM attack in which the certificate authority itself is compromised, by having the server provide a list of “pinned” public key hashes during the first transaction. Subsequent transactions then require one or more of the keys in the list must be used by the server in order to authenticate that transaction.

DNSSEC extends the DNS protocol to use signatures to authenticate DNS records, preventing simple MITM attacks from directing a client to a malicious IP address.

Tamper detection

Latency examination can potentially detect the attack in certain situations,such as with long calculations that lead into tens of seconds like hash functions. To detect potential attacks, parties check for discrepancies in response times. For example: Say that two parties normally take a certain amount of time to perform a particular transaction. If one transaction, however, were to take an abnormal length of time to reach the other party, this could be indicative of a third party’s interference inserting additional latency in the transaction.

Quantum Cryptography, in theory, provides tamper-evidence for transactions through the no-cloning theorem. Protocols based on quantum cryptography typically authenticate part or all of their classical communication with an unconditionally secure authentication scheme e.g. Wegman-Carter authentication.

Forensic analysis
Captured network traffic from what is suspected to be an attack can be analyzed in order to determine whether or not there was an attack and determine the source of the attack, if any. Important evidence to analyze when performing network forensics on a suspected attack includes:

IP address of the server
DNS name of the server
X.509 certificate of the server
Is the certificate self signed?
Is the certificate signed by a trusted CA?
Has the certificate been revoked?
Has the certificate been changed recently?
Do other clients, elsewhere on the Internet, also get the same certificate?

Notable instances

A notable non-cryptographic MITM attack was perpetrated by a Belkin wireless network router in 2003. Periodically, it would take over an HTTP connection being routed through it: this would fail to pass the traffic on to destination, but instead itself responded as the intended server. The reply it sent, in place of the web page the user had requested, was an advertisement for another Belkin product. After an outcry from technically literate users, this ‘feature’ was removed from later versions of the router’s firmware.

In 2011, a security breach of the Dutch certificate authority DigiNotar resulted in the fraudulent issuing of certificates. Subsequently, the fraudulent certificates were used to perform MITM attacks.

In 2013, the Nokia’s Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia’s proxy servers, giving the company clear text access to its customers’ encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information.

In 2017, Equifax withdrew its mobile phone apps following concern about MITM vulnerabilities.

Other notable real-life implementations include the following:

DSniff — the first public implementation of MITM attacks against SSL and SSH
Fiddler2 HTTP(S) diagnostic tool
NSA impersonation of Google
Qaznet Trust Certificate
Superfish malware
Forcepoint Content Gateway — used to perform inspection of SSL traffic at the proxy
Comcast uses MITM attacks to inject JavaScript code to 3rd party web pages, showing their own ads and messages on top of the pages