Skip to content

Tor

Jump to bottom
0xACAB edited this page Apr 17, 2020 · 14 revisions

Wiki ▸ Tor

Tor ("the Onion router") is an anonymizing overlay network known as a mix network (or "mixnet" for short). It sits in between your application(s) and your network connection, providing an extra layer of protection between your (self-hosted) services and the public Internet (or "clearnet"). Tor is useful for privacy-enhanced communication, cryptographic naming services (through its Onion service or “hidden service” features), and firewall traversing (NAT punching) capabilities.

Tor is often used by red teamers (attackers) to help obscure their true location from discovery by blue teamers (defenders). It is not a foolproof tool, however. This page offers a cursory treatment of valuable resources related to attacking Tor users, whether human (end users) or machine (servers).

  1. De-anonymization attacks
    1. De-anonymizing Onion sites
      1. Address disclosure
        1. Apache mod_status leak
      2. localhost bypass attack
      3. Correlation attack vectors
        1. Software fingerprinting
          1. SSH fingerprinting
    2. De-anonymizing Tor end users
      1. Operator errors
        1. nmap over Tor
  2. Tools

De-anonymization attacks

Since the purpose of Tor is to prevent the discovery of a machine's true IP address (i.e., network anonymity), an important class of attacks against Tor users is de-anonymization. Generally speaking, Tor users are either end users or server operators. End users are humans using Tor via, for example, the Tor Browser. Server operators (aka "system administrators" or "sysadmins") are humans who manage the machines to which end users connect using the Tor Browser. For the purposes of discussing attacks on Tor, these machines are known as Onion services (formerly "hidden services").

While a common set of techniques can be used to de-anonymize both Onion services and Tor end users, the mechanisms by which these techniques are employed differ between these two use cases. In general, de-anonymization techniques include:

  • Information disclosure: when a service or user inadvertently discloses their true network address or other identity in a way that is detectable by an attacker.
  • Correlation vectors: when, through normal operation, a service or user publishes a distinguishing set of characterstics such as Bitcoin addresses, software banners, SSH key fingerprints, or other information across a range of interactions or services.

This section describes various de-anonymization vectors and provides examples of their use.

De-anonymizing Onion sites

Address disclosure

The simplest method of de-anonymizing a hidden service is to induce the server to reveal its identity (or address) to you. Numerous common information disclosure vectors can be utilized to this effect.

Apache mod_status leak

If the Onion service runs an Apache HTTP server, check for a page generated by the mod_status module. By default, if enabled, this page will be published at the /server-status path on the Web server. Simply by visiting http://host.onion/server-status may reveal the server's clearnet IP address, along with other information.

As of 2017, approximately 10% of Onion Web sites running on Apache can be deanonymized this way.

localhost bypass attack

🚧 TK-TODO

Basically, send a header like Host: localhost or Host: 127.0.0.1 to an HTTP server running behind an Onion site and you sometimes get an HTML page which includes everything you need to know to figure out who is running the service. Oops. :P

This can also be performed the other way around: send a Host: some.onion header to a clearnet IP address or domain name, and see if it returns a page for the given Onion site.

Correlation attack vectors

Correlation de-anonymization attack vectors rely on the ability to observe information that is unlikely to be reproduced by different entities. For example, an SSH server's host key fingerprint is likely unique across all SSH servers, making it possible to correlate co-located Onion services, or de-anonymize them, if both Onions and/or the clearnet SSH service share the same SSH key fingerprint. Any observable identifying charactersitic can be used as a correlation data point, such as:

  • BitCoin addresses
  • Google Analytics user IDs
  • HTTP response header strings, such as Server, X-Powered-By, etc.
  • TLS certificate data
  • FTP, SMTP, or other server banners
  • more…?

Software fingerprinting

Software fingerprint correlation de-anonymization attacks work by observing or deducing specific software running on the target Onion service and correlating this information with the software running on another Onion or a clearnet server address. If the software can be fingerprinted uniquely enough and then matched to other Onions or clearnet servers running the same software, you can be increasingly confident that you have found either shared Onion infrastructure or the clearnet identity/address of the service.

SSH key fingerprinting

SSH services are typically used to provide remote login to GNU/Linux machines for an .onion address. If the same SSH service is offered on a public IP address, as well as through an Onion service, this will lead to uncovering the IP address of Tor’s hidden service. The following represents a demonstration of this deanonymization technique:

  1. Make an SSH connection to the Onion service (using torsocks(1) to "torify" the ssh connection), and note the server's fingerprint: 
    $ torsocks ssh root@msydqstlz2kzerdg.onion
