HSTS Creative Abuse Protection

Original author: Brent Fulgham
  • Transfer
HTTP Strict Transport Security (HSTS) is a security standard that allows a website to declare itself accessible only through secure connections, and redirect information is sent to browsers. HSTS-enabled web browsers also prevent users from ignoring certificate errors on servers.

Apple uses HSTS, for example, on iCloud.com , so every time you try to go to the unprotected address http://www.icloud.com from the address bar of the browser or through a link, it automatically redirects to https://www.icloud.com . This is a great feature that prevents simple errors, for example, on performing financial transactions on a channel without authentication.

What could be wrong here?

Well, the HSTS standard describes that a web browser should remember a redirect to a safe version - and automatically execute it on behalf of the user if he tries to establish an insecure connection in the future. Information for this is stored on the user's device. And it can be used to create "supercooks" that will be read by intersite trackers.

HSTS as Permanent Cross-Site Identifier (Super Cookies)


An attacker who seeks to track site visitors can use a bit of information from the HSTS cache on the user's device. For example, “download this domain via HTTPS” represents 1, and the absence of a record represents 0. By registering a large number of domains (for example, 32 or more) and initiating the downloading of resources from a controlled subset, you can get a sufficiently large bit space for a unique view of each site visitor .

The authors of HSTS recognized this possibility in section 14.9 of the specifications (“Creative manipulation of memorizing HSTS policies”):

... for those who control one or more HSTS computers, it is possible to encode information in domain names and force such user agents to cache this information in the process of marking HSTS computers. This information can be extracted by other computers by properly constructing and downloading web resources, forcing the user agent to send requests for encoded domain names.

When you first visit the site:

  • The visitor is assigned a random number, for example 8396804.
  • It is converted to a binary value (e.g., 10000000001000000000000100).
  • The tracker script requests subresources from controlled domains via https, one request for one bit of the tracking identifier.
    • https://bit02.example.com
    • https://bit13.example.com
    • https://bit23.example.com
    • … etc.
  • The server responds to each HTTPS request with an HSTS response header, which caches the value in a web browser.
  • Now we are guaranteed to download the HTTPS version of bit02.example.com, bit13.example.com and bit23.example.com, even if the user initiates the download via HTTP.

On subsequent visits to the website:

  • The tracker script loads 32 invisible pixels over HTTP , corresponding to bits in a binary number.
  • Since some of these bits (bit02.example.com, bit13.example.com and bit23.example.com in our example) have already been downloaded from HSTS, they are automatically redirected to HTTPS .
  • The tracking server transmits one image when requesting via HTTP, and the other when requesting via HTTPS.
  • The tracking script recognizes different images, turns them into zeros (HTTP) and ones (HTTPS) of a binary number, and voila - your unique binary identifier has been recreated, and now they are tracking you!

Attempts to defend themselves against such an attack are hindered by the need to strike a balance between security and privacy. Incorrect protection risks compromising important security mechanisms at the same time.

Tasks


Confidentiality risks due to HSTS are periodically discussed in the press as theoretical. In the absence of evidence of malicious abuse of the HSTS protocol, browser developers were careful to obediently follow all HSTS instructions from the sites.

We recently learned that this theoretical attack is actually being used against Safari users. Therefore, we have developed a balanced solution that maintains the security of web traffic while protecting it from snooping.

Apple Solution


An HSTS exploit consists of two steps: 1) creating a tracking identifier; 2) read operation. We decided to establish protection at both stages.

Protection 1: Limit HSTS installation to hostname or TLD + 1 only


We noticed that tracker sites construct long URLs that encode numbers at different levels of a domain name.

For example: We also noticed that tracker sites use a large number of related domain names, for example: Telemetry showed that attackers install HSTS simultaneously for a wide range of subdomains. Since using HSTS in this way does not correspond to normal use, but facilitates tracking, we changed the network stack to allow HSTS to be installed only for a loaded host name (for example, https://aaaaaaaaaaaaexample.com ) or TLD + 1 (for example, https: // example.com ).

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…и т.д...




https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...и т.д...
https://bit64.example.com




This prevents trackers from effectively setting a large number of HSTS bits. Instead, go to each domain that represents the bit in the tracking identifier separately. At the same time, content providers and advertisers may decide that a delay due to a redirect to 32 or more domains is unacceptable to them. WebKit also limits the size of the redirect chain, which limits the maximum number of bits in the identifier, even if attackers found the delay acceptable.

This solves the problem of installing supercooks.

Protection 2: Ignore HSTS state for subresource requests from locked domains


We modified WebKit so that requests to update the HSTS state are now ignored and the source URL is simply used if the link to download an insecure subresource comes from a domain for which cookies are blocked (for example, invisible tracking pixels). This leads to the fact that the bit identifiers of superstacks HSTS consist only of zeros.

Conclusion


The telemetry collected during the internal regression testing and from the final versions of the publicly available software indicates that the two described protections successfully prevented the creation and reading of HSTS super cookies without compromising the protection on the site. We believe that they are in line with best practices and provide the important safety measures provided by HSTS. We shared the first defense details with the authors of RFC 6797 (HSTS) and are working to make this mechanism part of the standard.

Also popular now: