A Logo

Feel free to include my content in your page via my
RSS feed

Help Irongeek.com pay for
bandwidth and research equipment:

Subscribestar or Patreon

Search Irongeek.com:

Irongeek Button
Social-engineer-training Button

Help Irongeek.com pay for bandwidth and research equipment:


Cipherspaces/Darknets: An Overview Of Attack Strategies (Hacking Illustrated Series InfoSec Tutorial Videos)

Cipherspaces/Darknets: An Overview Of Attack Strategies

Darknets/Cipherspaces such as Tor and I2P have been covered before in great detail. Sometimes it can be hard to follow attack strategies that have been used against them as the papers written on the topic have been academic and abstract. What this talk will attempt to do is step back and give an overview of the topic in a manner hopefully more conducive to the understanding of security practitioners, giving more concrete examples. While little to nothing in this talk will be "new and groundbreaking" it should lead to a better understanding of how encrypted anonymizing networks can be subverted to reveal identities.

Download Slides

Defcon 19 Live Version:


Canned Version:

Download Video:

Text from presentation:

Cipherspaces/Darknets: An overview of attack strategies
Adrian Crenshaw
About Adrian
   I run Irongeek.com
   I have an interest in InfoSec education
   I don’t know everything - I’m just a geek with time on my hands
   (ir)Regular on the ISDPodcast
   Researcher for Tenacity Institute
A little background…
   Darknets: There are many definitions, but the one I’m working from is “anonymizing networks”
   Use of encryption and proxies (some times other peers) to obfuscate who is communicating to whom
   Sometimes referred to as Cipherspace
(I love that term)
   Tor and I2P will be my reference examples, but there are others
…and some notes
   Things get subtle
   Terms vary from researcher to researcher
   Many weaknesses are interrelated
   Other anonymizing networks: Morphmix/Tarzan/Mixminion/Mixmaster/JAP/
   Focus on Tor and I2P for illustrations when needed
   Academic vs. real world
Threat Model and Adversaries matter
   Threat Model: You can’t protect against everything!
      Some protocols may be lost causes
      Users may do something to reveal themselves
      Does an attack reveal the Client/Host or just reduces the anonymity set?
   Active vs. Passive attackers
   Location, Location, Location:
      Internal vs. External
   Adversaries: Vary by power and interest
      Nation States
      Western Democracies vs. Others
      Government agency with limited resources
      ISP/Someone with a lot of nodes on the network
      Private interests groups (RIAA/MPAA)
      Adrian (AKA: Some shmuck with time on his hands)
Tor: The Onion Router
   Layered encryption
   Bi-directional tunnels
   Has directory servers
   Mostly focused on out proxying to the Internet
   More info at https://www.torproject.org 
   Unidirectional connections: In tunnels and out tunnels
   Information about network distributed via distributed hash table (netDB)
   Layered encryption
   Mostly focused on anonymous services
   More info at http://www.i2p2.de/ 
I2P Encryption Layers
   EIGamal/SessionTag+AES from A to H
   Private Key AES from A to D and E to H
   Diffie–Hellman/Station-To-Station protocol + AES
Silly Garlic Routing
Un-trusted exit points
You are only as anonymous as the data you send!
Mostly Tor centric:
   Is the exit point for traffic looking at the data?
   Traffic may be encrypted inside the network, but not once it is outbound!
   Dan Egerstad and the “Embassy Hack”
   Tons of passwords sent via plain text protocols (POP3/SMTP/HTTP Basic/Etc)
   Moxie Marlinspike did something similar with SSLStrip
Do you trust your exit node?
   Tor is for anonymity, not necessarily security
   Use end-to-end encryption/Don’t use plain-text protocols
   Plain text protocols that send usernames/email addresses in the clear are not very anonymous now are they?
DNS Leaks, Other Protocol leaks and application layer problems
   Does all traffic go though the proxy?
   DNS Leaks are a classic example
   Badly configured proxy setting could lead some types of traffic to go elsewhere (outside of cipherspace)
   Snooper can use web bugs to figure out your location
   HTTPS is a good example, but plugins can also be an issue
   Application level stuff in general is a problem
   Javascript is just hosed as far as reducing you anonymity set
See: Gregory Fleischer, DEFCON 17: Attacking Tor at the Application Layer
DNS Leaks
Mitigating DNS Leaks
   Sniff for traffic leaving your box on port 53. The libPcap capture filter:
port 53
should work in most cases.
   In Firefox, under about:config set network.proxy.socks_remote_dns to true
   Torbutton should help
   Other applications vary
   May have to firewall off 53 in some cases
   May want to edit torrc, and add:
DNSPort 53
AutomapHostsOnResolve 1
Then set your box’s DNS to point to
Grabbing content outside of the Darknet
Slightly Related: Cookies/Supercookies/Etc
Make hidden server contact you over public Internet
Another example, Bittorrent Issues
Yet Another Example:
IRC Ident
General Mitigations
Client wise:
   Make sure your browser is set to send all traffic though the darknet, or none at all
   Look into firewall rules
   Limit plugins used
   Use a separate browser
   Check against:
