Detect Tor Exit doing sniffing by passively detecting unique DNS query (via HTML & PCAP parsing/viewing)

[fpietrosanti]

This ticket is to detect Tor Exit doing sniffing by passively detecting HTML link/url/js/css parsers & viewer by unique DNS.

The idea is to generate HTML content over HTTP that contain in several tags (link, url, js, css, image inclusion, etc) URIs that point to a specific DNS entry, done for that specific Tor exit, that if loaded will enable to detect passively a sniffer.

The idea is that a sniffer, after it store the data, will have some piece of software processing it automatically and/or at a later stage a viewer component of a sniffer software that will enable the "sniffer operators" looking at the "sniffed data" to see an offline copy of the traffic.

If the software processing the sniffed data with HTML content or the viewer will try to load any external resources, not present in the traffic sniffed, it will trigger a DNS request.

A sub-domain with a wildcard such as *.testme.domain.org could be configured so that all requests will go that specific DNS where a DNS server with logging (or some custom Twisted DNS server code) is enabled.

When scanning Tor exit with fingerprint XXXX1234, all the URIs included in the HTML content being transmitted could be XXXX1234.testme.domain.org .

Whenever a dns resolution query would come to XXXX1234.testme.domain.org is surely because some piece of software sniffed traffic on Tor Exit XXXX1234 and then processed it.

The DNS hostname used, could also include a "timestamp" to know when it has been sniffed, and by looking and timestamp when the DNS query has been received it's possible to know when the HTML content has been processed and/or viewed.

HTML content could be transported also over other protocols, such as POP3/IMAP with RFC822/MIME format or FTP by downloading and/or uploading an HTML file somewhere.

[fpietrosanti]

Thinking about it, it would be also possible to extend this concept to detect who does sniffing with tcpdump by saving traffic to a pcap, then reading it at a later stage without using "-n" parameters, triggering DNS reverse query on the IP address contained in the PCAP.

By generating traffic destinated to a netblock, on which we are authoritative for reverse PTR DNS zone, we could get those dns query.

A quick testing show tcpdump making DNS reverse query when reading a pcap without -n parameter:

sniff some traffic to sux.pcap

root@demo:~# tcpdump -nvvv -s0 -w sux.pcap
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C4 packets captured
4 packets received by filter
0 packets dropped by kernel

start logging dns query with another tcpdump

root@demo:~# tcpdump -nvvv -s0 port 53 &
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
[1] 22022

now read the pcap just saved

root@demo:~# tcpdump -r sux.pcap | head -4
reading from file sux.pcap, link-type LINUX_SLL (Linux cooked)
18:36:12.359623 IP (tos 0x0, ttl 64, id 13969, offset 0, flags [DF], proto UDP (17), length 71)
194.150.168.64.52531 > 194.150.168.168.53: [udp sum ok] 13360+ PTR? 38.218.33.41.in-addr.arpa. (43)
18:36:12.359689 IP (tos 0x0, ttl 64, id 41498, offset 0, flags [none], proto UDP (17), length 113)
194.150.168.168.53 > 194.150.168.64.52531: [udp sum ok] 13360 q: PTR? 38.218.33.41.in-addr.arpa. 1/0/0 38.218.33.41.in-addr.arpa. [23h59m16s] PTR host-41.33.218.38.tedata.net. (85)

We see that tcpdump make dns reverse query while reading the PCAP file, so that kind of DNS-based passive sniffing test could be extended also to detect this scenario.

[loganaden]

so, you are proposing to use lipcap to do that ?

[NullHypothesis]

That's a good idea. One issue is that we won't be able to attribute sniffing to an exit. It could also be an upstream entity, but that's true for most exitmap modules. This idea will also require some glue code (e.g., to analyse the pcaps) to automate this experiment as much as possible; if we have to do stuff manually, nobody will run this continuously.

I probably won't implement this myself in the near future, but I'm happy to review and merge code if anyone wants to tackle this.

[meejah]

(Hopefully, one can reply to these via email and have them appear on
github.com)

Tangential to this, somewhat, I think even for "might be an upstream
problem", an honest exit operator would be happy to receive a
(friendly!) email telling them about the sniffing/cencorship/etc while a
dishonest exit operator may, optimistically, re-think their poor
behavior if they are made aware it's being noticed.

It's also a net win for "the Tor network" either way to BadExit such
relays after giving them a chance (e.g. some timeframe) to reform their
ways...? Especially if no response is forthcoming from the operator...

[fpietrosanti]

I think that a KISS principle for implementation is a must for early testing, that means "stateless" application that does a sequence of actions (triggering the tor-exit-testing, processing inbound dns query, sending an email alert at first to an internal email alias).

It could maybe be "prototyped" with some shel scripting or maybe minor tor exit-map tweaking.

INFRASTRUCTURE
The infrastructure maybe done as follow:

• 1 VPS
• A domain name
• A small IP netblock (4 IP) with authoritative DNS reverse/PTR authority delegation
• An HTTP server to receive inbound HTTP request
• An email account to send out notifications

SOFTWARE

• A DNS Servers with query logging feature (Bind or other lightweight solutions. Twisted provide dns server it as a module, but it require coding)
• A Log parsing scripts for DNS query log file that check if there's something being logged as $FINGERPRINT.testme.domain.org or 4.3.2.1.in-addr.arpa reverse, then sending an email with the content of the log
• An HTML template file with variables inside "$FINGERPRINT" that can be easily changed with sed
• A Webserver (thttpd) with a CGI that does return the HTML, by changing $FINGERPRINT" content with a fingerprint= HTTP parameters
• A "crontabb'able" script with torsocks + curl scripts that does HTTP request to the IP of the HTTP server going trough all the Tor Exit relays once every 24 hours, logging to a text file basic data on all the requests it does (for later processing if a DNS-alert trigger)

That way it could be possible to make a relatively quick prototype, without writing python application code (that's my analysis because i'm a unix man, scripter, definitively not a skilled coder!)

[fpietrosanti]

Usage of DNSPot (https://github.com/jekil/UDPot) would be a nice way to log inbound DNS query, instead of a full DNS Server with log parsing:
"The idea behind this script is to provide a DNS honeypot which logs all requests to a SQLite database and with a configurable interactivity level." Howto https://jekil.sexy/tools/homemade-custom-interaction-dns-honeypot