pseudo-flaw.net

Next week at DEFCON 17, I'll be presenting a talk entitled "Attacking Tor at the Application Layer". The talk is the culmination of several months of new research into application layer and web security issues affecting Tor and associated components.

The material will cover some of the past application attacks as well as current problems that may have an impact on anonymity. Also presented will be new approaches to identifying Tor web traffic, fingerprinting Mozilla Firefox web browser versions and installed applications and browser addons.

In some ways, the content feels like a web app security talk masquerading as a Tor presentation. Although the material is primarily focused on Firefox, a number of the items could have broader applicability to Internet security in general. The topics range from the highly esoteric to the predictably mundane. A few of these are those issues that everyone should know about, but either forgot or doesn't care to deal with.

Over the next few days, I'm going to be posting several items that probably aren't going to make the cut for my talk. Stay tuned.

I've posted an updated version of my Tor hacking utilities. This is a collection of extremely simple scripts that I used for testing from an isolated Tor environment on Linux.

I haven't been actively maintaining this package, but a couple of weeks ago I received an email asking about some difficulties with 'mktorfw.sh' script. The script constructs a Linux iptables firewall based on the list of current Tor routers. It appears that the script hadn't been updated since late 2007 and was still expecting the list of Tor routers to be contained in '/var/lib/cached-routers'. It has been updated to read from '/var/lib/cached-descriptors'.

The 'mktorfw.sh' script can be used to create an extremely restrictive iptables Linux firewall. I found this very helpful when looking for applications that leak network traffic. Some applications don't properly respect proxy settings and can result in anonymity compromise. With this local firewall, any attempts by an application to connect out to a port that wasn't currently a Tor router endpoint was logged and dropped.

The script has two primary modes. The first reads the lists of routers and creates the firewall based on set of router addresses and ports as well as some other necessary rules. The second mode is an update mode that detects changes in the list of routers and updates the corresponding iptables rules.

For example, to create an initial firewall configuration where 'eth0' is the gateway interface:

./mktorfw.sh -i eth0
	

If there are additional local ports that should be allowed, these can specified as well:

./mktorfw.sh -d -i eth0 -l "4443,5553,5533:5539,5041"
	

As Tor routers come and go, the list of routers changes and the firewall needs to be updated to follow these changes. The simplest mechanism to accomplish this is to install the script in a root owned location:

install -m0755 mktorfw.sh libutiltor.sh /sbin
	

and, create a crontab entry to run the update frequently:

*/5 * *   *   *   root  /sbin/mktorfw.sh -u -i eth0
	

Note: the firewall rule-set created by this script was mainly for experimental, research purposes. If you are looking for strong anonymity, a firewall or VPN that transparently proxies your traffic is probably a better solution. The Noreply Wiki has information on a TheOnionRouter/TransparentProxy. Or, if you are on Windows, there is JanusVM.

Download version 0.06 of the Tor Hacking Utils here (sig).

Tor and EFF are once again taking part in Google's Summer of Code (GSOC). See The Tor Project is in Google Summer of Code 2008! post or Work on Tor this summer, get paid by Google.

The volunteer projects page has some great ideas. And the deadline is rapidly approaching (March 31, 2008 at 5pm Pacific Time).

I've always been fascinated by client-side attacks that use the web-browser as a launching pad. Although the networking aspect of anonymity is interesting (and critically important!), the application level attacks seem more practical from a high-level point of view. There is an extremely low barrier entry for an adversary to configure a Tor exit node and start injecting malicious traffic.

Currently, Torbutton is the preferred Firefox plugin for enabling and disabling the use of Tor from within the browser. There has been a large amount of work going into improving the anonymity profile for Firefox users. Ideally, an adversary should not be able to unmask a user by profiling browser attributes or forcing plugins to make direct network connections.

To this end, I've set up a Torbutton testing page that lists several possible attacks. Many of these are fixed in the latest development version of Torbutton. Unfortunately, some require changes in the Firefox browser to achieve the more complete anonymity that many users desire.

Note: this is primarily a resource for developers or researchers.

So, if you are a student who enjoys Firefox, JavaScript and plugin hacking, the "Testing integration of Tor with web browsers for our end users" topic many be a good project to look at. There is still a large amount of research to be done, especially focused on the soon to be released Firefox 3 web-browser.

Tor (The Onion Router) version 0.1.2.19 has been released. Download it here.

The release notes make mention of one security fix:

Exit policies now reject connections that are addressed to a relay's public (external) IP address too, unless ExitPolicyRejectPrivate is turned off. We do this because too many relays are running nearby to services that trust them based on network address.

The fix addresses an issue most recently discussed on the or-talk mailing list. Martin Fink posted a message Security concerns/help me understand tor that raised the issue of cheap home routers that provide access control based on LAN IP address ranges. The basic premise is that if a Tor exit node is NAT'd behind a cheap home router, any ports listening on the LAN side of the router may be exposed to Tor traffic. This situation arises for a couple of reasons.

