HSTS vs SSL Stripping attacks.

Image 1

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.

Image 1

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.

Image 2

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:


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:

Image 3

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.

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 ✅✅

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

Image 3

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 ✅

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

Image 4


Web servers with a badly HSTS configuration ❌

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.

Image 5

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

Image 6

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.

Image 7


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.

Image 8

However, HSTS is not applied.

Image 9

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

Image 10


Correct implementation

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


References