Attacking the onion router

Presented at atlseccon 2015, details on how one would go about attacking Tor users. We include a number of practical and theoretical attacks.

Transcript

1. Attacking The Onion Router The good, the bad and the ugly
2. What is Tor?
3. Each relay has a limited view
4. Tor traffic is detectable • IP addresses of relays known • Use Tor bridge relay • DPI can still find Tor • Obfuscated bridge (pluggable transports) • VPN then Tor?
5. How is that different than a VPN? • Single point of failure • Account information about you • Widely ranging security/privacy/trustworthiness • Non-PFS brittleness to key compromises
6. Hidden Services • The darkweb (scary!) • .onion addresses (16 characters, base32 encoded from 80bit hash of pubkey) • Hidden Service Protocol needs some love – Key length RSA-1024 – SHA1 used for onion hash – HSDir servers can enumerate onions – Scaling issues
8. #torgate • A journalist read wikipedia (pando article) • Funding concerns (EFF, Human Rights Watch, various universities) • 50% non-USG funding goal by 2016 • Tor conspiracy theories (honeypot) • Harassment of developers
9. Tor is not an inside job • The following would need to be in on it: – WikiLeaks (Jacob Appelbaum) – Edward Snowden – EFF – Mozilla • Open Source (I've grep'ed for "backdoor")
10. Leave the NSA alone! • FiveEyes not only game in town – Great Firewall of China – Non-state actors also playing • We use worst-case for a reason • You'll be hacked, probably won't be state actor
12. Hostile exit nodes • Logging traffic • Malicious code injection • Flash proxy bypass • Remedies – end to end encryption – binary signature verification – exit node scanning system? – Isolate tor browser
14. Induced Traffic Correlation • Sambuddho research paper • Works against VPN
16. At Scale Practicality • Incomplete relay visibility at internet scale • end to end encryption (lack of http identifiers) • false positives (99.9% accuracy not enough) • Many exit flows possible inside of same circuit • cover traffic (xmpp, irc, twitter query window)
18. CERT, Carnegie Mellon • Adding number (115) of Tor relays (sybil attack) • Inject signal through "relay/relay early" cells at Hidden Service directory node • Noisy, since unknown entry guard
19. Message in a bottle, and cast it within the sea • Signal used to encode message • Need to control both ends of circuit • Theoretical data structures – HSDir message; identifier, onion address (4+80 channel commands) – Database record of HS lookup; timeStamp, requesting IP, onion address
20. Aftermath • BlackHat 2014 presentation, cancelled! • Who has the database? • Remediation – fixed in 0.2.4.23 – relays banned – detected by DocTor scanner – limit entry guard rotation
21. Can we still use a sybil attack? • Timing attacks between entry and exit node • Most flows will not correlate • No easy fix, adding latency unpopular solution • Mitigation through limiting entry guard rotation
23. So what does this get me? • Untargeted, we don't get to pick who • Common middle node necessary, but not sufficient • Easier to scale correlations work with parallelism • Instead of single flow, we get EVERYTHING in circuit Where G = percentage of entry guard capacity E = percentage of exit node capacity C = correlation efficiency We can de-anonymize G*E*C of Tor circuits. 0.10 * 0.10 * 0.80 = 0.8 percent 0.15 * 0.15 * 0.85 = 1.9 percent 0.008 * 0.025 * 0.85 = 0.017 percent
24. Can we do better? • Observe all Tor client flows into entry nodes • We lose middle node information
25. Death, taxes and opsec fails • Don't break the law • Don't cross-contaminate identities • Don't use Paypal to sell drugs • Bitcoin only pseudo-anonymous • Document Metadata (EXIF, PDF, Office) • Encrypt all of the things • Everyone is Sabu • It's probably your fault you got caught
26. • Follow me @jzsavoie • XMPP jzsavoie@jabber.at • Questions, Angry Rants? "We will never be able to de-anonymize all Tor users all the time."