Thwarting Identity Correlation Attacks
Anonymity is hard. Hidden, or Onion, Services allow you to setup services which can hide their location by using the Tor network.
However, on their own, onion services will not protect you. One particular attack vector which has received little attention is that of Identity Correlation attacks.
These attacks involve an attacker gathering information from your service, other onion services and the internet at large in order to find identifiers which can be linked to each other and, ultimately, a real world identity.
Identifiers can be leaked by software misconfigurations, bad defaults and ignoring operational security (by say, publishing your service under a well known handle).
We have compiled this guide to document some of the best practices for securing your onion service against Identity Correlation attacks and protect your anonymity.
1. Only Host 127.0.0.1
This may seem obvious but there are hundreds of onions which expose their services to the clearnet by not explicitly binding to 127.0.0.1.
Failure to do this risks your service being searchable via tools like Shodan, and, if you fail to follow the rest of this advice, makes it trivial for attackers to unmask you.
How bad can it get - In the world case, simply searching for onion address on shodan reveals the real world IP address of the onion service.
2. One Protocol. One Onion
Exposing multiple different servers (e.g. a web server and an ftp server) at the same hidden service address opens up the door for certain kinds of identity correlation attacks.
As an example, two hidden services a.onion and b.onion both have a web server on port 80 and an ssh server on port 22.
While a.onion and b.onion appear to be unrelated, an inspection of their SSH public keys reveals that they are the same - meaning that they are hosted on the same infrastructure.
Had a.onion and b.onion hosted their SSH server on a separate address, we would not have been able to link them in this way.
There are obvious exceptions to this rule e.g. OnionMail servers expose a web server and an SMTP server - it makes sense to associate these two as they are fundamentally related.
However, if the only reason you expose SSH is to manage your server, then there is no need to host it on the same onion address as your website.
How bad can it get - Linking identifiers like SSH key fingerprints with onion web sites can determine co-hosting arrangements or detect groups of sites which are related.
3. Remove Software Banners
When the web was young, people decided that the first thing servers should do when you connect to them is tell you information about themselves.
This often included domain names, IP addresses, operating systems and the software version of the server.
Today, this legacy persists and a large number of software applications still package these banners as default. Common applications with banners include:
- SSH Servers
- FTP Servers
- SMTP Servers
We can also include HTTP Server headers in here too. There is no reason a visitor needs to know whether you are hosting on Apache or nginx or Twister.
If you do host any software which includes a banner, turn it off.
How bad can it get - In the worst case software banners can leak IP address and domain names - although often not by default. However, if your server is running a particular unique software version, this can be searched in Shodan and narrow down the search for a server (in one case we saw Shodan return a single result, which would either indicate a remarkable coincidence or a match on the owner of the service)
4. Steer Away from Apache
By default, most modern web servers are private by default i.e. they have directory listings turned off, and have minimal extensions installed that may leak information.
Apache sadly is often packaged in a way that is the opposite of the above, and most fresh installs include a few modules which are damaging to privacy especially when deployed as part of an onion service.
The most critical of these is mod_status - a module which presents a single page at /server-status containing a number of analytics about the server.
The main defense mod_status has from unauthorized eyes is that it is only available from localhost.
If you've been following along, you might realize the issue - all onion services receive traffic as if it is coming from localhost. The availability of mod_status in this context is an example of a localhost bypass attack, but this attack, although with other Apache quirks, often contains identifiers which can be used to correlate identities.
How bad can it get - At least 12% of Apache hosted onion services have mod_status enabled - leaking server IP addresses, co-hosted hidden services, clearnet visitor IP addresses, user activity and much more.
Maybe use nginx.
5. Be careful who you (don't) link to (and who links to you)
As we demonstrated in the latest OnionScan Report hidden relationships between sites can be detected by analyzing who they link to (and who links to them).
This means that if you have a number of sites that you would like to keep separate from a common identity then it is necessary to ensure that they don't link to each other, share common resources, are linked solely from a few common sites or use the same ad network.
