Protection against creative abuse of HSTS
HTTP Strict Transport Security (HSTS) is a security standard that allows a website to declare itself accessible only over secure connections, and redirects information to browsers. Web browsers with HSTS support also do not allow users to ignore 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 the link, it is automatically redirected to https://www.icloud.com . This is a great feature that prevents simple errors, for example, on executing financial transactions on a channel without authentication.
What could be wrong here?
')
Well, the HSTS standard describes that a web browser should remember to redirect to a secure 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 "superkukov", which will be read by cross-site trackers.
An attacker who seeks to track visitors to the site can use the bit of information from the HSTS cache on the user's device. For example, “load this domain via HTTPS” represents 1, and the absence of a record is 0. By registering a certain large number of domains (for example, 32 or more) and initiating the loading of resources from a controlled subset, you can get a sufficiently large bit space to uniquely represent each visitor .
The authors of HSTS recognized this possibility in section 14.9 of the specifications (“Creative manipulation of remembering the HSTS policy”):
When you first visit the site:
On subsequent visits to the website:
Attempts to defend against such an attack are hampered by the need to strike a balance between security and privacy. Improper protection risks simultaneously weakening important security mechanisms.
The risks of confidentiality 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 followed caution and dutifully followed all the HSTS instructions from the sites.
We recently learned that this theoretical attack in reality is being used against Safari users. Therefore, we have developed a balanced solution that preserves the security of web traffic while protecting against snooping.
The HSTS exploit consists of two steps: 1) creating a tracking identifier; 2) read operation. We decided to install protection at both stages.
We noticed that tracker sites construct long URLs that encode numbers at different levels of the domain name.
For example:
We also noticed that tracker sites use a large number of related domain names, for example:
Telemetry has shown that attackers set up HSTS simultaneously for a wide range of subdomains. Since using HSTS in this way does not correspond to normal use, but makes tracking easier, we changed the network stack to allow the installation of HSTS only for the loaded host name (for example, https://aaaaaaaaaaaaaexample.com ) or TLD + 1 (for example, https: // example.com ).
This does not allow trackers to effectively set a large number of HSTS bits. Instead, you must go separately to each domain that represents the bit in the tracking ID. At the same time, content providers and advertisers may decide that the delay due to 32 or more domains is unacceptable for them. WebKit also limits the size of the chain of redirects, which limits the maximum number of bits in the identifier even if the attackers found the delay acceptable.
This solves the problem of installing superkukov.
We modified WebKit so that HSTS state update requests are now ignored and the source URL is simply used if the link to downloading the insecure sub-resource comes from a domain for which cookies are blocked (for example, invisible tracking pixels). This leads to the fact that the bit identifiers of the HSTS superkuk consist of only zeros.
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 the HSTS supercooks without compromising the protection on the site. We believe that they are in line with best practices and provide important safety measures provided by HSTS. We shared the details of the first defense with the authors of RFC 6797 (HSTS) and are working to make this mechanism part of the standard.
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 the link, it is automatically redirected to https://www.icloud.com . This is a great feature that prevents simple errors, for example, on executing financial transactions on a channel without authentication.
What could be wrong here?
')
Well, the HSTS standard describes that a web browser should remember to redirect to a secure 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 "superkukov", which will be read by cross-site trackers.
HSTS as a permanent cross-site ID (superkuki)
An attacker who seeks to track visitors to the site can use the bit of information from the HSTS cache on the user's device. For example, “load this domain via HTTPS” represents 1, and the absence of a record is 0. By registering a certain large number of domains (for example, 32 or more) and initiating the loading of resources from a controlled subset, you can get a sufficiently large bit space to uniquely represent each visitor .
The authors of HSTS recognized this possibility in section 14.9 of the specifications (“Creative manipulation of remembering the HSTS policy”):
... 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 tagging HSTS computers. This information can be extracted by other computers by appropriately constructing and loading web resources, forcing the user agent to send requests for coded 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 (for example,
10000000001000000000000100). - The tracker script requests sub-resources from the controlled domains via https, one request for one bit of the tracking identifier.
https://bit02.example.comhttps://bit13.example.comhttps://bit23.example.com- … and so on.
- The server responds to each HTTPS request with an HSTS response header that 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 an HTTP download.
On subsequent visits to the website:
- The tracker script loads 32 invisible pixels over HTTP , corresponding to bits in 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 sends one image when requested via HTTP, and another when requesting via HTTPS.
- The tracking script recognizes different images, turns them into zeros (HTTP) and units (HTTPS) of a binary number, and voila - your unique binary identifier is recreated, and now you are being tracked!
Attempts to defend against such an attack are hampered by the need to strike a balance between security and privacy. Improper protection risks simultaneously weakening important security mechanisms.
Tasks
The risks of confidentiality 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 followed caution and dutifully followed all the HSTS instructions from the sites.
We recently learned that this theoretical attack in reality is being used against Safari users. Therefore, we have developed a balanced solution that preserves the security of web traffic while protecting against snooping.
Apple Solution
The HSTS exploit consists of two steps: 1) creating a tracking identifier; 2) read operation. We decided to install protection at both stages.
Security 1: Restrict the installation of HSTS to only the host name or TLD + 1
We noticed that tracker sites construct long URLs that encode numbers at different levels of the domain name.
For example:
https://aaaaaaaaaaaaaexample.com
https://aaaaaaaaaaaaexample.com
https://aaaaaaaaaaaexample.com
https://aaaaaaaaaaexample.com
https://aaaaaaaaaexample.com
https://aaaaaaaaexample.com
https://aaaaaaaexample.com
… ....We also noticed that tracker sites use a large number of related domain names, for example:
https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
... ....
https://bit64.example.comTelemetry has shown that attackers set up HSTS simultaneously for a wide range of subdomains. Since using HSTS in this way does not correspond to normal use, but makes tracking easier, we changed the network stack to allow the installation of HSTS only for the loaded host name (for example, https://aaaaaaaaaaaaaexample.com ) or TLD + 1 (for example, https: // example.com ).
This does not allow trackers to effectively set a large number of HSTS bits. Instead, you must go separately to each domain that represents the bit in the tracking ID. At the same time, content providers and advertisers may decide that the delay due to 32 or more domains is unacceptable for them. WebKit also limits the size of the chain of redirects, which limits the maximum number of bits in the identifier even if the attackers found the delay acceptable.
This solves the problem of installing superkukov.
Protection 2: Ignore HSTS state for requests for sub-resources from blocked domains
We modified WebKit so that HSTS state update requests are now ignored and the source URL is simply used if the link to downloading the insecure sub-resource comes from a domain for which cookies are blocked (for example, invisible tracking pixels). This leads to the fact that the bit identifiers of the HSTS superkuk consist of only 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 the HSTS supercooks without compromising the protection on the site. We believe that they are in line with best practices and provide important safety measures provided by HSTS. We shared the details of the first defense with the authors of RFC 6797 (HSTS) and are working to make this mechanism part of the standard.
Source: https://habr.com/ru/post/351476/
All Articles