Bypassing HTTP Strict Transport Security (HSTS)

Hanno Böck

Once there was HTTP without encryption

In 1995, Netscape introduced SSL - today known as TLS - and HTTPS

SSL and HTTPS

  • Encryption
  • Integrity
  • Authentication

SSL and HTTPS

  • Expensive
  • Optional security
  • Mixing secure and insecure contexts

Mixing secure and insecure contexts

Mixing secure and insecure contexts isn't just a problem with HTTP; it's also a problem with e-mail protocols

NO STARTTLS
https://nostarttls.secvuln.info/		 Talk STARTTLS at Bornhack
https://youtu.be/kgR1nQYWBM8

Today, we want to talk about mixing insecure HTTP with secure HTTPS

Cookies

Cookies are bound to the hostname (e.g., www.example.com) or the whole domain (e.g., .example.com)

Cookies

Set Cookie over HTTPS

Read Cookie over HTTP

Cookie Secure Flag

RFC 2109, 1997

Optional. The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.

The user agent (possibly under the user's control) may determine what level of security it considers appropriate for "secure" cookies. [...]

RFC 6265, 2011

The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).

RFC 6265, 2011, continued

Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity [...]

A fix for that problem was only provided very recently

__Host- / __Secure- prefix

Still just a draft, but use them!

draft-ietf-httpbis-rfc6265bis-13

Just because we have a Secure flag for cookies does not mean people will use it

Session-Cookies and SSL, 2008

Found and reported problems in various PHP web apps and described a practical attack on eBay

Firesheep (2010)

Plugin that made Cookie stealing attacks easy

Other Cookie Security features (not TLS related)

  • HttpOnly
  • SameSite=Lax/Strict/None

This is how your Cookies should look like

Set-Cookie: __Host-SESSID=c60fu856m8u25vrv; path=/; Secure; HttpOnly; SameSite=Lax

Cookies are not the only problem of mixing secure HTTPS and insecure HTTP

Redirects

Let's say you want to have a very secure website, so you redirect all HTTP calls to HTTPS

HTTP/1.1 301 Moved Permanently
Location: https://hboeck.de/

The redirect is still HTTP and is not protected!

SSL Stripping

Moxie Marlinspike, 2009

A network attacker can prevent the redirect and serve a fake webpage over HTTP

Speaking of Redirects...

I see something like this quite often:

  • https://example.com/ redirects to http://www.example.com/
  • http://www.example.com/ redirects to https://www.example.com/

https -> http -> https

Don't do that!

How can we fix SSL Stripping?

HTTP Strict Transport Security (HSTS)

RFC 6797, 2012

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

max-age=31536000

HSTS Expires!

How do you set the time on your computers?

Network Time Protocol (NTP)

NTP is insecure by default and had no TLS support until 2020

Delorean attack on HSTS

                                    _._                                          
                               _.-="_-         _                                 
                          _.-="   _-          | ||"""""""---._______     __..    
              ___.===""""-.______-,,,,,,,,,,,,`-''----" """""       """""  __'   
       __.--""     __        ,'                   o \           __        [__|   
  __-""=======.--""  ""--.=================================.--""  ""--.=======:  
 ]       [w] : /        \ : |========================|    : /        \ :  [w] :  
 V___________:|          |: |========================|    :|          |:   _-"   
  V__________: \        / :_|=======================/_____: \        / :__-"     
  -----------'  ""____""  `-------------------------------'  ""____""

Jose Selvi, 2014

Luckily, we have Network Time Security (NTS) now

RFC 8915, 2020

Optional, usually not enabled by default, enable it!

HSTS is Trust-on-First-Use

First connection problem

preload

HSTS preload list

  • ~140.000 entries
  • 15 Megabyte uncompressed
  • 1 Megabyte compressed

includeSubDomains

Hanno in late 2023:

How exactly does the includeSubDomains flag in HSTS work?

I tried a few things

This does not look right!
This is great. Now I know what to submit to Nullcon!

Assume the following

  • https://example.com/ sets an HSTS policy with includeSubDomains
  • https://sub.example.com/ sets an HSTS policy without includeSubDomains
  • Which policy applies to sub.sub.example.com?
  • Can you open http://sub.sub.example.com/?
  • RFC says No
  • Chrome blocks it
  • Firefox before version 122 opens it

In Firefox before 122, any subdomain with an HSTS policy without includeSubDomain disables HSTS for all sub-sub-domains.

This even works with preloading!

Mozilla developers immediately agreed that this is a vulnerability and needs to be fixed

CVE-2024-0753

Fixed in Firefox 122

wget also affected

(fixed in 1.24.5, low impact)

Why is this a problem?

Imagine the following:

  • https://example.com/ uses HSTS, includeSubDomains, *AND* preloading
  • https://example.com/ sets a Cookie for .example.com without the "Secure" flag. (HSTS already makes sure it's secure!)
  • https://sub.example.com/ uses HSTS without includeSubDomains

Attack!

  • Attacker sends user to https://sub.example.com/ without includeSubDomains policy
  • Attacker sends user to http://sub.sub.example.com/ - Cookie is transmitted in plain text

netflix.com has all the conditions for this attack to work

Have I reported this to Netflix?

No

Contact: https://bugcrowd.com/netflix
Policy: https://bugcrowd.com/netflix
Hiring: https://jobs.netflix.com/
Acknowledgments: https://bugcrowd.com/netflix/hall-of-fame
Expires: 2025-01-01T06:00:00.000Z

Bugbounty as the only security contact is a problem

  • Bugbounty triagers are trained to reject as much as possible (sad, but true)
  • Technically, this is not a vulnerability on netflix.com, "just" a non-ideal configuration

https://bugcrowd.com/netflix

Please note: This program or engagement does not allow disclosure.

In preparation for this talk, I wanted to create a demo

I tried the demo in Firefox 121 (vulnerable), it worked as expected.

I tried the demo in Firefox 122 (fixed), it still worked 🤔

That was unexpected

As an attacker, how can you make sure a user opens another webpage?

Iframes!

Firefox does not let subresources set HSTS policies...

This was an attempt to fix another bug that is also undermining HSTS...

... and it did not even fix it.

https://bugzilla.mozilla.org/show_bug.cgi?id=1701192
https://bugzilla.mozilla.org/show_bug.cgi?id=1818984

Even before that, Firefox used partitioning for HSTS on subresources (similar to Cookies)

HSTS is a good feature, and you should use it, but its implementation is not necessarily robust, particularly in Firefox

Demo time!

Recommendations for Web Developers

Use HSTS and always set includeSubDomains

Use HSTS preloading for important domains

Even with HSTS, use other tools to prevent plaintext leakage

Redirects

Always redirect from http:// to https://

If your main webpage is on the www subdomain

  • First redirect from http://example.com/ to https://example.com/
  • Then from https://example.com/ to https://www.example.com/

This makes sure you protect all subdomains.

Avoid insecure redirects

No https:// -> http:// -> https://

Cookies

Should always have the "Secure" flag, HSTS is no excuse for not having it

Use __Host- prefix if possible, __Secure- prefix otherwise

Recommendation for Users

Enable HTTPS only mode in your browser

Thanks for listening!

Any questions?

QR

Need help with HTTPS, HSTS, TLS?
Contact me:
https://itsec.hboeck.de/