Name Wordpress 3.0.3 Persistent XSS vulnerability
Systems Affected Wordpress 3.0.3 and possibly earlier versions
Severity High
Vendor http://wordpress.org/
Authors Mauro "sneak" Gentile (chiudisessione [at] gmail (dot) com -
http://www.sneaked.net)
Date 20101230
Other contributors duck_ (http://joncave.co.uk/) from
http://wordpress.org/news/2010/12/3-0-4-update/
DESCRIPTION
The default install of Wordpress 3.0.3 allows to insert malicious comments
in order to produce a xss attack. The vulnerability resides in the kses library,
that is used for sanitizing HTML.
ANALYSIS
It is possible to insert a comment with a link using the A tag. The issue is that
the protocol check has done when the href attribute is written in lower case,
so an attacker should insert any kind of protocol into the attribute href with
a vector like the following:
click me
So the cookie stealing practise is achievable:
click me doc
Note that kses uses a whitelist approach to avoid this kind of injections:
$allowed_protocols = wp_parse_args( $allowed_protocols, apply_filters('
kses_allowed_protocols', array ('http', 'https', 'ftp', 'ftps', 'mailto', 'news', 'irc',
'gopher', 'nntp', 'feed', 'telnet', 'mms', 'rtsp', 'svn') ));
The protocol check is not realized whenever we uses the href attribute
with at least one upper case character. Of course this is not a right way to
sanitize HTML.
We can also provide some more effective attacks by using javascript and DOM.
The following vector shows how it is possible to modify a page after clicking on
the injected link.
nice site
The "site-title" is the id of the admin section header, but we can definitely
modify the content of a blog post by just changing it.
Considering the fact that we can use any kind of protocol, the base64 encoding
should be a good way to realize an "obfuscated xss attack":
click here
Wordpress needs an approvation for each comment, but an unexperienced administrator
could allow a kind of fake comment, which looks fine, or he could simply click on
the injected link.
You can find the fixed PHP code at
http://core.trac.wordpress.org/changeset/17172/branches/3.0
WORKAROUND
Actually the vulnerability is fixed with Wordpress 3.0.4.
All information about the fix are reported in
http://core.trac.wordpress.org/changeset/17172/branches/3.0
DISCLOSURE TIMELINE
20101219 Vendor contact
20101220 Vendor proposes a patch
20101220 The patch is right in my opinion
20101220 Vendor takes time to fully audit and test kses.php
20101229 Wordpress 3.0.4 release