Redirecting HTTP LAN Traffic to a Malicious Site


After breaching the perimeter, there are many techniques to choose from to expand influence within a LAN. In many cases, using Responder or other methods will yield satisfactory results very quickly. In other cases, you might have to get creative due to defensive mitigations or due to a small attack surface. One possible attack to chose, would be a PiTM (person-in-the-middle) attack which impersonates the gateway and sends unencrypted HTTP traffic to a malicious website. If an attacker has control of a Linux host on the LAN, this attack can be performed with arpspoof. The attack disrupts a victim's unencrypted HTTP traffic and would ideally only be run in a targeted manner.

PoC video showing the PiTM attack


Though this attack is fairly simple, and is described in many blogs across the web, most of those posts are very old. My purpose in revisiting this is to offer updated documentation that includes important prerequisites and offers tips for exploitation in a test environment. As an example, many posts do not indicate the -r switch with arpspoof, which is important for spoofing in both directions. Many sites also have not been updated to reflect that typed navigations in Chrome default to an https:// scheme instead of http://, while  this is not the case for Firefox and Edge, at the time of this post. In addition, it took me a while to figure out that it's much easier to do this attack with VirtualBox than it is with VMWare because of the way the latter handles layer 2. Hopefully, my experimentation and documentation saves others time.

Please keep in mind that this attack will ultimately result in a DoS on all traffic destined for port 80, including traffic not generated by the browser, like updates, etc.

Below are the details on the test environment LAN I'll use to demonstrate:

  • Router
    • 10.0.0.1
  • Ubuntu host machine running VirtualBox (this attack is much more complicated in VMWare)
  • Kali Linux 2022.1 VM
    • 10.0.0.83
    • dsniff 2.4 (includes arpspoof)
  • Windows 10 VM
    • 10.0.0.161
    • IPv6 disabled
    • DNS cache cleared
    • Microsoft Edge version 101.0.1210.53 64-bit (history cleared)
    • Firefox 101.0 64-bit
To begin, we must configure VirtualBox appropriately. Both the Kali and Windows machines must use a bridged adapter. Since the Kali box will need promiscuous mode, we'll need to also allow that in VirtualBox. Under Settings>Network>Advanced>Promiscuous Mode, choose Allow All:


Now it's time to configure the Kali box to prepare the attack. Let's start with installing the dsniff suite of tools that includes arpspoof:

sudo apt install dsniff

We also need to enable IPv4 forwarding so we can forward packets from the victim computer to the real router, otherwise the victim's internet connection will be completely down:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

As a side note, the following command does the same thing as the previous command, so either is fine:

sudo sysctl -w net.ipv4.ip_forward=1

There are a variety of things that can be done with the intercepted traffic, but for this attack, we will forward all traffic destined for port 80 to 8080, where a malicious web server will be listening. Forwarding encrypted TLS traffic is more problematic due to HSTS, etc. and has more prerequisites, so we'll stick with unencrypted HTTP for this test. Here's the command we'll use to send HTTP to our malicious web server: 

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

Now we just need a malicious web server. We can of course use Python3's http.server module for that. When using this module, if there is no index.html file present a directory listing is displayed. So we'll need a malicious index.html. Depending on your needs, this could be a full blown phishing website, etc. For the purpose of this test, I'm going to simply serve up a redirect to my blog. This can be done by creating an index.html file with the following contents:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="refresh" content="0; url='https://jamesonhacking.blogspot.com/'" />
  </head>
  <body>
  </body>
</html> 

Now we just need to start the web server:

python3 -m http.server 8080

In a real world scenario, we would perform recon and choose a suitable victim. In this case, our victim will be 10.0.0.161. We will run arpspoof to poison the victim's ARP cache:

sudo arpspoof -i eth0 -r -t <victim-ip> <router-ip>

The -r means that both the victim and the router will be poisoned. Without this, the router wouldn't properly route responses back through our attack machine. The -t specifies the target victim. The appropriate command in my lab environment then is:

sudo arpspoof -i eth0 -r -t 10.0.0.161 10.0.0.1

Once this command is run, our attack box will send out ARP packets claiming that the router's IP address can be found using our MAC address, instead of the legitimate MAC address of the router. This should immediately poison our victim's ARP cache. For funsies, you can view the ARP cache on the victim before and after the attack, using this Windows command:

arp -a

If everything is setup correctly, your victim should now be sending all internet requests through the Kali box. Nothing will be disrupted except traffic on port 80. We'll test this in a browser in a moment, but first let's talk about prerequisites:

  1. This particular methodology with this particular toolset is only designed for IPv4 traffic. For this test environment, I recommend disabling IPv6 in Windows and clearing the DNS cache in case any IPv6 addresses are cached.
  2. Chrome now defaults to https:// for typed navigations, unless the user manually enters http://. At the time of this post, Firefox and Edge do not.
  3. If performing this test with Firefox, do not use Private Browsing mode, because in this case Firefox does rewrite http:// as https://.
  4. HSTS can be a showstopper. If the target URL the victim types into the browser is on Firefox's HSTS preload list or in Edge's similar list, the browser will modify the scheme from http:// to https://. In the case of a target website which has previously responded to the browser with a Strict-Transport-Security header, it will *also* do this. For our test environment, it is advisable to clear the Firefox or Edge browser history before testing, so as to remove any site added to the HSTS list via responses containing the Strict-Transport-Security header. In the case of Firefox, it's also advisable to perform a refresh.
  5. Even if HSTS isn't a factor, the browser may autocomplete the URL with https:// based on the browser history. Again, for this test exercise, be sure to clear browser history.
  6. In some environments, there may be protections in place like DHCP snooping, port security, etc., which prevent ARP spoofing.
Now it's time to perform the test from the victim side. After clearing the Edge history, I type in the following URL (no http:// scheme is necessary) in Edge and press enter:

icanhazip.com

The browser is then forwarded to index.html on the Kali box, which in my case successfully redirects to https://jamesonhacking.blogspot.com/.

Here's a recap of the attack:
  1. We use the Kali box to poison the ARP cache on the Windows host so that the MAC address of Kali is associated with the IP address of the router
  2. The victim types in icanhazip.com and this generates a DNS request which is forwarded up the chain by the Kali box to a legitimate DNS server.
  3. The victim then sends a request to the IP address of icanhazip.com on port 80 and the request is intercepted by our Python3 web server listening on 8080. Because the request doesn't use TLS (with an https:// scheme), the victim doesn't perform any validation to confirm that the website is who it says it is.
  4. At this point, any malicious content within index.html can be sent back to the victim. It could be a phishing site asking for credentials or offering a malicious download, etc. In our case, index.html contains a redirect.



Links of interest:

Comments

Post a Comment

Popular Posts