{{Title|title={{project name}} Protection against Real World Attacks}}
{{Header}}
{{#seo:
|description=A list of many past anonymity attacks where {{project name}} kept its users safe.
|image=https://www.{{project_clearnet}}/w/images/0/0b/Realworldexplosion.jpg
}}

[[Image:Realworldexplosion.jpg|thumb|400px]]

__TOC__

= Introduction =

{{project name}} helps to protect users against various deanonymization attacks. This chapter lists many notable [https://googleprojectzero.blogspot.com/p/0day.html "in the wild" attacks] that deanonymized users who did not rely on the {{project name}} platform, but which failed against {{project name}} due to its fundamental design.

The threats posed by "zero day (0-day) exploits" are not just a hypothetical concern. Since 2014, the Google Project Zero initiative has discovered a new exploit every 17 days, with the majority (68 per cent) related to memory corruption bugs. There has been a large increase in the number of "in-the-wild" 0-day attacks in 2021, with 33 publicly disclosed already halfway through the year; this is 11 more than all of 2020. This is attributed to an overall rise in the total number of exploits being used, as well as greater detection and disclosure by researchers. In one sense the proliferation of 0-days is a positive sign, because it indicates improved overall security now requires attackers to rely more on them for successful exploits. On the downside, there is a significant increase in the number of vendors providing 0-days, particularly for mobile devices due to their popularity. <ref>https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/</ref>

A [https://www.wired.com/story/untold-history-americas-zero-day-market/ widespread and highly profitable industry] has developed around 0-days, illustrating that all sectors of society are potential targets of the hack-for-hire market, including those involved in politics, advocacy, global commerce and government. Hundreds of commercialized hacking entities have emerged to trade in offensive security, posing threats to individuals and groups who do not have sophisticated cybersecurity resources. In the past, 0-day capabilities were solely developed and used by a handful of nation states to operationalize exploits, but now it is more common for commercial providers to develop exploits and sell them to government-backed actors.

This reality explains why government regulation is sorely lacking in this area -- [https://i.blackhat.com/USA-19/Wednesday/us-19-Shwartz-Selling-0-Days-To-Governments-And-Offensive-Security-Companies.pdf government is one of the largest clients of offensive security companies] in order to bolster their surveillance and espionage capabilities. Government tolerance and perceived normalization for these types of services reinforces the notion that private individuals and organizations must utilize all available measures to better protect themselves.

= Real World Attacks =

== BitTorrent ==

[https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea IP leaks]([http://www.webcitation.org/6FDaBuhHi w]) have been reported when using ordinary proxification methods. However, since {{project name}} prevents information leaks, using BitTorrent will not leak a user's real external IP address (see [[File Sharing]]). The reason is  {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) has no knowledge of the external, ISP-facing IP address.

== Flash and Java ==

{{project_name}} prevents information leaks from browser plugins since it has no knowledge of the real external IP address. This protection also applies to Flash-based applications used by [https://en.wikipedia.org/wiki/Operation_Torpedo advanced adversaries]. Nevertheless, it is not recommended to install browser plugins such as Flash when anonymity is the goal. <ref name=plugin>[https://www.whonix.org/wiki/Comparison_with_Others#Flash_.2F_Browser_Plugin_Security https://www.whonix.org/wiki/Comparison_with_Others#Flash_.2F_Browser_Plugin_Security]</ref> See [[ Browser Plugins]] for further details.     

== Nautilus ==

A [https://bugzilla.gnome.org/show_bug.cgi?id=777991 security bug] was reported in Nautilus file manager that allows an attacker to disguise a malicious script as a <code>.desktop</code> file. <ref>http://linux.debian.bugs.dist.narkive.com/Z4frRjjC/bug-860268-desktop-files-can-hide-malware-in-nautilus</ref>  In this attack, an adversary tricks the user into downloading the <code>.desktop</code> file from a website or sends the file in an email. Once the file is on the target's computer, the file (PDF, ODT) only has to be opened by the user for the script to execute. 

This security bug was used to craft an exploit which was able to break the [https://subgraph.com/sgos/index.en.html Subgraph OS] security model.<ref name=break>[https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/ https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/]</ref> Since Subgraph does not contain Nautilus in an <i>Oz sandbox</i>, <ref>The Subgraph OS sandbox framework is known as Oz, which is unique to the platform. It is designed to isolate applications from each other and the rest of the system.</ref> once the malicious script was executed, it would have enabled access to much of the user's data; PGP keys, SSH keys, stored email, documents, password databases, MAC addresses and nearby Wi-Fi access points.

This sensitive information could be used by attackers to deanonymize the user, <ref>To be fair, when this bug was reported Subgraph OS was still in Alpha status.</ref> but {{project name}} defeats this attack and others like it. Since {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) is isolated from the host and {{gateway_product_name}} (<code>{{gateway_product_name_vm}}</code>), even if a malicious <code>.desktop</code> script is executed, no information can be gathered about the external IP address, hardware serials or sensitive data outside of {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>).<ref>All data inside {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) would be available to the attacker and aid deanonymization.</ref> Once Subgraph developers were informed of the vulnerability, the Nautilus package was patched on the platform. <ref name=patched>[https://twitter.com/subgraph/status/852000407253594114 https://twitter.com/subgraph/status/852000407253594114]</ref>

== P2P ==

An [https://hal.inria.fr/inria-00574178/en/ attack]([https://www.webcitation.org/6FVK6WpNu w]) was published that targets P2P applications in order to trace and profile Tor users. {{project name}} defeats this attack and others like it because {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) has no knowledge of the external IP address. Furthermore, {{project name}} provides extended protection by using [[Stream Isolation|Stream Isolation]].

== Pidgin ==

A bug was found in [https://www.webcitation.org/6FDZj1gpN Pidgin source code] that would have leaked the real IP address. <ref>https://mailman.boum.org/pipermail/tails-dev/2012-September/001704.html</ref> {{project name}} did not exist when this bug was discovered. Nevertheless, the security by isolation model adopted by {{project name}} prevents this kind of leak from occurring. Notably, this bug only existed in the developmental source code and it was patched before the release date.

== Skype ==

{{project_name}} will not leak a user's IP address / location while using [[Voip#Skype|Skype]] or other [[Voip|VoIP]] protocols, although [[VoIP#Introduction|it is fairly difficult to anonymize voice]] over these channels.

== Targeted Clock Skew Correlation ==

This type of correlation allows an adversary to acquire the time stamp of an Onion Service http header and measure the skew ([https://www.webcitation.org/6FDZnhH5j clock skewing])([https://www.webcitation.org/6FDZnhH5j w]). The adversary then compares the acquired time stamp against Tor relays or other publicly reachable web servers. If the time skew of the Onion Service server matches any publicly reachable servers or Tor relays, it is very likely the Onion Service is hosted on the same server. 

{{project_name}} defeats this and other [[Time Attacks| time attacks]] since it uses [[Boot Clock Randomization]] and [[sdwdate]]. This program connects to a variety of servers (likely to be hosted on different hardware) at random intervals and extracts time stamps from the http headers. Using the sclockadj option, time is gradually adjusted thus preventing bigger clock jumps that could confuse logs, servers, Tor, i2p, etc. <ref name=sdwdate-github>
[https://github.com/{{project_name_short}}/sdwdate https://github.com/{{project_name_short}}/sdwdate]
</ref> <ref>
To be fair, when this attack was first described {{project name}} did not exist.
</ref>

{{mbox	
| image   = [[File:Ambox_warning_pn.svg.png|40px]]	
| text    = It is not recommended to run Tor relays on a publicly reachable server along with an Onion Service on the same server. This configuration aids [https://www.webcitation.org/6FDZnhH5j traffic correlation and fingerprinting].	
}}

== Thunderbird ==

[https://tails.boum.org Tails] reported that [https://tails.boum.org/security/IP_address_leak_with_icedove/index.en.html Thunderbird leaked]([https://www.webcitation.org/6FDZcatic w]) the real external IP address. Although {{project name}} did not exist when this bug was discovered, it would have been impossible for the real external IP address to leak, since {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) has no knowledge of it. In fairness to Tails, this kind of leak is now considered unlikely since they no longer use transparent torification. <ref name=transparent>[https://mailman.boum.org/pipermail/tails-dev/2012-September/001704.html https://mailman.boum.org/pipermail/tails-dev/2012-September/001704.html]</ref>

== Tor Browser Bundle ==

# A severe [https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs bug]([https://www.webcitation.org/6FDZlP2Ht w]) was discovered in FireFox which related to WebSockets bypassing the SOCKS proxy DNS configuration. <ref name=proxy-bypass>[https://gitlab.torproject.org/legacy/trac/-/issues/5741 https://gitlab.torproject.org/legacy/trac/-/issues/5741]</ref> {{project name}} defeats this bug since {{gateway_product_name}} (<code>{{gateway_product_name_vm}}</code>) forces all traffic through the Tor network or it is blocked. At worst, a proxy bypass would have emitted traffic through Tor's TransPort. In this scenario, the only information that could leak is the IP address of another Tor Exit Relay, which would not affect anonymity.
# An old [https://lists.torproject.org/pipermail/tor-announce/2013-August/000089.html attack] <ref>
https://blog.torproject.org/tor-security-advisory-old-tor-browser-bundles-vulnerable
</ref> was observed in the wild that exploited a JavaScript vulnerability in Firefox. <ref>JavaScript was enabled by default in Tor Browser at the time this exploit was discovered.</ref> The observed version of the attack collected the [[Hostnames|hostname]] and [[MAC_Address|MAC address]] of the victims' computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a [[Tor_Browser#Security_Slider|security slider]] in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings. Nevertheless, {{project name}} would have protected against a MAC address leak <ref>Since {{workstation_product_name}} (<code>{{workstation_product_name_vm}}</code>) is unaware of the MAC address.</ref> and at worst leaked a [[Hostnames|hostname which is common to all {{project name}} users]].
# TorMoil: A [https://blog.torproject.org/tor-browser-703-released security bug] was reported in version 7.0.2 that allowed systems with GVfs/GIO support to bypass Firefox proxy settings using a specially crafted URL, leading to an IP address leak. <ref>
https://www.wearesegment.com/research/tormoil-torbrowser-unspecified-critical-security-vulnerability/
</ref> Since {{gateway_product_name}} (<code>{{gateway_product_name_vm}}</code>) forces all traffic through Tor, and information leaks are blocked, {{project name}} users were not affected by this bug. <ref>
Quote [https://blog.torproject.org/tor-browser-703-released The Tor Project]:
<blockquote>
Tails and {{project_name}} users, and users of our sandboxed Tor Browser are unaffected, though.
</blockquote>
</ref>
# A [https://gitlab.torproject.org/legacy/trac/-/issues/8751 defect] was discovered which allowed an adversary to use targeted clock skew correlation to identify a user.  Since Tor Browser transmits TLS "Hello Client" <code>gmt_unix_time</code> there are two scenarios in which these transmissions could be used to track users. 
** In the first scenario an adversary either compromises [https://en.wikipedia.org/wiki/Network_Time_Protocol NTP] servers or uses a man-in-the-middle to intercept NTP server replies and introduces a unique clock skew. Since "Hello Client" transmissions are visible to ISPs that host Tor Exit Relays as well as destination servers, an adversary could use clock skew correlation to track users' movements. 
** In the second scenario, a user visits a clearnet website under adversary control without Tor Browser and the unique clock skew of the TLS "Hello Client" <code>gmt_unix_time</code> is recorded.  Afterwards, the user visits the same or a different adversary-controlled website using Tor Browser. If both clock skews match, this could indicate the two visitors were the same person. At the very least this would significantly degrade anonymity. Since {{project name}} uses [[Boot Clock Randomization]] and [[sdwdate]] and not NTP to keep time, these instances of targeted clock skew correlation and many like it are defeated.

= See Also =
* [[Security Reviews and Feedback]]
* [[Dev/Leak_Tests|Leak Tests]]

= Footnotes =
{{reflist|close=1}}

{{Footer}}

[[Category:Documentation]] [[Category:Design]]
