This issue is rather old, fixed and superseded by more serious code injection problems in Wordpress. But as I never got around to write an advisory and as I did use this vulnerability as an example of a severe CSRF-exploit in my recent talks, I decided to do a short write-up in order to document the issue properly.

Introduction:

The look and feel of a Wordpress weblog is determined by the "theme" of the blog. Such a theme itself consists of a couple of template files. These templates can either be HTML- or PHP-files. To edit these templates Wordpress provides an web interface.

The preparation:

This template editor was not protected against CSRF in Wordpress versions < 2.03. While a couple of functions in the Wordpress admin interface required strict referrer-checking, for some reasons the scripts of the template editor were accessible without providing a valid referrer.

To launch a CSRF exploit the attacker had to know the name of the template file he wants to change and the name of the used theme. Both these informations are in the most cases public, as the majority of Wordpress weblogs use themes that are derived from standard themes that are available to the pubic. Furthermore, if the web server is configured to allow directory listenings, the attacker can get these information by simply accessing the blog's wp-content/themes directory.

With this knowledge the attacker could create a malicious webpage that contains a HTML form with the action POST and the target http://baseurl_of_the_attacked_blog/wp-admin/theme-editor.php and four hidden fields:

• A field called "action" with the value "update",
• a field called "file" with the name of the template file as value,
• a field called "theme" with the name of the theme as value,
• and a field called "newcontent" that contains as value the new HTML/JavaScript/PHP code that the attacker wants to inject into the application.

This form can be contained in e.g. a hidden iFrame and will be submitted via JavaScript whenever anybody accesses the malicious web page.

The attack:

If the attacker succeeds to lure the blog's admin/owner to access the malicious page while being authenticated with the blog, the hidden request that is created by the web page is send within this authentication context admin and is therefore accepted and executed by the blog.

Many CSRF attacks are hard to exploit as the attacked victim has to be logged in the attacked application at the same time the attack is launched. In the case of Wordpress it is rather simple for the attacker to ensure this condition: Many blogs employ comment moderation. Every comment that is submitted to the blog has to be manually approved by the blog's admin before it can appear. Therefore, all the attacker has to do, is to include the link to the malicious page into a comment to one of the blog's articles. To moderate the comment, the blog's admin has to be logged into the admin-interface and to judge if the comment in ok, he should follow all provided links. Peng.

Closing remarks:

As I already wrote in the beginning, the issue is fixed since WP 2.03.

I found this vulnerability in late March 2006 and reported it to the security people at Wordpress immediately. As I became a father a couple of days later, I temporary lost interest in web security. Before I got around to write an advisory and post it to the appropriate places, other people found a more serious code injection issue in WP and publicized it. After this it felt kind of pointless to write the advisory. Nonetheless I considers this issue to be a very good example for the potential damage a CSRF-attack can do - in this case PHP code injection. As CSRF is still frequently underestimated, such an example is useful for raising awareness.

By the way, it took Wordpress quite a long time to fix the issue. One of the reasons for this is, that they decided to drop referrer checks and introduce form-nonces (the right thing to do (tm)). Check out this mailing-list threat to get an impression how clueless many web app developers are when it comes to CSRF.

Justus and I finally found the time and patience to decide on a hosting option for our client-side anti-CSRF proxy. From now on, we will maintain RequestRodeo on nongnu.org. There are still open issues to implement and rough edges to smooth (cough HTML parser cough). So if you care about CSRF and/or are a Python enthusiast – hop on board. It is called open source for a reason.