The trust of the Tor anonymity network is in many cases only as strong as the individual volunteers whose computers form its building blocks. On Friday, researchers said they found at least 110 such machines actively snooping on Dark Web sites that use Tor to mask their operators’ identities.
All of the 110 malicious relays were designated as hidden services directories, which store information that end users need to reach the “.onion” addresses that rely on Tor for anonymity. Over a 72-day period that started on February 12, computer scientists at Northeastern University tracked the rogue machines using honeypot .onion addresses they dubbed “honions.” The honions operated like normal hidden services, but their addresses were kept confidential. By tracking the traffic sent to the honions, the researchers were able to identify directories that were behaving in a manner that’s well outside of Tor rules.
“Such snooping allows [the malicious directories] to index the hidden services, also visit them, and attack them,” Guevara Noubir, a professor in Northeastern University’s College of Computer and Information Science, wrote in an e-mail. “Some of them tried to attack the hidden services (websites using hidden services) through a variety of means including SQL Injection, Cross-Site Scripting (XSS), user enumeration, server load/performance, etc.”
There’s no evidence the malicious relays were able to identify the operators or visitors of the hidden sites or monitor the plain-text traffic passing between them. But the researchers from Northeastern can’t rule out those possibilities, either. Both SQL and XSS exploits can reveal a wealth of sensitive information on servers containing administration or configuration errors or vulnerabilities that aren’t publicly known. What’s more, more than a quarter of the rogue directories also functioned as exit nodes, a status that allowed the malicious relays to view all unencrypted traffic.
To create a misbehaving directory, an operator would have to first modify the code provided by Tor to add logging capabilities, making it unlikely the snooping was inadvertent or the result of some sort of glitch. Professor Noubir presented his findings on Friday at the Privacy Enhancing Technologies Symposium in Germany along with Amirali Sanatinia, a PhD student who also participated in the research.
The research is only the latest indication that Tor can’t automatically guarantee the anonymity of hidden services or the people visiting them. Last year, FBI agents cracked open a Tor-hidden child pornography website using a technique that remains undisclosed to this day. In 2014, researchers canceled a security conference talk demonstrating a low-cost way to de-anonymize Tor users following requests by attorneys from Carnegie Mellon, where the researchers were employed. Tor developers have since fixed the weakness that made the exploit possible.
More than 70 percent of the snooping hidden services directories were hosted on cloud services, making it hard for most outsiders to identify the operators. In some cases, the directories didn’t visit honion services immediately. Instead, they waited days before probing the honeypots, most likely in an attempt to remain undetected. In a paper accompanying Friday’s presentation, the researchers from Northeastern wrote:
Most of the visits were just querying the root path of the server and were automated. However, we identified less than 20 possible manual probings, because of a query for favicon.ico, the little icon that is shown in the browser, which the Tor browser requests. Some snoopers kept probing for more information even when we returned an empty page. For example, we had queries for description.json, which is a proposal to all HTTP servers inside Tor network to allow hidden services search engines such as Ahmia, to index websites. One of the snooping HSDirs (5.*.*.*:9011) was actively querying the server every one hour asking for a server-status page of Apache. It is part of the functionality provided by mod status in Apache, which provides information on server activity and performance. Additionally, we detected other attack vectors, such as SQL injection, targeting the information_schema.tables, username enumeration in Drupal, cross-site scripting (XSS), path traversal (looking for boot.ini and /etc/passwd), targeting Ruby on Rails framework (rails/info/properties), and PHP Easter Eggs (?=PHP*-*-*-*-*).