Trac Cookie Revocation

Last week there was some spam posted to the WordPress core bug tracker. The accounts involved can easily have their access to WordPress.org blocked and their passwords changed to invalidate the cookies used to access the WordPress.org forums. This also stops them from logging into the bug tracker again. However, the trac_auth cookie — the cookie that Trac uses to authenticate a browser to a particular user account after valid login details are provided — is not tied to a user’s password; instead the cookie stores a random string that can be verified against the auth_cookie table in the Trac database. This means that until this cookie expires, when the user closes their browser or 10 days after initial sign-on, the spammer is able to remain authenticated to their WordPress.org profile on core.trac.wordpress.org and can continue to post their spam on the bug tracker.

So, because I was curious (and I had to find something to do other than revision for a machine learning test on Tuesday), I decided to write a short Trac plugin to allow a TRAC_ADMIN user to revoke user cookies. The plugin registers a new administration panel and provides the HTML template for its display. The new panel is just a simple form with a single input for entering the target’s username. After the form is submitted the plugin handles the POST request to delete the row in the auth_cookie table which matches the given name. On future requests to the Trac instance the value stored in the user’s trac_auth cookie will no longer match an entry in the database and so the user will not be authenticated.

Revoking a trac_auth cookie

The code can be found on github. Currently the master branch and the 0.1 tag can be run with Trac versions greater than 0.12 whilst the develop branch contains a small update to make use of enhancements to the Trac database API in the unreleased Trac 0.13.

I found the process of writing a Trac plugin to be quite interesting and fun. Using my (basic) python knowledge again was a good experience too. I already have a project lined up which requires a Trac plugin to be developed, so this was also a nice, easy way to set up the necessary development environment in advance and get myself acquainted with the API.

Posted in Code | 1 Comment

One year in core

A year ago today was the first time that one of my patches was accepted into WordPress core. Just a few days after submitting my first patch and opening my first ticket.

In the past twelve months I have submitted hundreds of other patches and been involved with a few other projects outside of the core. I have also helped it with, if not been one of the causes of, the past four security releases — sorry folks.

It has been truly amazing to be involved with the community and to know that I have helped make software that is used by millions daily. It is also the first time that I can honestly say that I was glad to have had revision to do. In trying to procrastinate and put off doing said revision I decided to contribute to an open source project. I chose WordPress.

My goals for the second year? Firstly to be more involved with the WordPress community; for starters I need to attend my first WordCamp as I feel that I have really missed out on that front so far. Second, to help get more people contributing to the project. This is currently taking the form of being a GSoC mentor this year (don’t worry I’ll return as a student another time!). Last, and definitely not least, to continue contributing as much as I can to WordPress. This means many, many more patches as well as finding the time to work more on the WordPress API reference.

Posted in WordPress | 5 Comments

Announcing Exploit Scanner 1.0

With the launch of WordPress 3.1 — actually slightly delayed by bug hunting — I am pushing Exploit Scanner version 1.0.

Summary of main changes:

  • diffs of modified core WordPress files
  • File hashes for WordPress 3.1
  • Updated malicious pattern signatures

Core file diffs

The major feature delivered with the new release are diffs of core file changes. This allows you to easily see how a modified file has been changed from the original and identify any malicious code that has been introduced.

These diffs are powered by the same engine that runs the compare revisions feature in WordPress; that is Text Diff from The Horde Project and PHP PEAR.

Understanding the output is relatively simple. First of all the pretty colours quickly show you what has been added or removed from the file in question. Red indicates content that has been removed from the original, unmodified core file. Green highlights lines that have been added to a file. There are also reference numbers along with ‘change commands’ detailing the line numbers affected. There are three of these change commands:

  • lar — Add the lines in range r of modified file after line l of the original file.
  • fct — Replace the lines in range f of the original file with the lines in range t of the modified file.
  • rdl — Delete lines in the range r of the original file; line l is the line where they would have appeared in the modified file if they had not been removed.

This feature works by retrieving the unmodified source file from the WordPress subversion repository and comparing it to the local file using Text Diff. Unmodified sources are cached in the database to reduce HTTP requests and (minimal) extra load on the WordPress.org servers.

Plans for the future

Bug fixing and continued core hash updates as usual. Unfortunately people still seem to encounter problems when running scans, but I never seem to be able to reproduce and pinpoint how the error is occurring. 1.0 adds some error catching code to help track this.

