So will this really help secure WordPress in the future?

WordPress have been becoming more security focused. They surpressed database errors in version 2.3.2 and added salted passwords & cookie security in 2.5. Although some of the initial releases caused more harm then good, we think WordPress are generally trying to do the right thing.

Minimising XMLRPC functions is certainly a good way to mitigate the attack surface. In fact, BlogSec have been thinking about coding a plugin to do this. However, WordPress really need to get a dedicated security team together that will provide quality security standards and procedures around development, infrastrucure and design. Commenting on this, David Kierznowski had this to say:

I don’t believe they have achieved a golden security standard as yet, when considering the security implications in the initial WordPress 2.5 release, but they are certainly on the right track.

According to the advisory, the attacker does require authentication and access to the following URL:

http://[host]/[directory]/wp-admin/admin.php?page=nggallery-manage-gallery

As far as we know, no fix is currently available.

This post will be updated as new information is made available.

Input passed via the “cat” parameter to index.php is not properly sanitised in the “get_category_template()” function in wp-includes/theme.php before being used to include files in template-loader.php. This can be exploited to include arbitrary PHP files from local resources via directory traversal attacks.

According to the advisory, successful exploitation allows execution of arbitrary PHP code, but requires privileges to store PHP files on an affected system and that WordPress is installed on a Windows platform.

The vulnerability is confirmed in version 2.3.3.

Solution:
Update to version 2.5.1.

If you wish to patch your 2.3.3 install, please see the WordPress Trac.

We do not quite follow this advisory. The vulnerability discusses the idea of uploading a PHP backdoor onto a WordPress blog via the upload file facility, or via the plugin edit facility. I don’t think this is really a WordPress issue but rather the correct functionality of WordPress.

We have discussed before in our WordPress Whitepaper that the file upload facility should be restricted to trusted users only. We also recommend you reading our Role Management post.

Of all the bugs fixed, two fairly critical security issues were fixed. A Cross-Site Scripting vulnerability and the WP 2.5 Cookie Integrity Protection Vulnerability, discovered by Steven J. Murdoch.

The latest WordPress 2.5.1 can be downloaded from WordPress.

WordPress discuss the vulnerabilities here and as part of their development feed.

According to Steven:

This vulnerability exists because it is possible to modify
authentication cookies without invalidating the cryptographic
integrity protection.

If a Wordpress blog is configured to freely permit account creation,
a remote attacker can gain Wordpress-administrator access and then
elevate this to arbitrary code execution as the web server user.

The fix is fairly straight forward and WordPress have released a fix in WordPress 2.5.1.

Please note this vulnerability is different to http://blogsecurity.net/wordpress/wordpress-25-secret_key-vulnerability/

Steven’s Advisory is available here.

The SQL Injection vulnerability may allow an attacker to compromise your backend database and potentially your blog and web server.

A public exploit has been released on milw0rm by 1ten0.0net1.

The ’ss_id’ parameter inside ss_load.php is not correctly escaped before being passed to the database.

It was reported that all versions before 0.6 are vulnerable. The plugin homepage is currently not available. Therefore, we can’t prove that the version 0.61(released August ‘07) is indeed safe to use.

It is recommended that you disable this plugin until a fix has been verified.

Our recent "Secure WordPress Whitepaper Revision" shows the new WordPress SECRET_KEY variable in the ‘wp-config.php’ file. This SECRET_KEY must be set to something random, as specified in the WordPress documentation. If not, it may be possible for an attacker to brute force the default WordPress SALT generation process to gain access to your blog.

The vulnerability has been reported as a Medium risk as it only affects WordPress installations matching a certain criteria. See advisory for more details.

A proof of concept exploit is publicly available. Please ensure that you set your SECRET_KEY in your ‘wp-config.php’ file to something random.

From wp-config.php:

Change SECRET_KEY to a unique phrase.  You won't have to remember
it later, so make it long and complicated.  You can visit
https://www.grc.com/passwords.htm to get a phrase generated for you,
or just make something up.
define('SECRET_KEY', 'put your unique phrase here');

The new revision takes a more hands-on approach making it easier to follow and implement. New sections have been added to cover important topics like Spam and Blog Encryption.

Check out more information at the WordPress Whitepaper HomePage.