HSTS vs SSL Stripping attacks.

November 11, 2019

HTTP Strict Transport Security (HSTS) is a web server security policy that forces web browsers to respond via HTTPS connections rather than HTTP. But do users pay attention to this? How effective are SSL Stripping attacks against modern websites? How is HSTS well implemented?

How HSTS works?

When a URL is entered in the web browser and the protocol part is omitted, for example, by typing jlajara.gitlab.io instead of https://jlajara.gitlab.io, the browser assumes that you want to use the HTTP protocol. The HTTP protocol sends the information in plain text, therefore it is considered a vulnerable protocol. Any attacker in the same network performing a MITM (Man-in-the-middle) attack could read this information.

Normally, in this situation, the web server responds with a redirection (response code 301) pointing to the HTTPS site. Then, a HTTPS connection is established with https://jlajara.gitlab.io.

In order to prevent that in later cases the information will be send in plain text again by mistake, using the HTTP protocol, the server responds with a header to apply the HSTS security policy once the HTTPS connection has been made. This header is called HSTS Header and looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This header gives specific instructions to the browser. From now on, each connection to the site and its subdomains for the next year (31536000 seconds) from the moment you receive this header, must be an HTTPS connection. HTTP connections are not allowed at all. If the browser receives a request to load a resource using HTTP, you should try it with an HTTPS request. If HTTPS is not available, the connection must be terminated.

In addition, if the certificate is invalid the connection will be terminated. Normally, if a certificate is invalid (expired, self-signed, signed by an unknown CA, etc.), the browser displays a warning that you can bypass. However, if the site is configured with HSTS, the browser will not allow you to bypass the warning at all. To access the site, you must remove it from the HSTS list of the browser.

The Strict-Transport-Security header is sent for a given website and covers a particular domain name. Therefore, the HSTS header for test.jlajara.gitlab.io will not cover jlajara.gitlab.io, only test subdomain. Therefore, for complete protection, an include call must be included to the base domain (in this case, jlajara.gitlab.io) and receive a Strict-Transport-Security security header for that domain with the includeSubDomains directive.

In addition, the browser ignores the Strict-Transport-Security header when accessing your site forzing the HTTP schema.

How bad HSTS implementations could be exploited?

The absence of HSTS can trigger an attack when:

User writes http://jlajara.gitlab.io through bookmarks or enters it manually and is subject to an attacker of the type Man-in-the-middle.
A web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP.
HSTS is implemented in a subdomain but not in the root domain.

SSL Strip

In order to simulate an attack scenario, two virtual machines (victim and attacker) were placed on the same network.

The attack is known as SSL Strip and consists on the following:

1. An attacker performs a Man-in-the-middle attack by poisoning the victim’s ARP table.
2.The victim’s HTTP traffic is redirected to a proxy created by the attacker.
3.The attacker sends the victim’s traffic over HTTPS and serves the content of the response to the victim over HTTP.
4.The traffic generated by the victim is read by the attacker and sent to the server continuously.

This technique was discovered by Moxie Marlinspike an presented at BlackHat 2009: Slides - Video

Exploitation

To properly perform a MiTM attack, an attacker should poison the victim’s ARP table. To do this, the attacker would continuously send ARP packets to the victim, stating that the gateway IP is the attacker’s machine. The traffic will be sent to the attacker and he will send it back to the gateway, allowing it to be placed in the middle of the connection. This technique is known as ARP Poisoning.

Bettercap can be used for this. It also includes a module to automatically set a proxy and perform SSLStrip.

Note: It is important to use Bettercap version 1.x, as during the writing of this document, version 2.x does not perform SSLStrip correctly.

Installation:

apt-get install ruby-full
apt-get install libpcap-dev
gem update --system
gem install bettercap
ln -s /var/lib/gems/2.5.0/gems/bettercap-1.6.2/bin/bettercap /root/bettercap-1.6.2
./root/bettercap-1.6.2

Once installed, to perform a MyTM attack with SSLStrip the following command is executed:

./bettercap-1.6.2 -T <victim_ip> --proxy

The modules that are being executed are showed:

[ spoofing:✔ discovery:✘ sniffer:✘ tcp-proxy:✘ udp-proxy:✘ http-proxy:✔ https-proxy:✘ sslstrip:✔ http-server:✘ dns-server:✔ ] ...

Common HSTS cases

Web servers with HSTS properly implemented and HSTS is preloaded in the browser ✅✅
Web servers with HSTS properly implemented and HSTS is not preloaded in the browser ✅
Web servers with a badly HSTS configuration ❌
Web servers withous HSTS ❌❌

Web servers with HSTS properly implemented and HSTS is preloaded in the browser ✅✅

In this case, the first web request is made with HTTPS, facebook.com could be checked.

The first HTTP packet forces the use of HTTPS, making it immune to SSLStrip.

Web servers with HSTS properly implemented and HSTS is not preloaded in the browser ✅

1. The first web request is made using HTTP.
2. A redirection to the main domain is performed forzing HTTPS.
3. The HTTPS response cointains the HSTS header and applies HSTS to all the domain and subdomains.
4. Each time the browser tries to connect to the URL, HTTPS is forced.

In this case yahoo.com has been used as an example.

Web servers with a badly HSTS configuration ❌

1. The first web request is made using HTTP.
2. The web page redirects to another subdomain where it adds HSTS forzing HTTPS. However, this HSTS header is only applied to the subdomain where it redirects and not to the main domain.

For example, when you make a request to outlook.com, the first request is HTTP and makes a redirection to the subdomain https://www.outlook.com.

HSTS is applied to the subdomain www.outlook.com, but not to the main domain outlook.com.

An attacker could impersonate another outlook.com subdomain by poisoning the DNS and cloning the DNS content, since HSTS only applies to www.outlook.com. In this case, a fake subdomain is set at wwwww.outlook.com faking the web content of the victim.

Web servers withous HSTS ❌❌

In this case, all requests are made using HTTP. There is no security mechanism that forces the use of HTTPS after a second request is performed.

For example, when you visit webs.com, there is a redirection to https://webs.com.

However, HSTS is not applied.

Therefore, any next request will maintain the HTTP protocol and a SSLStrip could be performed.

Correct implementation

Serve a valid certificate.
Redirect from HTTP to HTTPS on the same host (if listening on port 80).
Serve all subdomains over HTTPS.
- In particular, HTTPS must be supported for the www subdomain if a DNS record exists for that subdomain.
Serve an HSTS header in the base domain for HTTPS requests:
- The maximum age must be at least 31536000 seconds (1 year).
- The includeSubDomains directive must be specified.
- If an additional redirection from the HTTPS site is serving, that redirection must have the HSTS header (instead of the page it redirects to).

To check the HSTS status of a webpage hstspreload.org is the best option.