https://www.hackerfactor.com/blog/index.php?/archives/944-Tor-0day-Snowflake... https://www.hackerfactor.com/blog/index.php?/categories/19-Tor Tuesday, 21 December 2021 Back in 2020, I wrote nine blog entries about Tor that covered a wide range of vulnerabilities. Many of them were well-known to the Tor Project (some nearly a decade old!) but had never been addressed and had no viable mitigation options or alternatives. Other issues were brand new and first disclosed on my blog. (The last blog entry begins with a summary of the vulnerabilities.) Of all of the vulnerabilities and concerns that I raised in 2020, the Tor Project didn't address any of them. Zero. Over the past year, there were over a dozen updates for the Tor daemon (and that's not counting the pre-releases). There were also over a dozen updates to the Tor Browser (from version 10.0.8 to 11.0.3), but most of these were basically incorporating updates from Firefox. The main Tor-specific changes were the deprecation and removal of onion v2 support (replaced by v3 addresses) and the formal release of snowflake as a pluggable transport. Some of my "Tor 0day" blog entries mentioned a lack of good pluggable transports for when someone blocks direct and indirect (bridge) connections. Snowflake introduces another connection option, but it has its own serious limitations and is far too detectable. Still Viable Exploits My "Tor 0day" blog series focused on one specific scenario: Can someone watching the network traffic determine if you (specifically you) were using Tor? For example, many companies do not permit Tor within the corporate network. This restriction prevents malware from downloading past the corporate anti-virus scanners and deters someone from potentially leaking company-confidential information. These companies don't mind if you use Tor on your home network and home computer; just not on anything that touches the company's network. For these companies, it is one thing to have a rule about "no Tor", but it's another to enforce the rule by detecting and immediately blocking anyone who violates the rule. This threat vector is also seen when countries block access to Tor. Earlier this month, the Tor Project made an announcement that Russia was blocking Tor. What they didn't mention was that these blocks were made possible using the exact same methods disclosed in my blog series a year earlier. Moreover, the Tor Project had known about these issues for years. The Tor Project's alert about Russia was really just a complaint that people were blocking their service through exploits that the Tor Project hasn't felt like fixing. The Open Observatory of Network Interference (OONI) is an organization that tracks online censorship. About 10 days after the Tor Project's announcement, OONI posted their report. According to OONI, it wasn't all of Russia blocking Tor; it was 15 out of 65 subnets. Moreover, each censorship instance used a different blocking method: In some cases though (such as on AS42437), OONI data suggests that access to torproject.org is being interfered with by means of a TLS man-in-the-middle attack, while in other cases (such as on AS51570), we observe that the connection is reset once the TLS handshake has been initiated, suggesting the use of Deep Packet Inspection (DPI) technology. If the censorship was government-sponsored, as the Tor Project suggested, then I would expect it to be much more widespread and consistent. This looks like individual blocking efforts. As OONI noted, the blocks followed a "recent spike in the use of Tor bridges (used for circumventing Tor blocking) in Russia." To me, this looks like ISPs having a problem with Tor users. Tor is often viewed a bad neighborhood since it is often associated with other criminal activities, like human trafficking and drugs. By blocking Tor access, these services reduce the number of bad actors on their networks. This censorship also means that these ISPs could easily detect Tor bridges (as noted in my second Tor 0day blog entry.) If the Tor Project actually provided anonymous or less detectable bridges, then this filtering would never have happened. Similarly, this year Tor researcher Nusenu found that one persistent threat group (KAX17) had managed to create thousands of Tor nodes. With that many nodes, they can easily decloak hidden services and track individual users. This group has been around since at least 2017 and the Tor Project's efforts to remove them have been ineffective. (See my 6th blog entry for more details.) Pluggable Transports Tor uses pluggable transports as alternative protocols for connecting to the Tor network. My second blog entry shows how to detect and block all production pluggable transports. Moreover, code had been deployed and was working in real-time on high-volume networks. (As an aside: as far as I know, my code is not being used for those Russian blocks.) I had previously mentioned that the Tor Project had dropped support for all pluggable transports except obfs4 and meek, and meek was being shut down by various cloud providers. In effect, the Tor Project was putting all of their eggs in one basket (obfs4) and hoping that ISPs wouldn't block it -- even though it was trivial to detect and filter. Obfs4 acts as a trojan protocol. It sends encrypted communication over a known port, like 22/tcp (normally used by Secure Shell) or 443/tcp (normally used by HTTPS). It's a trojan protocol because it doesn't speak the right language when using a well-known port. Any kind of stateful packet inspection at the session or application layer will easily detect it. Meek depends on TLS tunneling. I currently have a couple of methods for easily detecting Tor's use of meek. The Tor Project's solution was to introduce a new pluggable transport: snowflake. Snowflake had been a work-in-progress since 2016 and takes a different tunneling approach. It pretends to be a WebRTC (video chat) communication stream. WebRTC relies on a couple of protocols, including STUN and ICE. (The name 'snowflake' is because it is related to the ICE communication protocol. It is not intended as a derogatory term.) Detecting Snowflake Of all of the pluggable transports that the Tor Project has released, I think snowflake is the easiest to detect. I'm not saying that the others were difficult to detect and filter. Rather, the other protocols (fte, obfs3, obfs4, meek, etc.) only had a few ways that they could be detected. Snowflake has literally dozens of trivial ways to detect it. For example, video chats rely on a protocol called STUN (Session Traversal Utilities for NAT; network address translation). Basically, STUN identifies your external network address. This is needed to establish any kind of video chat when you use a firewall. Snowflake uses a hard-coded list of available STUN servers. The current list is: stun.voip.blackberry.com:3478 stun:stun.altar.com.pl:3478 stun:stun.antisip.com:3478 stun:stun.bluesip.net:3478 stun:stun.dus.net:3478 stun:stun.epygi.com:3478 stun:stun.sonetel.com:3478 stun:stun.sonetel.net:3478 stun:stun.stunprotocol.org:3478 stun:stun.uls.co.za:3478 stun:stun.voipgate.com:3478 stun:stun.voys.nl:3478 When the snowflake client first starts up, it queries DNS for a randomly selected subset of these STUN servers. It looks for the hostname resolution using both IPv4 and IPv6 (DNS 'A' and 'AAAA' records). However, it doesn't just look up the hostnames; it checks if the name is on the local network. Like most companies, my lab uses a private network behind the firewall and runs an internal DNS server. All computers on my private network use the domain name "internal.lan". When I started snowflake, I immediately saw a set of DNS queries for the STUN servers: client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com' client -> dnsserver : DNS Query Type[1]=A Name='stun.epygi.com' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.sonetel.net' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com.internal.lan' Each line is one packet, and all of this happened in one second. This means that I have multiple ways to detect a Tor snowflake client before it even tries to connect to the Tor snowflake server! A single WebRTC client typically connects to one STUN server. If you see a single client immediately lookup multiple STUN servers and all of the servers are in the snowflake hard-coded list, then you've found a Tor snowflake client. Regular WebRTC clients do not do hostname lookups for remote STUN servers on the local network. If you see any DNS lookups for snowflake's STUN servers on the local network (stun.epygi.com.internal.lan, stun.voipgate.com.internal.lan, etc.) then you've found a Tor snowflake client. About a second later -- after doing the DNS lookups -- there are queries for the snowflake hard-coded domain fronting server: client -> dnsserver : DNS Query Type[1]=A Name='cdn.sstatic.net' client -> dnsserver : DNS Query Type[1]=AAAA Name='cdn.sstatic.net' Again, if you see any IP address that first does a DNS lookup for a snowflake STUN server and then does a lookup for the snowflake domain fronting service, then you've found a Tor snowflake client. These are just 3 ways for an administrator to watch DNS in order to detect or block Tor snowflake users before they can connect to the Tor network. There are another dozen ways to detect snowflake (zero false positives, zero false negatives) if you start looking at how it uses STUN and ICE. In addition, a snowflake client can be used to identify the IP addresses of other Tor users because other Tor users provide the snowflake proxies. (The entire snowflake protocol strikes me as a project created by a group that put no consideration into how an adversary might detect or block this pluggable transport.) I want to emphasize the warning from my earlier blog entries: If you are in a location where using Tor can result in an arrest, being tracked by government agents, or losing your job, then do not rely on snowflake for anonymity or to protect your privacy. The Tor Project provides zero solutions if you are located in a repressive location. Tor: State of the Onion Earlier this year, I attended the Tor Project's online "State of the Onion" presentation. During the presentation, different members spoke about all of the great things that the Tor Project was doing to advance online privacy, anonymity, and anti-censorship. They even praised snowflake as a success. If you didn't know the technical details, then you might get the impression that this was very positive and incredible forward movement. The amount of spin from the Tor Project was as good as any nation-state or political announcement. But behind the scenes? They haven't addressed any of their core issues. If someone wants to track you through Tor, deanonymize your network activity, or prevent you from accessing Tor, then they can do it and you cannot stop them. And if you do something illegal over Tor and you haven't been arrested, then it's only because there are bigger villains than you; you're not a high priority -- yet. Today, the Tor Project seems to be more focused on fund raising than actual privacy, anonymity, or anti-censorship. I wonder if they will ever start fixing these known issues.