Tor Browser Does Not Clear CORS Preflight Cache despite creating a “New Identity”
via hackerone:
- Title: Tor Does Not Clear CORS Preflight Cache despite creating a “New Identity”
- Scope: Tor Browser
- Weakness: Information Disclosure
- Severity: Medium (4.3)
- Link: https://hackerone.com/reports/1652022
- Date: 2022-07-27 19:24:33 +0000
- By: @mirmasoodali
- CVE IDs:
Details:
Summary:
Tor triggers CORS Preflight Requests using the OPTIONS method similar to other browsers, including Firefox. Although the cache has been keyed to the top-level site, and depends on the URL of the requested resource, it does not get cleared when the user creates a “new identity”, and persists until the browsing instance has been quit. This increases the duration for which a user can be tracked, despite explicitly requesting to be forgotten.
Steps To Reproduce:
The attack has three phases:
- Generate and store the browser ID,
- Clear Browser Data
- Read the stored browser ID.
For simplicity, in the description below we assume that a tracking site makes the following domains publicly accessible -- (1.tracker.com, 2.tracker.com, 3.tracker.com, …, 32.tracker.com).
-
Write Browser ID
a. When a user visits a website, say attacker.com, it can make a CORS request to canary.tracker.com.
i. If canary.tracker.com does not observe an OPTIONS-based preflight request, before observing a request for the resource, an ID already exists in the cache. The attacker can proceed to the read phase. ii. If canary.tracker.com observes an OPTIONS-based preflight request, no ID has yet been set. The following steps can be executed.
b. The attacker creates a 32-bit ID, 1011…0011, and associates this ID with the tracking domains - 1.tracker.com -> Bit 1 - 2.tracker.com -> Bit 2 - 3.tracker.com -> Bit 3 …
i. Send CORS requests to each tracking domain associated with a bit that is equal to 1. ii. The client will first send a CORS Preflight Request before sending the actual request for each domain. The domains respond with an Access-Control-Max-Age header set to the maximum acceptable value, i.e., 2 hours. iii. The client caches the response to the preflight request.
-
The user clicks on the “New Identity” button in the browser’s toolbar.
-
Read Browser ID
a. When a user visits the attacker website, attacker.com, the attacker makes a CORS request to canary.tracker.com.
i. If canary.tracker.com observes an OPTIONS-based preflight request, no ID has yet been set. The attacker can first proceed to the write phase. ii. If canary.tracker.com does not observe an OPTIONS-based preflight request, before observing a GET request for the resource, an ID already exists in the cache. The following steps can be executed.
b. The attacker sends 32 network requests, one to each tracking domain, to read back each bit associated with it. - 1.tracker.com -> Bit 1 - 2.tracker.com -> Bit 2 - 3.tracker.com -> Bit 3 …
i. If a domain receives a resource request without initially observing a preflight request, the preflight for that domain was served from the cache. ii. These domains are associated with a bit value of `1`.
If a domain receives a preflight request before receiving a request for the domain, no entry for that domain was available in the client’s preflight cache.
iii. These domains are associated with a bit value of 0
.
The attacker hence reconstructs the 32-bit identifier and recognizes the unique browser instance, despite the user creating a “new identity”.
Supporting Material/References:
Proof-of-Concept Files Attached:
- Express Server: server.js
- Write 32-bit Identifier: write.html
- Read 32-bit Identifier: read.html
Credit Information
Mir Masood Ali, PhD student, University of Illinois at Chicago Binoy Chitale, MS student, Stony Brook University Mohammad Ghasemisharif, PhD Candidate, University of Illinois at Chicago Chris Kanich, Associate Professor, University of Illinois at Chicago Nick Nikiforakis, Associate Professor, Stony Brook University Jason Polakis, Assistant Professor, University of Illinois at Chicago
Impact
An attacker website can track a user across visits from the same browser instance, despite the user requesting a "new identity".