My Security Planet » BlogSecurity

BlogSecurity

Frisco Vista blog hacked

Posted: January 24th, 2008, 2:14am CST by DK

Tags: News [edit]

Frisco Vista’s WordPress blog ran into some security problems. His experience can be read here.
WordPress Insecure by Design?

Posted: January 22nd, 2008, 2:47pm CST by DK

Tags: Articles [edit]

We have seen alot of critical vulnerabilities being discovered in WordPress core and its plugins of late, who’s to blame? This article will take a brief look into WordPress design and its core security functions.

One of the major problems I see with WordPress is that it provides little (if any) protection against input validation attacks. So where does the problem lie?

One of the main problem lies in the way WordPress sanitises user input. It passes SQL queries to $wpdb->escape. This function (in most cases) is all that stands between an attacker completely compromising the blog. So what does this function really do?

$wpdb->escape is really just addslashes. Here in lies one of the big problems.

PHP’s addslashes() function only supports UTF-8 and was originally designed to escape single quotes in SQL strings, to allow for names such as O’brien. It really isn’t the function you want to rely on for hardcore PHP security. Hence why Stefen Esser was able to bypass WordPress security and exploit a UTF-7 SQL Injection exploit some time ago. Another example of this, was Abel Cheung’s Charset SQL Injection vulnerability, published last month (which in theory should still be exploitable).

If WordPress is going to get serious about security, we need to come up with hardcore secure functions, that the WordPress core, and its plugin developers can use. These functions should take the security considerations out of the plugin developers hands and secured from within the WordPress core!

