Go to Bragboard

Stored XSS in WordPress Center - Magebay.com

Magebaytn Magebaytn posted on "Bragboard and Bragline"
View Magebaytn Magebaytn's Bragline
  • Likes
  • Like
  • Like
As you might remember, we recently blogged in regards to a critical Content Shot Vulnerability in WordPress which allowed attackers to deface susceptible websites. While our original disclosure only identified one vulnerability, we actually reported two to the WordPress team. As it turns out, it was possible to leverage this content injection issue to attain a stored cross-site scripting episode. This issue was patched in WordPress 4.7.3.
WILL YOU BE at Risk?
This vulnerability has been present in WordPress for a long time, prior to 4.7.
Combined with the recent content injections vulnerability we found, it's possible for a remote control attacker to deface a arbitrary post on the webpage and store malicious Javascript code in it. This code would be executed when a site visitors view the post so when anyone edits the post from the WordPress dashboard. Because of this, an administrator will try to fix the defaced post, the would unknowingly bring about the harmful script, that could then be utilized to place a backdoor on the site and create new admin users.

The content injections vulnerability was patched in version 4.7.2, and as such, the risk posed by this XSS vulnerability is a lot less severe. Furthermore, only users with certain privileges, like contributors, can presently exploit the problem.
Technical Details
Having the ability to edit any sole post on a niche site is a serious vulnerability alone, but there's a notable downside for attackers. Because of the constraints of the WordPress function wp_kses(), a malicious actor was not a lot of in conditions of the HTML tags that could be put 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 : 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 (