|
Brought to you by:
Suppliers of:
|
|
|
| |
WordPress was "born out of a desire for an elegant, well-architectured personal publishing system built on PHP and MySQL and licensed under the GPL. It is the official successor of b2/cafelog. WordPress is fresh software, but its roots and development go back to 2001. It is a mature and stable product. We hope by focusing on user experience and web standards we can create a tool different from anything else out there."
While testing WordPress it was discovered that WordPress supports trackbacks in different charsets when PHP's mbstring extension is installed. This feature can be abused to bypass WordPress's SQL parameter escaping which leads to an SQL injection vulnerability that can result in a compromise of the admin account and end in a server compromise. |
| |
Credit:
The information has been provided by Stefan Esser.
The original article can be found at: http://www.hardened-php.net/advisory_022007.141.html
|
| |
Vulnerable Systems:
* WordPress version 2.0.5 and prior
Immune Systems:
* WordPress version 2.0.6
WordPress supports decoding trackbacks with different charsets when PHP's mbstring extension is activated. Because the decoding happens after the database escaping is performed choosing the right charset for the input data allows bypassing the protection against SQL injection.
For the demonstration exploit that was shared with the WordPress developers the UTF-7 charset was chosen, because it is the easiest to work with. Other multibyte charsets that for example allow multibyte sequences ending in '\' can also be used.
The exploit first checks if the mbstring extension is loaded by sending only an UTF-7 encoded '0' in the title field. Because only a decoded '0' will pass the empty() check this will trigger two different error situations depending on mbstring availability.
The exploit continues with injecting bogus SQL commands into the SQL query which will result in WordPress giving out detailed information about the failed query. This error message is used to determine the configure database table prefix, which is needed for the correct exploitation.
In the next step a harmless looking bogus comment is injected into the comment table with a timestamp in the future. This is done to stop WordPress from sending notification emails to the admin during the password hash retrieval.
The rest of the exploit is a simple UNION SELECT injection that determines password hashes by issuing a request for every bit of the hash (128 bits) and checking which error message is returned. With the reconstructed password hash it is possible to create a WordPress login cookie that can be used to become admin.
As admin it is possible to edit (overwrite) all files within the blog directory that are writeable. This can be used to inject arbitrary PHP code in most installations. There exists a protection that denies loading the wp-config.php file into the file editor, but it can be tricked by directly sending a POST request that only saves the files. The wp-config.php file is usually left writeable after the installation has finished.
Disclosure Timeline:
29. December 2006 - Notified security@wordpress.org
05. January 2007 - WordPress 2.0.6 release
05. January 2007 - Public Disclosure
Recommendation:
We strongly recommend to upgrade to WordPress 2.0.6 which also fixes several other security vulnerabilities not covered by this advisory: http://wordpress.org/download/
|
|
|
|
|