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).

What I found most refreshing was the proper use of the term 'Threat Model' in Appendix B: Threat Model for the Skilled, Determined Attacker. Too often the term has been abused by some people to label activities better described as vulnerability analysis or attack modeling. The proper focus of a threat model is the agent or actor that could exploit a vulnerability. It was extremely satisfying to see the threat model explicitly described when it is so often glossed over or ignored completely.

The basic premise is that in Wordpress 2.5, an HMAC was used to provide integrity protection for the authentication cookie, but a design flaw allows specially chosen user names to create forged authentication cookies.

The auth cookie allows a user to login without any complicated session management on the server side by storing the user login, expiration time and hash value. A valid auth cookie grants a user the ability to login without any form of password. So, if a forged auth cookie could be generated such that the user login field was "admin", then that given user would have administrative privileges.

The auth cookie value is of the format:

      $user_login . '|' . $expiration . '|' . $hash

where the hash was the HMAC derived from the SECRET_KEY defined in the configuration.

The design mistake was that the HMAC was calculated over the undelimited value:

      $user_login . $expiration

Consequently, an appropriately chosen user name could be registered that would allow access to the admin account by tampering with the cookie.

In order to chose an appropriate user name, the following criteria needs to be met:

1. User name must begin with the string "admin"
2. The expiration must be not be in the past
3. When the user name and password are concatenated, the original value used to calculate the HMAC must be unchanged.

Obviously, the simplest choice for a user name would be "admin0". For example, when the HMAC was initially calculated, the value:

      "admin0" . "1209590828"

would result in a cookie value of:

admin0|1209590828|7863a08bd04af260bd5df2a8bf7e8b33

Then, the cookie is modified by moving the 0 to the expiration field:

admin|01209590828|7863a08bd04af260bd5df2a8bf7e8b33

so that the HMAC is calculated over:

      "admin" . "01209590828"

Since the concatenated strings are identical, the HMAC hash is matched and the user is granted admin privileges.

A simple implementation mistake with serious consequences.

I think this is good news overall. It just didn't seem that the whole concept of cross-site XHR was fully baked. Given the prevalence of cross-domain web attacks, waiting for the specification to settle is probably an excellent idea.

There are security fixes for a couple of vulnerabilities that I was involved with:

• MFSA 2008-18: Java socket connection to any local port via LiveConnect
• MFSA 2008-16: HTTP Referrer spoofing with malformed URLs

I'll be posting some more information about these in the future.

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.

I noticed that there still doesn't appear to be any publically available scripts to import the 'dataloss.csv' into a MySQL database, so I went ahead and bundled up what I had. These scripts are pretty rough and the documentation is limited, so you'll want to look at the source to answer any questions.

You can download the package directly: dldos-db-mysql-0.1.tar.gz (sig). See the README for more information.

Eventually, I'd like to consolidate the scripts into a single utility that could handle the entire import process. Hopefully, what I've posted will be of use to someone.

The page is available from here.

These demonstrations are currently available in Bugzilla, but I wanted to tie them together with some of the other file stealing vulnerabilities. There is quite of list of other Bugzilla entries detailing possible file stealing attacks, some of which reach all the way back to the year 2000.

I find the two demos very fascinating, because they represent failures to fully address a vulnerability. The original vulnerability was related to using the 'focus()' method to set the focus on a label. Unfortunately, not all of the code paths were examined and it was possible to redirect the focus by clicking on a nested label or by programmatically creating and sending a "click" MouseEvent.

• Nested label stealing: Firefox Focus Bug - File Stealing - DEMO (Bug #404391)
• MouseEvent "click" stealing: Firefox Focus Bug - File Stealing - DEMO (Bug #404391)

I will post the second part after I confirm that the other "spoofing" vulnerabilities were fully addressed in Opera.

Included are several important security fixes:

• #233321: Two Security Vulnerabilities in the Java Runtime Environment Virtual Machine
• #233322: Security Vulnerability in the Java Runtime Environment With the Processing of XSLT Transformations
• #233323: Multiple Security Vulnerabilities in Java Web Start May Allow an Untrusted Application to Elevate Privileges
• #233324: A Security Vulnerability in the Java Plug-in May Allow an Untrusted Applet to Elevate Privileges
• #233325: Vulnerabilities in the Java Runtime Environment image Parsing Library
• #233326: Security Vulnerability in the Java Runtime Environment May Allow Untrusted JavaScript Code to Elevate Privileges Through Java APIs
• #233327: Buffer Overflow Vulnerability in Java Web Start May Allow an Untrusted Application to Elevate its Privileges

I'll followup with some additional information on the JavaScript privilege elevation (#233326) after I can do some more testing.

Mozilla notified us of one security issue ( :smile: ) the day before they published their public advisory ( :worried: ). They did not wait for us to come back with an ETA for a fix: they kept their bug reports containing the details of the exploits closed to the public for a few days, and now opened most of them to everybody ( awww ).

This was picked up by The Register and Slashdot as well as numerous personal blogs.

But as best as I can tell, Mozilla has not released details for any of the proofs-of-concept exploits that Opera may be vulnerable to. The samples for the focus shifting bugs don't appear to affect Opera. If Opera is in fact vulnerable to any of the released information, I would be very interested in finding out more about it.

In any case, once the details for Bugzilla #413135 are opened to the public, I will be posting online versions of the sample exploits.