The first reason is due to nature of Internet routing. In a typical home network, packets destined for the external IP address of the gateway router that originate within the home network will be routed directly to the gateway router. These packets will arrive on the LAN interface even though they are addressed to the external IP address. If the router is performing authorization based on either packet source address or the interface the packet arrived on, it will appear as if this is legitimate LAN traffic. This holds true of any proxy-type systems that are deployed on an internal network but accept traffic from an external source.

The second reason is that Tor attempts to solve the exit node eavesdropper problem by detecting if you going to IP address that also has a Tor exit node running on it. If it detects this situation, Tor will construct a routing path that terminates at that IP address. The OnionRouterFAQ has an entry that describes this:

Tor does provide a partial solution in a very specific situation, though. When you make a connection to a destination that also runs a Tor relay, Tor will automatically extend your circuit so you exit from that circuit. So for example if Indymedia ran a Tor relay on the same IP address as their website, people using Tor to get to the Indymedia website would automatically exit from their Tor relay, thus getting *better* encryption and authentication properties than just browsing there the normal way.

But, that behavior combined with a NAT'd Tor server behind a cheap home router raises an interesting problem.

For example, consider home network router with an external IP address of 77.77.77.77 and an internal IP address of 192.168.0.1, and a Tor server NAT'd at 192.168.0.69. If Tor detects that a web user wants to visit the web page at IP address 77.77.77.77, the onion routing path will be constructed to exit at that IP address. When the Tor server running on 192.168.0.69 receives a packet to be routed to 77.77.77.77, it will treat it just like any other packet to exit. The server will unencrypt it and forward it out. But since the Tor server is NAT'd to 192.168.0.69, when the packet is forwarded to the gateway router, it will be receiving it on the LAN interface. If that LAN interface has a web server listening on it, that web server will respond. What if this is the administrative interface for the router and access restrictions are based on the origin of the packet? Any Tor user (that wanted to) could browser to the admin interface of the router and reconfigure it.

In general, Tor attempts to guard against routers sending locally addressed packets by automatically adding exit policy deny rules for the RFC 1918 address space. The 0.1.2.19 update adds a deny rule to the exit policy for the external IP address of the Tor server. If the old behavior is desired, it would need to be configured manually.

The change is important for those home users who don't understand the intricacies of network routing or use cheap gear that trusts packets based on where they originate. But given the relative prevalence of client-side browser exploits, that trust is probably misplaced to begin with.

I've posted a new version of my Tor hacking utilities. This is a collection of crude scripts that was written to make my life easier when working from an isolated Tor environment. Basically, I got tired of tying together socat pipelines and wrote these scripts to simplify some common tasks.

The 'socks-http.pl' script has been added. It is a command-line utility that can be used to make basic HTTP requests directly over the Tor SOCKS port. Normally, HTTP requests are going to be funnelled through an HTTP proxy such as Privoxy or Polipo. These proxies generally apply a certain set of checks to verify that the HTTP request is valid. But when you need to send invalid HTTP requests, these checks represent a serious problem. And that is where the 'socks-http.pl' script comes in handy.

The socks-http.pl script accepts command line options that are extremely similar to wget:

usage: ./socks-http.pl [options] URI

   make HTTP request via Tor

options:
 -O, --output=<file>             Output (defaults to STDOUT)
 -OO, --output-overwrite=<file>  Output and overwrite
 --referer=<referer>
 -U, --user-agent=<UA>           User-agent
 --host=<host>
 --method=<method>               GET,HEAD,TRACE,etc.
 --debug                         print request
 --socksdebug                    enable SOCKS debugging
 --request=<file>                read request from file
 -S, --server-response           print server response
 --post-data=<data>              send post data
 --post-file=<file>              send post data from file
 --header=<header>               Added HTTP header (can be repeated)
 --url-encode                    URL encode the request PATH
 --help                          Display this help

      

A normal request may appear as:

./socks-http.pl --post-data="user=' or 1=1--%0a" \
	--header="X-Forwarded-For: 127.0.0.1" \
	--header="Cookie: admin=1" \
	'http://example.com/admin/search.cgi'
      

Whereas a malformed request could be sent as:

./socks-http.pl --method='%s' --host='localhost.localdomain' \
	'http://example.com:80http://localhost.localdomain/'
      

Download version 0.05 here (sig) or view the README.

Given all of the recent discussion on the or-talk mailing list about reducing Java leakage in Windows, I thought I'd put together an online Java leakage test page to see what is actually occurring.

Apparently, the latest Sun Java Runtime Environment (JRE 1.6u3) does not use any of the SOCKS proxy values configured through the network settings. Which does not matter really, because there are methods to ignore the proxy settings.

The HTTP URL connection reports the user-agent using its own custom value. The custom JRE user-agent includes the full operating system identifier. For example, instead of the fake user-agent in the latest Torbutton, you see:

• Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_03
• Mozilla/4.0 (Linux 2.6.20-16-generic) Java/1.6.0_03

Another item of interest is that Java 6 introduced new methods to the NetworkInterface class that allow the hardware addresses of all network interfaces to be read. Depending on what type of environment you are in, this could be information that may benefit an adversary.