WordPress Vulnerable to SQL Injection

Duplicate Page is an open source pluginfor WordPress that does just what you think it will do. It duplicates pages. There are over 800,000 installations of the plugin. It will duplicate pages, posts and custom posts with one click also saving the selected options (draft, private, public, pending).

But security firm Securi has found out that on WordPress versions earlier than 3.4, it will also allow an SQL injection vulnerability to occur.

The bug is important because it is exploitable by any user with an account on the vulnerable site regardless of the privileges they may have (that means subscribers) and is easy to exploit. This bug can allow attackers to steal sensitive user information such as password hashes. It could also lead to a complete compromise of the vulnerable WordPress installation.

Depending on what other plugins are active on the site, this bug can be forced into a PHP Object Injection vulnerability.

Digging a little deeper here, it can been seen that the plugin relies on an admin_action_ hook which is executed at the very end of wp-admin/admin.php. This means that it may be executed when any kind of user is on their dashboard, or even when they are editing their personal information.

A plugin that uses this kind of syntax should routinely do additional privilege and nonce checks to verify that it is not executed by less privileged malicious users.

But that checking does not seem to be happening.

The variable $post_id of the post to be duplicated is assumed to be an integer. That means no matter what value is in $post_id, it will retrieve a valid post if the contents start with the post's ID. For example, "456 garbage" in the $post_id would grab a post whose ID is 456.

There's more. $post_id is directly appended to the $wpdb->get_results() query. Since $post_id can contain unsanitized user input (the "garbage" we added), this means there is an SQL Injection vulnerability.

The values returned by this vulnerable query are re-used in a foreach() loop and are re-appended in the subsequent INSERT SQL query. This means that an attacker can inject arbitrary values in the postmeta table. There you have the elements needed for a PHP Object Injection attack.

Pulling back from the low-levels mechanisms here, what can be done to mitigate?

First, get Duplicate Page 3.4 or better. This bug was first fixed in that release. Also, version 3.5 of the Duplicate Page plug is advised, since it has been tested and checked for the absence of the vulnerability.

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.