pseudo-flaw.net

The OWASP Top Ten Project has released a final version of the Top Ten for 2010.

In this new version, the focus has shifted to become more risk oriented. There is less emphasis on "vulnerabilities" and a greater focus on identifying meaningful risk. Risk is identified by utilizing a methodology that explicitly calls out threat agents, attack vectors, weakness prevalence, technical impact and business impact.

For 2010, the OWASP Top 10 Web Application Security Risks are:

• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards

The final document is available from:

• OWASP_Top_10_-_2010.pdf (Google Code)
• OWASP_Top_10_-_2010.pdf(Google Docs)
• OWASP_Top_10_-_2010.pdf (local mirror)

Personally, I'm glad to see the return of a misconfiguration category (A6: Security Misconfiguration). This is a reprise of the old Insecure Configuration Management from the 2004 version. The failure to provide secure configurations is a more frequent problem than many people like to admit.

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

Today, the CWE - 2009 CWE/SANS Top 25 Most Dangerous Programming Errors list was released. These top twenty-five CWE entries represent the most important vulnerability categories that all application developers should be aware of. Think of it as a OWASP Top Ten that covers more than just web applications. The existing Common Weakness Enumeration is outstanding but overwhelming. By framing the programming errors in terms of a Top 25, these issues become instantly more accessible. In turn, this establishes a de-facto application security baseline.

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.

Steven J. Murdoch has a great post about an admin cookie authentication bypass in WordPress 2.5. It provides an instructive look at how simple it is to improperly implement cryptographic functions.

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.

According to this Bugzilla entry, Bug 424923 - Remove Cross-Site XHR, the Cross-Site XMLHttpRequest (XHR) support has been removed from Mozilla Firefox 3. Mike Shaver made brief mention of this in his latest blog post.

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.

Mozilla Firefox 2.0.0.13 has been released. See the release notes for more information.

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.

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.

I've been a big fan of Attrition.org's Errata: (DLDOS: Data Loss Database - Open Source) data set for a long time. When I first started working with it, I wanted something more friendly than just the straight CSV file to crunch. As a result, I created a very simple MySQL schema to hold it and wrote some simple bash scripts to get the data imported. It got more complicated following an aborted Ruby on Rails project due to the addition of reference tables for id values and data type checks.

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.

I've posted the first part of the demonstrations for the Mozilla Firefox file stealing vulnerabilities discussed in MFSA 2008-02: Multiple file input focus stealing vulnerabilities.

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.