The way that Firefox caches intermediate CA certificates could open the door to the fingerprinting of users and the leaking of browsing details, a researcher warned this week.
Alexander Klink, a security researcher based in Germany, discovered the issue and reported it to Mozilla in January but details of the bug weren’t made public via the company’s Bugzilla platform until Tuesday. Klink published a blog post and his proof of concept for the issue later the same day.
Intermediate certificates are subordinate certificates, usually used as a stand-in or proxy, issued by root certificates. Intermediate CAs enhance the security of SSL certificates by diminishing the potential for root cert compromise; if the root is compromised, the entire ecosystem could collapse, if an intermediate CA is compromised, the root CA can revoke it and issue a new one.
Fingerprinting Firefox users with cached intermediate CA certificates. #fiprinca https://t.co/6FQlN4ANlT pic.twitter.com/LfRKAu3tbI
— Alexander Klink (@alech) February 21, 2017
Klink discovered that through a third-party request–in this case one sent from his proof of concept website–he could determine which intermediate CAs a Firefox user has cached, even if the user is operating the browser in Private Browsing mode. Private Browsing mode doesn’t isolate a user’s cache, which is why Private Browsing users aren’t immune here, Klink claims.
According to Klink, the browser loads content from incorrectly configured hosts, hosts that are missing the intermediate cert, and then observes whether they were loaded correctly. The backbone of his test relies on trying to load an image from a webserver that has a valid cert, but not a intermediate CA. Klink is able to tell the difference between whether a user has an intermediate CA installed based on whether the image loads.
Upon visiting the site, assuming a user is on Firefox, Klink’s proof of concept immediately starts cycling through 326 different CAs–Comodo, VeriSign, WoSign, to name a few–and identifies any intermediate CAs associated with the profile.
He based his proof of concept on intermediate CA cert data he gathered from Root CA extract, a list of CA certificates extracted from Mozilla provided by the curl command line tool and library. He also used data from Censys, a search engine for hosts and networks, and Project Sonar, a Rapid 7 service that scans public-facing networks for apps, software, and hardware. With the tools he was able to uncover 3,366 intermediate CAs that ultimately chain back to a Firefox-trusted root.
According to Klink, “semantic information” gleaned from installed intermediate certificates could be used to piece together data on a user. Some CAs are country- and region- specific and could help an attacker narrow down where a user is based geographically. An attacker might also be able to determine where a user attends college, or studies, as well. In Klink’s case, he has a number of German academic certs pinned to his profile that could help fill out his fingerprint. If only a limited number of CAs are flagged by the exploit, it’s likely the user could be running the browser from a malware analysis sandbox, Klink claims.
Klink reported the issue to Mozilla on Jan. 27, but it’s unclear if the company can actually do anything – at least in the near future – about the problem. Klink says the easiest route would be to have the browser “not connect to incorrectly configured servers, regardless of whether the intermediate is cached or not,” but that’s likely not a move Mozilla would make.
The researcher advocates anyone concerned about the issue to be proactive when it comes to the cleanliness of their Firefox profile.
“From a user’s perspective, at the moment I can only recommend to regularly clean up your profile (by creating a fresh one, cleaning it up from the Firefox UI or using the certutil command line tool),” Klink wrote Tuesday, “Alternatively, blocking third-party requests with an add-on such as Request Policy might be useful since the attack obviously needs to make (a lot of) third-party requests.
Gervase Markham, a software engineer for Mozilla, weighed in on Klink’s finding via Bugzilla in late January and called Klink’s process “technically possible,” but admitted it’d be a “fairly terrible way of fingerprinting/tracking.” The engineer goes on to argue that each certificate only provides a small tidbit of information on a user.
“You would need 16-24 or so different SSL connections to different servers in order to give you a useful identifier, and that would probably be bad for the performance of your website. You’d also need to buy certificates from 16-24 different CAs, which would be a big hassle,” Markham wrote.
Still Markham acknowledged the issue and wondered if modifying the behavior of the cache, or just eliminating it, could mitigate the issue.
Mozilla’s next step appears to be gathering more information about the cache. Markham said that in order to move forward, engineers need more telemetry around it, mostly to see how much it’s being used but also to get a better grip on “performance characteristics, and the consequences of turning it off.” A bug was filed in Bugzilla earlier this month to look into the issue further but there’s been no visible movement since.
The Tor Browser, which is almost entirely built on Firefox code, apparently prevents cached certificate-based tracking like this. Arthur Edelstein, a Firefox engineer, also chimed in on Klink’s Bugzilla post, said a preference in Tor, security.nocertdb, is set to true. This makes it so the browser’s intermediate certificate store is memory-based only.
Still, this could be further tweaked, Edelstein says.
“A better solution might be to apply first-party isolation to the certificate cache instead, similar to the HSTS/HPKP effort,” Edelstein wrote.
Both Mozilla and Tor scrambled to fix a zero day at the end of November that could’ve been used to de-anonymize Tor users. That issue, ultimately tied to a use-after-free vulnerability, was much more severe than Klink’s. An attacker could have remotely executed arbitrary code to collect and forward IP and MAC addresses to a central server. The Tor Project is in the middle of hardening its browser with a sandboxed version, something that should limit de-anonymization attacks and confine future exploits to the sandbox.
