- Bypassing Basic HTTPS
- Bypassing 301 Caching
- Bypass non-preloaded HSTS through NTP
- Bypassing Preloaded HSTS through logic errors
- Cookie Domains
- Exploiting with MiTM on DNS
- Exploiting without MiTM on DNS
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:
- If you clear your browser cache (obviously!)
- 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:
- Have the login page request the user to clear their cache in order to continue.
- 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.
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:
- HSTS Preloading automatically moves all requests for the domain to HTTPS instead of HTTP. No HTTP request will be made.
- 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:
- The site must have a valid certificate.
- If port 80 is open, it must redirect from HTTP to HTTPS.
- All subdomains must be served over HTTPS.
- An HSTS header must be served on the base domain.
- the max-age for HSTS on the site must be at least a year.
- The preload directive must exist in the HSTS header.
- 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.
- Log onto the site you wish to target.
- In developer tools, view the cookies in storage.
- If the cookies you want to target start with . then you can target any subdomain of the cookie domain.
- The only cookies that aren’t possible to obtain are those with both the HTTPOnly flag, and the Secure flag set.
- 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:
- Redirect traffic temporarily to a fake subdomain of the target root domain.
- Fake the DNS response for the target subdomain to point to a controlled web server.
- 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.
- Identify the root domain you wish to target (For example, website.com)
- Identify all protected subdomains (e.g. mail, www, dev)
- 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)
- 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