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.

Now, we get the 0-day Can Happen to Anyone post. The OSVDB WordPress blog was being hacked by SEO spammers that edited spam content directly into the posts. Apparently the blog was being exploited by a real-life, discovered in the wild, 0-day: 41136: WordPress XML-RPC xmlrpc.php Unauthenticated Post Modification.

For reference, the links I saw were:

<noscript>Courtney scott a <a href="http://groups.google.com/group/lynn5052/web/cricket-ringtones">cricket ringtones</a> is not.</noscript>

<noscript>Wiederum im Uhrzeigersinn <a href="http://www.kasino007.de">gratis casinospiele</a> jeder Boxinhaber dann sein Online Blackjack Blatt zu Ende.</noscript>

Interesting stuff.

It is a step-by-step walk-through of how the vulnerability was located in the patch, the analysis applied to determine the flaw and finally how the exploit was developed. An informative and interesting read if you are into that sort of thing.