January 4, 2018

Modern Man-in-the-Middle Attacks

Contents:

  1. Introduction
  2. Bypassing Basic HTTPS
  3. Bypassing 301 Caching
  4. Bypass non-preloaded HSTS through NTP
  5. Bypassing Preloaded HSTS through logic errors
  6. Cookie Domains
  7. Exploiting with MiTM on DNS
  8. Exploiting without MiTM on DNS

Introduction

The old ways are dead.
Gone are the days where one could sit on a network, watch the plaintext traffic, and hijack sessions all day long.
Admins have been shamed publicly on twitter for not implementing HTTPS and now…
HTTPS prevents you from viewing the data you wish to obtain.

Welcome to MiTM in the age of HSTS.

This post will not focus on vulnerabilities that are likely patched  on any servers you want to target (BEAST, FREAK, etc) or problems that  exist with old or relatively unused browsers (mixed content injection)  but instead focus on exploiting common vulnerabilities that appear in  most websites using HTTPS.
The goal for these techniques will be session hijacking on a website of your choosing.

Bypassing basic HTTPS

When a user visits a new domain without specifying which protocol to  use (http://, https://), the browser will first connect to port 80. If  the site creator wishes to use HTTPS, they will usually return a 301  Moved Permanently status code in order to redirect http://domain.com to  https://domain.com.
An attacker can manipulate this first insecure request’s response to  point elsewhere, such as a malicious middleman to relay requests between  the real website and the user, all while monitoring sent data. If the  browser has any saved cookies, they will also be sent in this initial  request, meaning an attacker could monitor for this initial request and  then hijack the user’s session.

The only flaw in the plan here is that 301 responses are cached by  the browser as long as they can be, meaning accessing / again will  automatically redirect to https:// instead of http://.

Bypassing 301 caching

It’s unlikely that an attacker will be monitoring your network before  you’ve first visited a big target website. It’s more likely your  browser will already have this cached redirect. However, there are two  cases where the cache becomes irrelevant:

  1. If you clear your browser cache (obviously!)
  2. If you go to http://target-site.com/?random_stuff

Since the browser will not have a stored 301 for /?random_stuff, it  will access the site directly over http before being redirected again.

The first method requires social engineering. An attacker could follow this attack path:

  1. Create an Access Point login page with a hidden iframe to  http://target-site.com/ and a javascript script that refreshes it every 5  seconds.
  2. Have the login page request the user to clear their cache in order to continue.
  3. When you detect an http request to the target-site, mark the client as successfully logged in.

This way, the only users accessing the internet are the ones who clear their cache.
When using this method it’s important to remember that this method is quite intrusive and thus likely to cause suspicion.

The second method can be done by creating an Access Point login page  with a hidden iframe to http://target-site.com/?random_stuff (where  random_stuff is of course random characters) and javascript that waits  10 seconds before forwarding to google or whatever referrer was  specified in the request.

It can also be done by injecting the above mentioned hidden iframe  into all http websites visited. It’s likely at least one page will be  loaded over http and when that happens, you obtain the session cookie of  the user.

Bypass non-preloaded HSTS through NTP

This specific technique was originally mentioned by Jose Selvi at Blackhat EU 2014

HSTS is the bad boy of MiTM mitigators. When configured correctly it  can prevent an attacker using a Man-In-The-Middle attack entirely. It  essentially means that the site uses https and any http links that go to  the site should be automatically changed to https. HSTS adds a header  to the server response that tells the browser how long it should  remember that this site should be https-only. When preloading isn’t on  (We’ll talk about what preloading is in just a moment), an insecure http  request first sent, similar to the 301 above. The difference this time  is that our second 301 cache bypass technique won’t work. If we get the  victim to visit http://victim-site.com/random-page, the browser will  automatically request https://victim-site.com/random-page.
However, although our first method DOES still work (Social engineering  the user to clear their cache), it’s still too intrusive for an attacker  who wishes to remain unnoticed.

Luckily for us, there is an alternative approach to this; NTP MiTM.

NTP (Network Time Protocol) is how your computer synchronises it’s  local time. It’s also done in plaintext without authentication (although  NTPv4 does have authentication capabilities, it’s still widely unused  for Operating Systems) and thus is a target. If an attacker can  manipulate the time on your computer, they can make your computer think  that the HSTS period is over and so next time you visit  target-domain.com, you will default to http:// and not https://
Jose Selvi has designed an incredible script specifically for NTP MiTM attacks named Delorean and can be found here.
In order not to re-write the wheel, I’m going to leave this section as  is. If you would like to learn more about this technique, I recommend  reading Jose’s brilliant paper on the subject here.

Bypassing Preloaded HSTS through logic errors

HSTS as described above is still vulnerable to manipulating the  initial plaintext request. In order to prevent this attack, a preload  list is used. Almost all modern browsers use a preload list to maintain  which sites use HSTS and thus do not need an initial http request. This  defeats all attacks mentioned above. It also prevents an attacker from  effectively altering DNS responses for that domain because of these two  points:

  1. HSTS Preloading automatically moves all requests for the domain to HTTPS instead of HTTP. No HTTP request will be made.
  2. If a malicious actor were to generate a self signed certificate  for a fake redirected server, it will cause the browser to alert the  user to a possible attack.

But there is hope!

A site is allowed to be on a preload list when a number of conditions are met:

  1. The site must have a valid certificate.
  2. If port 80 is open, it must redirect from HTTP to HTTPS.
  3. All subdomains must be served over HTTPS.
  4. An HSTS header must be served on the base domain.
  5. the max-age for HSTS on the site must be at least a year.
  6. The preload directive must exist in the HSTS header.
  7. Optionally the includeSubDomains directive can also be  specified. This means that the protection doesn’t just apply to the  specified domain/subdomain, but also all subdomains on it.

The preload list as maintained by Google can be found here.

If either the domain/subdomain is listed in the list or both a  domain/subdomain on the levels above it on it’s domain hierarchy is  listed, includeSubDomains is set for the website, and force-https mode  is set, the browser will not perform an HTTP request to it. However,  most sites will not have the root domain using includeSubDomains (which  would have made it impossible to MiTM any subdomain on this particular  root domain) in order to be more flexible.

In order for us to use the lack of includeSubDomains to our  advantage, we need to know which domains we can leverage to leak  cookies.

  1. Log onto the site you wish to target.
  2. In developer tools, view the cookies in storage.
  3. If the cookies you want to target start with . then you can target any subdomain of the cookie domain.
  4. If the chosen cookie has the secure flag set, it will not be  possible to leak the cookie over an HTTP request. You have to obtain  these by mitm’ing the response of a plaintext page to contain session  stealing javascript, or MiTM’ing the DNS response and pointing to your  server.
  5. The only cookies that aren’t possible to obtain are those with both the HTTPOnly flag, and the Secure flag set.
  6. Using the HSTS logic errors and loose cookie domains, we can trick the browser into leaking cookies over an unencrypted request.
Exploiting with MiTM on DNS

DNS has been a favourite for use in MiTM attacks. It’s lack of  authentication and regular use makes it the perfect target for  exploitation

If includeSubDomains is not set for the root domain, you can do the following:

  1. Redirect traffic temporarily to a fake subdomain of the target root domain.
  2. Fake the DNS response for the target subdomain to point to a controlled web server.
  3. The cookies that are valid for the subdomain will be sent to it over an HTTP request.
Exploiting without MiTM on DNS

DNS MiTM is all well and good for most clients, however what about  when either a client is security-savvy and is using something like  DNSCrypt, or in the future when authenticated DNS may become the norm?  We need an alternate technique. Luckily there are many problems in the  way HSTS preload rules are written and we can use problems to our  advantage.

  1. Identify the root domain you wish to target (For example, website.com)
  2. Identify all protected subdomains (e.g. mail, www, dev)
  3. Identify any unprotected subdomains from that list (e.g.  tools.development.website.com is protected with all it’s subdomains but  development.website.com is not, and website.com doesn’t protect all  subdomains of itself)
  4. Use this subdomain to leak the client’s cookie using whatever method  you think is best (a fair few have been mentioned in this post).

In order to help you in finding subdomains that are affected by this,  I’ve made a tiny script to allow you to find them. It can be found over  here: HSTS Preload Checker