Stored XSS in WordPress Core - Magebay.comin Market Section Tue Mar 14, 2017 8:26 am
by magebaytn • 6 Posts
As you may remember, we just lately blogged in regards to a critical Content Injection Vulnerability in WordPress which allowed attackers to deface vulnerable websites. While our original disclosure only detailed one vulnerability, we actually reported two to the WordPress team. As it turns out, it was possible to leverage the content injection issue to achieve a stored cross-site scripting strike. This problem was patched in WordPress 4.7.3.
WILL YOU BE at Risk?
This vulnerability has been present in WordPress for a long time, well before 4.7.
The content treatment vulnerability was patched in version 4.7.2, and as such, the chance posed by this XSS vulnerability is much less severe. Furthermore, only users with certain privileges, like contributors, can presently exploit the problem.
Being able to edit any solitary post on a site is a serious vulnerability alone, but there's a notable disadvantage for attackers. Because of the limitations of the WordPress function wp_kses(), a harmful actor was very limited in terms of the HTML tags that may be inserted in the post.
This would result in a post only containing the text “alert(1)”.
We felt it was our duty as security professionals to dig deeper and see how far an attacker could go with this vulnerability. In the process, we discovered the embedshortcode could produce a more dangerous scenario.
In a nutshell, the embed shortcode takes an src (source link) attribute and tries several regular expressions in order to find out which handler method the script should use so the source link can be embedded properly. The one that caught our attention was youtube_embed_url which was registered with the following regex:
The only important detail here is that the last capturing group will catch anything that isn’t a “slash” character; this could include minus-than and greater-than characters too. We checked what the wp_embed_handler_youtube callback function did with this chunk of text. What we found is that it basically generates a Youtube URL and concatenates the last capturing group – youtube(.)com/watch?v=$LASTCAPTUREGROUP.
After doing this, it pushes the generated link to wp_embed and itsautoembed()method.
View more : https://productsdesignerpro.com
That’s where things gets really interesting. If $content (the embed URL) contains something like this:
none of these regular expressions will match, so autoembed() simply returns the$content URL.
In an attack scenario, the story would end here, but things got a tad more complex when we remembered that everything we send to our post would be sanitized by the HTML sanitization function wp_kses().
Even if we tried sending a shortcode like the following:
It would be shrunk down to:
However, we also looked at the shortcode_parse_atts function, which is responsible for parsing shortcode parameters.
In short, it uses a regular expression that matches all pairs of keys and values in a shortcode, and then it creates an associative array out of it while ensuring each of the attributes values is passed through the stripcslashes function. This allows us to send escape sequences like \x41 (A), or \x3c (<)
All that was left in order to get our XSS working was combining all the previous advances into one simple shortcode:
With this, we would get a working stored XSS exploit.
If you have disabled automatic updates on your website, update to WordPress 4.7.3 as soon as possible!
In the event where you cannot do this, we strongly recommend leveraging the https://www.magebay.com or equivalent technology to have the vulnerability patched virtually.