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.
Last updated
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.
Last updated
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.
Attacker
Run a HTTP proxy server to intercept and sniff or modify data
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
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>
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
Receive an email claiming to be from a trusted website
Clicks on the link provided in the email
Provides login credentials to "authenticate" with the website
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
Victim
Windows
10.0.2.4
Attacker
Kali Linux
10.0.2.5
Gateway
10.0.2.1
Terminal 1
Enable IPv4 forwarding
Create a firewall rule to redirect traffic to TCP port 80 (HTTP) to port 8080
Compile and run the HTTP proxy
Terminal 2
Drop all DNS query destined for the actual gateway
Load DNS hosts file
Run DNS server
Terminal 3
Run the ARP spoof attack
Craft and send a malicious phishing email
...
The address http://www.msftconnecttest.com/redirect is automatically opened on the default browser based on a few factors:
...
Notice that the website used in the Windows NCSI configurations are in HTTP, rather than HTTPS. If these factors could be replicated by an attacker on the same network as a user, it could trick the browser to open this address, which can be intercepted and modified.
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?
NCSI probs 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."
Both the user and attacker machine are in a virtualbox NAT network
Default gateway would be the host machine at a particular address
DNS server address is inherited from the host machine
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
To flush the DNS cache, followed by disabling interface (disconnect from network), and wait a few seconds before connecting back again
This will trigger the NCSI probes process:
DNS query for www.msftconnecttest.com
If step 1 succeeds, HTTP request to http://www.msftconnecttest.com/connecttest.txt
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 send content when request is sent to http://www.msftconnecttest.com/redirect
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, which would resolve correctly and allow the NCSI probe process to succeed. Hence, the http://www.msftconnecttest.com/redirect address would not triggered on the default browser.
Solution: Drop DNS packets returning from the gateway that is intended for the device
This would prevent the initial real DNS response from returning to the device. Subsequently, the DNS queries would be sent to the attacker device instead, due to the ARP spoof.
However, this seems to not be enough for the default browser to be automatically opened.
How to make the device believe that the network requires authentication, to trigger the sign-in page to be opened on the browser?
