Recent
WordPress 3.3 Cross-Site Scripting (XSS)
Yesterday two Indian security researchers, Aditya Modha & Samir Shah, released an advisory outlining a Cross-Site Scripting (XSS) vulnerability within the latest version (at the time of writing) of WordPress 3.3. Many people started re-tweeting the news (including myself) and blogging about it. The problem came when I tried to reproduce the vulnerability, I couldn’t.
I started to think that the vulnerability was a miss-understanding or publicity stunt and was getting annoyed at the many people who were spreading miss-information. I contacted the researchers over Twitter and told them that I was unable to reproduce the vulnerability in any browser or on any WordPress installation including vanilla installs.
The researchers got back in touch with a link to a WordPress installation on which the vulnerability worked. The URL they gave me was an IP address. Within their environment the XSS worked.
At this point I think even the researchers were puzzled. They sent me this code that they believed was the function causing the XSS within wp-includes/functions.php http://pastebin.com/iBnpN8Zm.
function wp_guess_url() {
if ( defined('WP_SITEURL') && '' != WP_SITEURL ) {
$url = WP_SITEURL;
} else {
$schema = is_ssl() ? 'https://' : 'http://';
$url = preg_replace('|/wp-admin/.*|i', '', $schema . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
}
return rtrim($url, '/');
}
The XSS occurs because $_SERVER['REQUEST_URI'] (the URI which was given in order to access the page) was used within output before first being sanitized. Or better yet, it shouldn’t have been used at all.
The reason I couldn’t reproduce it or why the researchers couldn’t reproduce outside of their environment? The reason is the ‘else’ never gets triggered when WordPress was installed via a domain.
If you installed WordPress by accessing http://192.168.100.110/, for example, you are vulnerable. If however, like most people, but not all, installed WordPress via the domain name, http://www.ethicalhack3r.co.uk you are not vulnerable.
Quick and easy fix until WordPress release a patch? Put $_SERVER['REQUEST_URI'] through esc_html() first, esc_html($_SERVER['REQUEST_URI']).
Example (tested):
wp-includes/functions.php:3756
$url = preg_replace('|/wp-admin/.*|i', '', $schema . $_SERVER['HTTP_HOST'] . esc_html($_SERVER['REQUEST_URI']));
UPDATE –
WordPress 3.3.1 has been released that seems to fix the issue.
12 Responses to “WordPress 3.3 Cross-Site Scripting (XSS)”
superevr
If the WordPress site is running HTTPS, there is a good chance that it can still be accessed by IP address, and vulnerable to this bug.
Wordpress 3.3.1 | oziloz
[...] Başka bir sitede yer alan bilgiye göre wordpress domain adresi üzerine (siteadi.com) kurulu ise açık kullanılamıyor. Fakat IP adresi(x.x.x.x) üzerinden kurulum yapılmışsa web sitesi saldırıya açık demektir.[kaynak] [...]
[REPOST] Sophos: XSS flaw in WordPress 3.3 – How the smallest things make testing tough | WEBsISC Blagh!
[...] researcher who goes by the name of ethicalhack3r decided to try to replicate their findings using the proof of concept (PoC) code that was posted to [...]
Wordpress 3.3 Patched to Fix Cross-Site Scripting Vulnerability | LIVE HACKING
[...] 15 issues with WordPress 3.3. Once the vulnerability was made public other researchers tried to test the vulnerability but without success. It transpires that if WordPress is installed using [...]
XSS flaw in WordPress 3.3 | Cyber Crimes Unit
[...] researcher who goes by the name of ethicalhack3r decided to try to replicate their findings using the proof of concept (PoC) code that was posted to [...]
WordPress 3.3.1 XSS Vulnerability Patch and 15 Bugs Fixed
[...] be reproduced/tested using an IP address (not a domain name) via Internet Explorer according to ethicalhack3r.The XSS vulnerability that affected WordPress version 3.3 has been patched in version [...]
WordPress 3.3.1 closes XSS hole | CYBERSEECURE
[...] instances installed using an IP address; instances of WordPress installed using a domain name are reportedly not [...]
WordPress 3.3.1 closes XSS hole |
[...] instances installed using an IP address; instances of WordPress installed using a domain name are reportedly not [...]
WordPress 3.3.1 « hep-cat.de
[...] WordPress 3.3 ist ein Update herausgegeben worden. Es behebt 15 Fehler unter denen sich eine experimentelle Cross-Site Scripting-Lücke befindet. Das Durchführen eines Updates kann also eigentlich nicht [...]
TAPAS
HI!
THANKS FOR THIS POST.
I BEG TO SAY THAT MY 1 WORDPRESS SITE WAS HACK.
WHEN I VISIT MY SITE IT SHOWN “HACKED BY DR.FOSAL”
PLZ. SAY ME HOW CAN I REMOVE IT.
THANK U SO MUCH.
WAITING FOR RPLY.
tomas
best solution is to remove the wordpress wp-admin and all unwanted files
filip
I have the same problem.Waiting for adv.