wp-config.php tracking. Changes to core files are easily spotted with checksums and the new diffs feature, but the all important wp-config.php file is not tracked. This probably would not be limited to just the config file, but could be extended to all files that make up your WordPress installation (i.e. plugins, themes, etc.) and would allow you to detect any modifications made from a known clean state à la AIDE.

Over the air signature updates and patches are really interesting to me. I have been toying with the idea providing (semi-)automatic updates to the malicious code signatures and even core patches for security vulnerabilities — though the latter may best be left to the VaultPress team (sidenote: is there going to be a public release of the plugin at some point?). This is the least likely update for the near future and would most probably be an optional feature as it would involve pinging an update server. A pipe dream for now.

Let me know if there is anything you would like – or not like – to see in future versions of Exploit Scanner.

Posted in Security, WordPress | 3 Comments

Road to WordPress 3.1

WordPress 3.1 is finally here!

Of the new features that arrived today, a few of my favourites are:

  • Internal linking
  • Improved WXR import/export (well it had to be on my list)
  • Admin bar, just because of the awesome Debug Bar plugin

The following is a visualization of all the commits made to WordPress up until the release of 3.1:

The video was made using Gource on a checkout of the whole WordPress repository using the following commands.

`gource --log-command svn` > svn.log
gource --user-image-dir gravatars --disable-progress --stop-at-end --highlight-users -s 0.1 --date-format '%A, %e %B %Y' --output-ppm-stream - svn.log | ffmpeg -b 3000K -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -vpre medium wp-gource.mp4

Unfortunately the commits appear to lose sync with the date. There are only four commits in the log for 23 February 2011, but the video shows some from a few days before. However since it took so long to create the video the first time I was not going to try again!

Time to start work on 3.2!

Posted in WordPress | 10 Comments

Password reminders or: How not to instill confidence

Please do not do this:

Password reminder email

Either send me a random string and tell me to change it once successfully logged in (not great), or send a link to allow me to save a new secret password.

Definitely do not let me believe that my password is being stored in plain text in a database (which is what this situation indicates), instead of being stored after the application of a one-way hash function with salting and stretching.

Posted in Security | 1 Comment

Why exams suck

You may know that the hours of missed sleep and prolonged concentration lead to total mental exhaustion, but the real reason that exams suck is because…

I had to miss #wptybee for five of them.

Posted in WordPress | 4 Comments

Drupal 7: Secure password storage by default at last

With the release of Drupal 7 today we see the arrival of secure password storage by default (as well as many other great new features and changes). Obviously secure password storage in the database is essential for any web application. The most recent high-publicity example of weak password storage was the Gawker break in; thousands of users had their passwords recovered from the DES hashes and, as we know, these are likely to be passwords used everywhere. Previous versions of Drupal have simply been storing the MD5 hash of a user’s password in the database. But why is this dangerous?

MD5 is a cryptographic hash function and so it should be infaesible to find a plaintext for a given hash. However, there are two main problems with a simple application of MD5 when storing passwords. (Both unrelated to known weaknesses, such as collision attacks, in MD5.)

The first problem is that it is easy to precompute MD5 hashes for a vast number of input strings and store these in a rainbow table. Such a table can then be used to quickly lookup a hash and find the original password. The example figures given by the RainbowCrack project suggest that a match can be found for a 7-character password made up from the original 95 ASCII characters, e.g. “@dtE]e~”, in under 10 minutes on an average desktop machine using a 64GB table.

The (very old) fix for this is to salt password hashes. This is done by generating a small, random bit sequence, this is the salt, and adding it to the password before it is hashed. The salt is then stored as plaintext along with the password hash. Now the application can still verify a submitted password, but it has made the use of rainbow tables impractical. For example, a small salt of length 16-bits has 216 = 65,536 different variations, each of which has to be computed and added to every single possible password (of which there are already billions) to build a rainbow table of the same usefulness. That 64GB table now has to become unconceivably big to be of any effective use against moderately strong passwords.

