Understanding HSTS bypassing with DNS spoofing

HSTS is an industry response to the sslstrip HTTP downgrading attack. It's a header that tells the browser, you can only communicate with this site over HTTPS. The browser receives the header and stores the name of the site as an HSTS site. Suppose you access https://mail.google.com at home, on a secure network; then, you take your laptop to the airport where a mischievous miscreant has planted an evil twin access point, drowning out the signal of legit access points with an amplifier to capture hapless travelers on their laptops, and they're running an sslstrip man-in-the-middle on everything. Have no fear, intrepid traveler, as your browser remembers from the HSTS header received from mail.google.com that the HTTP is a no-go. The hacker in you is now pointing out, but what if we're HTTP-downgrading the victim during his or her initial communication with the server? We can filter out the HSTS header so the browser never learns it. Yes, very true! However, the cat-and-mouse game continues as the browser industry thought of that one, too: modern browsers employ HSTS preloading, where big-name sites are already programmed into the browser; even a clean install of Chrome will refuse to talk to an HTTP session pointing at a domain in the list.

The key here is how a site is identified – by its name. Suppose my browser already has an HSTS header for www.example.com – it does not have an entry for wwww.example.com.  Technically, that's a different name and the browser would need to query DNS for it. We now have the setup for an ingenious misdirection attack. Let's step through how it works with BetterCAP, including key moments captured in Wireshark:

1. Attack the network at the link layer with ARP spoofing to trick the victim (using a network card with an Intel OUI in its MAC address) into sending data destined for the gateway to our Kali box (using a network card with an Alfa OUI in its MAC address). 
2. The victim wants to visit their bank and requests www.53.com with their browser.

3. The victim's browser sends a DNS request for www.53.com to the gateway, but due to the poisoned ARP table, sends it to Kali's interface where BetterCAP's DNS listener is waiting.
4. The Kali box receives the request and BetterCAP creates its own backline DNS request to 8.8.8.8 to get the actual answer; once the legitimate answer is received, BetterCAP (spoofing the gateway) sends back the answer in a DNS reply packet.  
5. The victim's browser now tries to create a session with www.53.com, which is hijacked by BetterCAP.
6. BetterCAP spoofs an HTTP 301 message (Moved Permanently) from www.53.com, redirecting to the domain wwwww.53.com in plain HTTP:  
   
7. The victim browser now creates a new DNS request for the spoofed name, wwwww.53.com, which is received by the DNS listener once again. BetterCAP replies as the gateway with the same IP address retrieved in the legitimate backline request in step 4:
   
8. The victim browser initiates a plain HTTP connection to wwwww.53.com, which BetterCAP transparently manages while fetching all the actual data from the HTTPS-protected www.53.com.

Wow, BetterCAP really is better.

Let's conduct this attack now. I'm sure you're cracking your knuckles and preparing for some intense typing – prepare to conduct this entire attack with a single command while you kick back and sip a coffee.