Hidden server wise:
   Patch your stuff
   Don’t run on a box that routes to the Internet
Attacks on centralized resources/infrastructure attacks/DoS attacks
   Not so much against individual nodes, but the network in general
   Whole bunch of categories, not comprehensive:
      Starvation attacks
      Partition attacks
   Standard DDoS attacks against resources inside and outside of the network (if going though the network) are likely to be soaked by other peers
   Shared known infrastructure can be a problem
   Total (or at least severe) blocking of the Internet
   China blocked access to the core directory servers of Tor on September 25th 2009
   Other blocking of Internet access. (Egypt, Libya, Iran)
DoS of directory servers
   Bridge nodes (Tor)
   Distributed infrastructure (I2P)
      Taking out dev site would still be an issue
   Distributed Hash Table
   Protocol obfuscation
   Total/Severe blocking will take a bit more:
(see next slide)
Mesh/Store and forward
For more info on mesh networks
   Needs a clear front runner for setting up such a system
   Wikipedia if nothing else
   Village Infrastructure in a Kit-Alpha (VIKA) Project
   U.S. Underwrites Internet Detour Around Censors
Clock based attacks
   Some protocols allow you to check the remote system’s clock
   Clock difference could be an issue
   Major difference are easy to spot
   Minor clock issues may need statistical analysis
   For skew, see:
Steven J. Murdoch, "Hot or Not: Revealing Hidden Services by their Clock Skew"
University of Cambridge, Cambridge, 2006
   I2P Clock differences in I2P
Clock Issues
Clock Differences
   Attack can be hard to pull off because of network jitter
   Set clocks with a reliably and often used NTP server
   Some mitigation may take place in the darknet protocol itself
Metadata in files
   Metadata is data about data
   Just a few files types that contain metadata
EXIF (Exchangeable image file format)
IPTC (International Press Telecommunications Council)
      Too many to name them all
   Things stored: User names, edits, GPS info, network paths, MAC addresses in odd cases. It all depends on the file format.
Incidents: Pwned by Metadata
   Well, clean out the metadata, duh!
   Apps vary on how to do it
local attacks
(at this point, it is already probably a lost cause)
   If they have access to the local box, your hosed
   Comes down to mostly traditional forensics
      Data on hard drive
      Cached data and URLs
      Memory Forensics
   Live CD/USB, but see Andrew Case’s work:
   Full hard drive encryption
Sybil attacks
Sock puppetry
   Ever heard of Sybil attacks?
   Think sock puppet, one entity acting as many
   May allow for control of routing, elections, etc.
   Makes many of the other attacks easier
Sock puppetry/Sybil
No absolute fixes
   Make it cost something to have nodes (hashcash)
   IP restrictions:
Both Tor and I2P restrict peering between IPs on the same /16
   Central infrastructure may be more resilient against Sybil attacks (but has other issues)
   Peering/Profiling strategies
Traffic Analysis Attacks
First/Last in chain attacks
Tagging attacks
Timing attacks
   There’s much focus on this in academia, but I imagine application layer flaws are more likely to snag someone
   So many subtle variation on profiling traffic
   Could be:
      Timing of data exchanges
      Amount of traffic
      Tagging of traffic by colluding peers
   Generally takes a powerful adversary
   Hard to defeat in “low latency” networks
I2P one-way tunnel mesh network: Logical view
I2P one-way tunnel mesh network:
ISP view
End point and exit point
Timing Correlation
   More routers
   More cover traffic
(smaller needle in a larger haystack)
   Entry Guards for first hop
   One way tunnels
   Short lived tunnels may help
   Better peer profiling
   Signing of the data
   Fixed speeds
   Padding and Chaff
   Non-trivial delays and Batching
Intersection/Correlation Attacks
   Could be as simple as knowing who is up when a hidden service can be accessed
   Techniques can be used to reduce the search set
   Application flaws and information leaks can narrow the anonymity set
   Harvesting attacks
Cut down needed checks
   More nodes
   Give less data that could be used to reduce the anonymity set
   Make harvesting/scrapping attacks harder
   Checkout “De-anonymizing I2P” paper and talk I’ll link to later
   Selected Papers in Anonymity
   I2P’s Threat Model Page
   General Darknets Talk
   De-anonymizing I2P
   Conference organizers for having me
   Tenacity for helping get me to Defcon
   By buddies from Derbycon and the ISDPodcast
   Open Icon Library for some of my images
   DerbyCon 2011, Louisville Ky
Sept 30 - Oct 2
   Louisville Infosec
   Other Cons:


Printable version of this article

15 most recent posts on Irongeek.com:

If you would like to republish one of the articles from this site on your webpage or print journal please contact IronGeek.

Copyright 2020, IronGeek
Louisville / Kentuckiana Information Security Enthusiast