The authenticity of host 'msydqstlz2kzerdg.onion (127.42.42.1)' can't be established.
RSA key fingerprint a7:93:84:a6:97:fa:25:65:77:c9:58:bb:fe:8e:e2:2f
Are you sure you want to continue connecting (yes/no)?
  2. Now make an SSH connection to the clearnet service you suspect of being the same server, and again note the server's fingerprint: 
    $ ssh root@ahmia.fi
The authenticity of host 'ahmia.fi (46.19.38.63)' can't be established.
RSA key fingerprint a7:93:84:a6:97:fa:25:65:77:c9:58:bb:fe:8e:e2:2f
Are you sure you want to continue connecting (yes/no)?

In the above example, the two domain names (msydqstlz2kzerdg.onion and ahmia.fi) can be reasonably assured to be the same machine because their SSH server is using the same RSA private key. The IP address for the clearnet service (46.19.38.63) is almost certainly the true IP address of the Onion service.

Internet census databases or search engines such as Shodan.io and Censys.io can be used if you have no or few suspect clearnet servers to test.

De-anonymizing Tor end users

🚧 TK-TODO: EXIF metadata in images that a user has posted…

Operator errors

In certain scenarios, Tor is a difficult tool to use correctly. For example, without the use of a strict isolating proxy (e.g., Whonix), applications may still reveal the end user's IP address, contrary to the expections of the user, even when the user believes they have configured their application to use Tor. One oft-cited example is in BitTorrent use, a scenario in which there are many BitTorrent client applications that do not strictly obey proxy settings in many common scenarios. Another is the infamous "DNS leak," in which an application first requests the IP address of a domain name entered by the user over a clearnet connection, and then obeys the configured proxy setting for the actual data transfer.

Although perhaps technically less interesting, this class of Tor end user deanonymization is potentially the largest simply because of how many uneducated Tor users use the software incorrectly. This section aims to provide some guidance for how to spot (and stop) these operator errors.

nmap over Tor

As of this writing, the popular network security tool nmap does not fully support proxies. In part, this is simply because proxy-supporting features are incomplete. However, a lot of nmap's functionality is incompatible with certain types of proxies, including Tor, by its nature. For example, the -PE flag instructs nmap to use ICMP echo requests for its host discovery phase. Since ICMP is not TCP, using a TCP-based proxy such as Tor with this option would never succeed, and all targeted hosts would be reported as down.

In order to use nmap over Tor, which only supports the TCP protocol, the following restrictions apply to nmap use:

  • Any scans must be established using a full TCP handshake; use the -sT flag to indicate TCP connect scanning. Other scan techniques (e.g., -sU, -sO) will not reach the target because they will not be proxied.
  • Host discovery must use a TCP-based "ping" option or it must be disabled entirely; to perform a TCP-based host discovery "ping," use the -PS (Ping with TCP SYN) or -PA (Ping with TCP ACK) options, optionally specifying a port number (e.g., -PS443 for a TCP SYN ping aimed at port 443). Alternatively, skip host discovery entirely by specifying -Pn.
  • Name resolution should be disabled, or else nmap must be instructed to use Tor's configured DNSPort for DNS resolution; use the -n flag to disable DNS requests, which also means you must supply an IP address (not a domain name) in your nmap target hosts list, or use the --dns-servers option to specify a custom DNS server (likely --dns-servers 127.0.0.1). Note, however, that there is no option to configure which port nmap should use to contact the DNS server at the given IP, so you may either need to bind Tor's DNSPort to port 53 or else set up a port forwarder, e.g., sudo socat UDP-LISTEN:53,fork UDP:127.0.0.1:5555, assuming 5555 is where your DNSPort is listening. Note that disabling nmap name resolution does not impede Onion service lookups, since .onion domains do not actually have real IP addresses anyway.

All the above restrictions have serious implications, the upshot of which is that someone who attempts to port scan "anonymously" using Tor (without the use of an isolating proxy or a correctly configured outbound firewall) but who fails to take into account the full and complete behavior of nmap given the options they passed can very easily accidentally leak their IP address to the target directly, or to the DNS via DNS requests regarding the target, simply by invoking nmap less than perfectly carefully.

A minimal working example of a successful nmap TCP port scan for the default ("top 1,000") ports over Tor (in this example, using torsocks) would look something like this:

torsocks nmap -Pn -n -sT whatever.onion

Tools

See awesome-tor.

References

See also: 🌐 Favorite conference talks.

Clone this wiki locally