DNS Attacks - Man in the Middle

TLDR: Man-in-the-Middle (MitM) Attacks allow attackers to intercept and alter DNS queries and responses, redirecting users to malicious websites. This example demonstrates how an attacker can exploit this vulnerability to create a convincing fake site, steal sensitive information, and compromise user security.

In Layerman"s terms
Protagonists
Bob: A visitor to a small shop.
Alice: The shop owner.
Jack: A prankster.

Jack decides to intercept the directions that people get when they try to visit Alice's shop. When Bob asks for directions to Alice's shop, Jack steps in and pretends to be a helpful local. He gives Bob false directions that lead him to a fake shop set up by Jack. Bob, thinking he's at Alice's shop, interacts with Jack's fake shop. Jack intercepts and manipulates Bob's requests, potentially stealing his payment details or giving him fake products. Meanwhile, Alice is unaware that Bob has been misled and that her business is being compromised.

Scenario: Intercepting DNS Queries to Redirect Users to a Malicious Website

Step 1: Setting Up the Interception

Setup:

The attacker positions themselves between the user and the DNS resolver. This can be done in various ways, such as compromising a router, using a rogue access point, or exploiting a vulnerability in the network. Purpose: To gain the ability to intercept and potentially alter DNS queries and responses.

Step 2: Monitoring DNS Traffic

Interception:

The attacker uses a network sniffing tool (like Wireshark) to monitor DNS traffic between the user's device and the DNS resolver. They capture DNS queries made by the user, such as a request to resolve the IP address of www.bank.com. Purpose: To identify and capture the DNS queries that the user is sending to the resolver.

Step 3: Injecting Malicious DNS Responses

Injection:

Upon intercepting a DNS query from the user (e.g., for www.bank.com), the attacker quickly sends a forged DNS response before the legitimate response from the resolver can reach the user. The forged response contains a malicious IP address (e.g., 192.168.1.100) instead of the legitimate IP address of www.bank.com. Purpose: To ensure that the user's device caches the malicious IP address and connects to the attacker-controlled server.

Step 4: User Interaction

Redirection:

The user's device receives the malicious DNS response and caches the IP address for www.bank.com as 192.168.1.100. The user tries to visit www.bank.com by typing the URL into their browser.

Outcome:

The user's browser is redirected to the attacker's server at 192.168.1.100. Purpose: This step redirects the user to the malicious website controlled by the attacker.

Step 5: Malicious Server Interaction

Fake Website:

The attacker's server hosts a fake website designed to mimic the legitimate www.bank.com site. The attacker may use SSL/TLS certificates to create a secure-looking https://www.bank.com site.

Data Capture:

The user, believing they are on the legitimate site, enters sensitive information such as login credentials, personal details, or financial information. The malicious site captures this information and sends it to the attacker's database.

Actions:

  • The attacker uses the stolen credentials to access the user's real bank account.
  • The attacker can also perform identity theft, financial fraud, or sell the stolen data on underground markets.

Security Implications:

  • This attack exploits the user's trust in the DNS system and HTTPS indicators.
  • Highlights the necessity for secure communication channels, like DNS over HTTPS (DoH) or DNS over TLS (DoT), which can help prevent such attacks.
  • Emphasizes the importance of user education on verifying URLs and being cautious even with HTTPS sites.