Understanding Man-in-the-Middle (MitM) Attacks and How to Defend Against Them

Understanding the Man-in-the-Middle Attack

The Man-in-the-Middle (MitM) attack is a fundamental network session hijacking technique. This attack can block, alter, or intercept network traffic. For example, an attacker using MitM might discreetly capture a user's login details, steal credit card information, or launch a denial-of-service attack. In this attack, the attacker positions themselves between the victim and the desired server. Achieving this can involve tactics like ARP spoofing or DNS poisoning. If traffic is encrypted, the attacker may devise ways to decrypt it. They might either listen to the communication passively or modify messages actively before passing them on. If messages were decrypted, they're re-encrypted (possibly after alteration) and then forwarded. MitM attacks can lead to data breaches, financial scams, and eroding user confidence.

How a MitM Attack Works:

A successful MitM attack unfolds in two stages. The initial stage is about intercepting traffic. In the subsequent stage, the attacker might just eavesdrop, or they could decrypt, modify, re-encrypt, and transfer messages between the communicating parties, all unbeknownst to them. Several interception techniques include:

Public Wi-Fi Sniffing: Here, the attacker creates a deceptive Wi-Fi hotspot in public area. Unsuspecting users connect, allowing the attacker to access all their traffic.
ARP Spoofing: Through fake ARP messages, an attacker can link their MAC address with another host's IP, diverting traffic intended for that IP to themselves.
SSL Stripping: In this approach, attackers force victims to shift from a secure HTTPS connection to insecure HTTP, simplifying traffic interception and reading.
IP Spoofing: Here, by tweaking packet headers in an IP address, an attacker masquerades as a genuine application. Thus, when users try accessing a linked URL, they're directed to the attacker's site.
DNS Spoofing (or Cache Poisoning): This involves compromising a DNS server and modifying a website’s address record. Consequently, users trying to visit the website are misled by the tampered DNS record to the attacker's site.

Decrypting the Two-Way SSL Traffic:

Once two-way SSL traffic is intercepted, the challenge is decrypting it without raising suspicion from either the user or the application. Several techniques can accomplish this:

SSL Stripping: This technique intercepts the secure authentication (TLS) sent from the application towards the user, converting a HTTPS connection to a less secure HTTP one. The user receives an unencrypted version of the application's website, whereas the attacker keeps the encrypted connection with the actual application. This exposes the user's entire session to the attacker.

SSL Hijacking: In this method, during a TCP handshake, the attacker provides counterfeit authentication keys to both the user and the application. This creates an illusion of a secure connection, while in reality, the attacker oversees the whole session.
HTTPS Spoofing: When a user initially tries to connect to a secure site, this method sends a fake certificate to the user's browser. This certificate contains a digital signature linked to the targeted application. The browser cross-references this with its list of trusted sites. If deemed trustworthy, the attacker gains access to information the user inputs before it reaches the actual application.
HSTS Hijack: The HSTS hijack targets sites already on a browser's HSTS preload list. Therefore, the browser rejects any HTTP connection attempts. Thus, the cunning nature of this attack lies in its indirect approach, aiming to cleverly sidestep HSTS. However, it requires user interaction to be successful. Imagine a user tries connecting to site A which supports HSTS header but it's not on the HSTS preload list. An attacker, using the MitM strategy and SSL stripping, can manipulate the data flow between the user and the site A. The attacker's ultimate goal is to capture user's login credentials for site B. Let's say site A links to site B. User clicks on a link to site B from site A. However, since the attacker has a succesful MITM between the user and the site A they could easily modify the link to site B to point to a malicious login capturing page.

Defending Against MitM in HTTP Sessions:

There are two primary safeguards against MitM attacks during HTTP sessions.

HTTP Strict Transport Security (HSTS):

Websites can adopt HTTP Strict Transport Security (HSTS). HSTS, essentially an HTTP header, signals browsers to insist on HTTPS for that domain. An HSTS header might look like: Strict-Transport-Security: max-age=63072000; includeSubDomains; This sets HSTS for two years and extends it to subdomains. If a user then tries accessing the site or its subdomains via plain HTTP, the browser recalls and upgrades the connection to HTTPS based on its cache. But there's a catch: if someone accesses the website for the first time—perhaps after installing a new browser or clearing its state—an attacker might strip away the HSTS directive.

HSTS Preload List:

A solution to the above risk is the HSTS preload list. Adding a site here ensures secure connections even post a new browser setup or after erasing its local cache. Essentially, this list consists of domains or top-level domains that inherently support HSTS. This gives browsers advance notice about the site's HTTPS requirement. In essence, these websites are hardcoded into browsers as HTTPS-exclusive. Managed by Google, all major web browsers endorse this list.

For inclusion, a domain's HSTS header must have the 'preload' directive, like: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; When a browser accesses an HSTS-supported website, it updates its local database with that domain.