Second problem: MD5 is a quick function to compute (one of the desired features of cryptographic hash functions). So even without a rainbow table it is possible to start trying to brute force a password by generating MD5 hashes on the fly looking for a match. John the Ripper, once patched to crack simple single MD5 password storage, can check the MD5 hashes of approximately 5,720,000 passwords per second on my laptop (2.4GHz Core i5, 4GB RAM). John the Ripper, and other similar tools, make use of time to crack passwords; the amount of time taken depends on the character set or dictionary that is used by the cracker, and even salted passwords can be cracked relatively quickly (2,200,000 passwords attempted per second for traditional-DES crypt passwords).

The solution to this is to use password stretching to increase the amount of time it takes to calculate hash of a password. Instead of running the hash function once it is run for thousands of iterations. This means that to check for a match a cracking tool now needs to run the thousands of hash iterations on each candidate password, thus greatly slowing the progress of the program and diminishing its usefulness.

So, salting and stretching together make a strong solution to password storage. And here to save the day is phpass from solardesigner (also author of John the Ripper), included in WordPress since 2.5 and now (well, quite a while ago actually) in Drupal 7 (though modified to use SHA-512 instead of MD5)…

The MD5 mode, a.k.a. portable hashes mode, of phpass works by generating an 8 character random salt which is prepended to the password and hashing the resulting string with MD5. This process is then repeated for several thousand iterations with the previous hash taking the place of the random salt in the first application of MD5.

$hash = md5($salt . $password, TRUE);
do {
    $hash = md5($hash . $password, TRUE);
} while (--$count);

The whole final hash value is encoded into 16 base64 characters and prepended by an identifying string, the standard phpass MD5 mode uses $P$ (Drupal’s modified version uses $S$ to indicate SHA-512) and a single base64 character to indicate the number of MD5 iterations used. Examples of a hashed password are:

# Drupal 7 hash
$S$CgwilRJS4VIF1.2y0R7B4qkXJ8F8SJPcuvXRKGlMWESVXMST.5n4
# WordPress 3.0.4 hash
$P$BiutJFaIcFHm5Vl286atS1.Tm1Advv0

WordPress 3.0.4 uses the phpass default of 8193 iterations ($count being 8192) and Drupal 7 uses 16385 — notice that the Drupal password has C after the identifier whereas WordPress has B, converted from crypt style base64 (character set [./0-9A-Za-z]) these are 14 and 13 respectively, then take 214 + 1 = 16385. A John the Ripper benchmark, after patching and enabling the usage of phpass portable passwords (WordPress style, 8193 iterations), quotes approximately 700 passwords checked per second.

Remember, always use a library written by somebody else (who is smart at crypto), use salting and stretching, and always use strong passwords as phpass will not save you from weak passwords and password reuse.

Further reading for those still interested:

Both are good explanations of secure password storage, password stretching and why you should use a library such as phpass or bcrypt (the latter being the one recommended by Ptacek).

Posted in Security | Tagged , | 4 Comments

I see your WordPress 3.0.4 with Exploit Scanner 0.97.5

WordPress 3.0.4 was released a few hours ago to fix a couple of persistent XSS vulnerabilities. One of these was discovered by me, and I also participated in lengthy discussions about the fix (maybe more on this at a later date). It is strongly recommended that you update now as this is a critical security release.

I have just pushed an update to Exploit Scanner with a new set of hashes for WordPress 3.0.4. The update also removes the wp-content folder and sub-directories/files from the list of core file hashes. This was done because of the difference in the release cycles of WordPress and Akismet; Akismet 2.4.0 got included in the 3.0.4 package, however 2.5.1 is the current stable version (hopefully this will be addressed by a change in core in the future, maybe either dropping it from the package and/or never touching wp-content on updates only initial installs).

I plan on releasing the next ‘major’ version of Exploit Scanner to coincide with the release of 3.1. The main new feature, which has actually been sitting in trunk for quite a while, will be core file diffs. This will allow you to see exactly what has changed if the plugin detects a modified core WordPress file. Please download the development version and give it some thorough testing if you feel like trying out the new goodness.

Posted in WordPress | 2 Comments

Hello world! (obligatory)

My name is Jon, I am currently studying Computer Science in the UK and I help make WordPress.

After much procrastination I have finally gotten around to starting a blog using the software that I contribute to (think of it as a Christmas present to the whole world… no really, it is going to be that good!). Like all other bloggers in the world I will be writing about topics that interest me. So, content will be mainly of a technical nature with a heavy bias towards WordPress development.

Posted in Uncategorized | Leave a comment