HTTP MitM attack

This section combines the techniques from the ARP & DNS spoofing, and demonstrates how an attacker would be able to leverage the MitM position to intercept and modify HTTP data/traffic.

In an effort to understand the dangers of a public network, and the risks of ARP spoofing attacks, I have came up with a simple simulation example.

https://gohxiangzheng.com/projects/http-mitm-attack/gohxiangzheng.com

Overview of attack

Attacker

1. Run a HTTP proxy server to intercept and sniff or modify data

2. Run a rogue DNS server on the attacker machine, to resolve queries for a few selected or all the host names, to the IP address of the attacker. Special hosts file rules can be added for fake subdomains that does not exist

3. Run ARP spoof attack on the victim machine, sending ARP replies to the victim and router gateway:

   • ARP reply to the gateway: <victim_ip>is-at<attacker_mac_addr>

   • ARP reply to the victim machine: <gateway_ip>is-at<attacker_mac_addr>

4. Sends a phishing email to the victim, claiming to be from a trusted website. The email contains a seemingly legitimate HTTP link of a fake subdomain of the trusted root domain

Victim

1. Receive an email claiming to be from a trusted website

2. Clicks on the link provided in the email

3. Provides login credentials to "authenticate" with the website

4. Performs a certain action

Attacker

At this point, the user have gained control of the user's connection to the seemingly trusted website, and have stolen the login credentials

The attacker can exploit the user's trust in the website, and trick the user in performing actions

Parameters

Victim

• Windows

• 10.0.2.4

Attacker

• Kali Linux

• 10.0.2.5

Gateway

• 10.0.2.1

Attacking commands

Terminal 1

• Enable IPv4 forwarding

$ sudo sysctl -w net.ipv4_ip_forward=1

• Create a firewall rule to redirect traffic to TCP port 80 (HTTP) to port 8080

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

• Compile and run the HTTP proxy

$ gcc mitm_proxy_http-hijacK.c -o http-proxy && sudo ./http-proxy

c-sockets/mitm_proxy_http_hijack.c at main · Jarrettgohxz/c-socketsGitHub

Terminal 2

• Drop all DNS query destined for the actual gateway

$ sudo iptables -A FORWARD -d 10.0.2.1 -p udp --dport 53 -j DROP

• Load DNS hosts file

$ cat hosts.spoof
10.0.2.5 *

• Run DNS server

$ sudo dnsspoof -i eth0 -f hosts.spoof

Terminal 3

• Run the ARP spoof attack

$ sudo arpspoof -i eth0 -t 10.0.2.4 10.0.2.1 -r

Craft and send a malicious phishing email

...

msftconnecttest.com

On a Windows machine, the address http://www.msftconnecttest.com/redirect is observed to be automatically opened on the default browser it is disconnected from a VPN, and subsequently reconnected. I have noticed that the website used in the Windows NCSI configurations are in HTTP, rather than HTTPS.

In an effort to understand why this happens, and how I can trigger this behavior, I have done some research. I hope to replicate this as an attacker while being on the same network as a target user, to trick their browser to open this address — which can be intercepted and modified.

Factors that trigger the browser to open the msfconnecttest.com/redirect address (theory)

1. Proxy server connection is detected

   • Based on the TUN/TAP interface?

   • How to trick the user device to believe it is connected to a proxy server?

2. NCSI probes failure

   • how to make it fail?

Refer to " Why default browser automatically opens" link below:

"In some cases, such as when you connect to a network that uses a proxy server to connect to the internet or when network restrictions prevent NCSI from completing its active probe process, Windows opens the MSN Portal page in the default browser."

Practical experimentation based on point 2 (force the NCSI probes to fail)

Assume the following:

1. Both the user and attacker machine are in a virtualbox NAT network

2. The default gateway and fake DNS address for the target user would be the attacker machine at a particular address

Attacker machine: Run usual ARP & DNS spoof techniques

• IP forwarding, drop DNS packets, etc.

• Resolve www.msftconnecttest.com to any address

Windows user machine: Simulate change in network settings

• Trigger disconnect of network interface on Windows machine

$ ipconfig /flushdns

PS C:\Windows\System32> netsh interface set interface <iface_name> disable
PS C:\Windows\System32> netsh interface set interface <iface_name> enable

To flush the DNS cache, followed by disabling interface (disconnect from network), and wait a few seconds before connecting back again. The goal of these steps is to trick the use's Windows machine to trigger the process explained in the observation description above.

Connect to VPN (expected to fail) for a few seconds, before disconnecting again

This will trigger the NCSI probes process:

1. DNS query for www.msftconnecttest.com

2. If step 1 succeeds, HTTP request to http://www.msftconnecttest.com/connecttest.txt

3. If step 2 fails to connect or doesn't return a valid content of "Microsoft Connect Test", the default browser with address http://www.msftconnecttest.com/redirect would be automatically opened

Attacker machine: Run a HTTP proxy to intercept traffic

Upon receiving HTTP request for http://www.msftconnecttest.com/connecttest.txt, either ignore the request, or reply with an invalid content (anything besides "Microsoft Connect Test") as mentioned above.

Subsequently, the default browser would be opened with HTTP GET request to http://www.msftconnecttest.com/redirect , where the content would be controlled by the attacker machine's HTTP proxy

NOTE:

• ARP spoof: To redirect DNS & HTTP traffic during the NCSI probe process to the attacker machine

• DNS spoof: To resolve www.msftconnecttest.com

• HTTP proxy: To process requests for http://www.msftconnecttest.com/connecttest.txt and http://www.msftconnecttest.com/redirect

Experiment results

The attack does not work., which leads me to wonder how does the presence of a proxy server such as a VPN trigger the mentioned behavior?

The following is my theory on why the attack does not work:

The NCSI probes are sent immediately after the device reconnects, this means that the ARP poisoned entry is not in use yet, and the initial DNS query for www.msftconnecttest.com would be resolved by the actual gateway instead, followed by the HTTP request. This would allow the NCSI probe process to succeed. Hence, the http://www.msftconnecttest.com/redirect address would not be triggered on the default browser.

Further experimentation: authentication and automatic sign-in page

How to make the device believe that the network requires authentication, to trigger the sign-in page to be opened on the browser?

pending research...

Network Connectivity Status Indicator FAQ for WindowsMicrosoftLearn

An Internet Explorer or Edge window opens when your computer connects to a corporate network or a public network - Windows ClientMicrosoftLearn

Why default browser automatically opens

How to Fix Msftconnecttest Redirect Error in 5 Steps - Updated %%currentyear%%Comparitech