There is alot that needs to be done. For starters, I’d suggest providing a proper set of SQL safe functions (i.e. $wpdb->escape_int and $wpdb->escape_str.

This is one area, where I think blogging platforms like Drupal do a far better job!

Note: This article was based on WordPress <=2.3.2 code.
WP-Forum 1.7.4 SQL Injection

Posted: January 22nd, 2008, 2:23pm CST by Philipp

Tags: Advisories [edit]

For Fredrik Fahlstads WP-Forum Plugin was a critical vulnerability made public. Details are available on Secunia and milw0rm.

This hole may allow an unauthenticated attacker full access to your blog and potentally your web server/host.

Input passed to the “user” parameter in the WordPress installation’s index.php script (when “forumaction” is set to “showprofile” and “page_id” to a page with the “” tag) is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.
PoC
See milw0rm
Fix
The BlogSec team are unaware of any fixes at this time.
WP TextLinkAds Plugin SQL Injection Vulnerability follow up

Posted: January 18th, 2008, 4:28am CST by DK

Tags: News [edit]

The TextLinkAds WP plugin is dynamically generated to insert the API key. I think this dynamic generation may be wrecking havoc with version numbers. I have verified this vulnerabiility in version 3.0.8.

Please do not trust the version number on your WP TextLinkAds plugin, your plugin is likely vulnerable.

The advisory has been updated accordingly.
WP TextLinkAds Plugin SQL Injection Vulnerability

Posted: January 16th, 2008, 5:07pm CST by DK

Tags: Advisories [edit]

David Kierznowski of BlogSecurity has found a critical vulnerability in the popular TextLinkAds plugin for WordPress. The vulnerability allows an unauthenticated, remote attacker to completely compromise your database and therefore your blog.

This is a serious security risk, and should take higher priority then what it has. I have shared various emails with TextLinkAds (starting 31 Dec 2007), but no fix has been made available to date - as far as I am aware. It was trivial to find and there are most likely others… I am releasing this now as attackers may already be exploiting it and I am reluctant to leave it longer.

The vulnerability was tested on version 1.1.1 and the latest version 1.1.3, both were found vulnerable. Please note I have verified that this vulnerability affects v3.0.8.. Please note, all plugins are likely affected before (15/Jan/08). DO NOT rely on the version numbers.
Proof of concept:
Removed for security reasons.
Fix information:
The vulnerable code is found on line 512:
$postId = $postId;
This variable is passed to $wpdb->get_results without being sanitised.
to fix this hole, simply change the above line to:
$postId = (int) $postId; /* FIXED */

While browsing through the code, I did notice other SQL Injection problems, but some of these are mitigated by the fact that you need a valid TextLinkAds key to call the function, but a more indepth view may reveal more.
Summary
Although I have provided a fix, I would suggest disabling this plugin until a full review of the code has been conducted by TextLinkAds and an appropriate fix released. I am sure this will cause alot of anxiety, especially as a number of larger and smaller blogs earn income via this service.
Democracy 2.0.1 HTML Injection Vulnerability

Posted: January 16th, 2008, 6:24am CST by DK

Tags: Advisories [edit]

Intro
Democracy is a popular AJAX driven voting plugin for WordPress.

BlogSecurity found a vulnerability in the latest version of Democracy (2.0.1) that may allow attackers to hijack your admin/user accounts as well as a vast number of other attack vectors.

Proof of concept (test your blog):

http://wordpress.dom/blah’style=xss:expression(alert(document.cookie)); (Tested on IE7)
OR
http://wordpress.dom/blah’onMouseOver=javascript:alert(document.cookie);// (Testing on Firebox & IE)

This proof of concept exploits above can be used to test for vulnerable blogs.
How to fix?
Go to your democracy plugin directory and edit class.php.

Vulnerable code: in class.php (Line 166)
$url = htmlspecialchars(add_query_arg(array(’dem_action’ => ‘view’, ‘dem_poll_id’ => $this->id)));

Change to:
$url = htmlspecialchars(add_query_arg(array(’dem_action’ => ‘view’, ‘dem_poll_id’ => $this->id)), ENT_QUOTES);

Double quotes are escaped but single quotes aren’t. As single quotes are used in $url, we can append malicious code.As a fix, we simply use htmlspecialchars() with ENT_QUOTES.
Summary
The Democracy author was contacted initially on the 31 December, and then again at the beginning of last week. As we have not heard anything in over 15 days, we are releasing the advisory along with a fix.

David Kierznowski is credited for the find.
bs-wp-sandbox v1.2 released

Posted: January 13th, 2008, 8:17pm CST by DK

Tags: News [edit]

The main changes in this version are to make it easier to use and to permit comments and post previews by default. Also, when a blacklisted page is requested bs-wp-sandbox will redirect the client to “http://yourblog/”. Now you can change the BLOGNAME variable at the top of the file to redirect the client where you choose (i.e. http://yourblog/blog/).

Version 1.2 of the BlogSecurity WordPress Sandbox plugin has been released. See its tool page for details and for the latest download.
Defeating Audio Captcha Systems

Posted: January 11th, 2008, 8:24am CST by DK

Tags: Advisories [edit]
Jose Palazon, sent us an advisory he wrote which allows defeating of a WordPress antispam plugin named, "Peter’s Math AntiSpam spinoff".

I think this is one of the first practical audio captcha hacks I’ve seen. Very cool actually, nice one Jose.

Now, back to the details…

Here’s another spin-off of Peter’s Custom Anti-Spam Image for WordPress that will generate math anti-spam equations as images instead of custom anti-spam images….

The goal of this spin-off plugin is to further fool spambots somewhat by combining the “make them answer a math equation” and “make them read an image” ideas. This plugin aims to keep the readability of the Custom Anti-Spam version, as well as other features like random fonts and colours.

Jose’s research demonstrates practical Pseudo code to attack this plugin. I’m not going to try summarise, just read the paper. In short, spammers are going to have a BBQ with your blog.

Solution? Use an alternate AntiSpam plugin like Akismet or BlogSec’s SpamBam.
- Jose’s full advisory is available here.
- Jochem van der Vorm released a paper last year on defeating Voice/Audio Captchas. More details here.
wp-scanner back online

Posted: January 8th, 2008, 3:58pm CST by DK

Tags: News [edit]

wp-scanner is back online. We are in the process of moving wp-scanner to become part of a larger, cooler project. We had emails flooding in, so we’ve gotten it back up… please let us know if you run into any bugs.
WP-Filemanager

Posted: January 8th, 2008, 3:11pm CST by Philipp

Tags: Alerts [edit]

The H-T Team have reported a vulnerability in WP-Filemanager.

***No proof of concept available***

The vulnerability is suppose to affect version 1.2. It may also affect earlier versions (in fact, this is likely). It is possible for an Attacker to upload Arbitrary PHP-Code, which can afterwards be executed with Webserver rights.

Currently there’s no vendor fix available. BlogSecurity recommend that users disable and remove the Plugin until a fix is available.

For the original Bug Disclosure visit SecurityFocus.
WP Directory Traversal Vulnerabilities

Posted: January 3rd, 2008, 4:09am CST by DK

Tags: Advisories [edit]

Mustlive has found a number of directory traversal vulnerabilities in WP 2.0.11 (Latest 2.0 branch). BlogSec have confirmed this in WordPress 2.3.1. WP 2.3.2 is not vulnerable.

Please note, this only affects WordPress running on MS Windows.

A directory traversal attack, means an attacker can potentially edit and view files outside of its ‘allowed’ area. Depending on how the web server has been configured, this may allow an authenticated user to view sensitive files such as wp-config, password files etc.

The problem lies in the following function:

function validate_file(..)
if (false !== strpos($file, ‘./’))

This works fine for Linux, however, MS Windows operating-systems supports backslash (.). This means we can bypass the above check (’./’) by using (’.’).

Proof of concept:
http://site/wp-admin/index.php?page=.....htaccess

This is fixed in WP 2.3.2 (latest version checks for ‘..’ and ‘./’).