Cedric’s Cruft

  • Blog
  • Tools
Browse: Home > WordPress < 4.1.2 Stored XSS vulnerability

WordPress < 4.1.2 Stored XSS vulnerability

WordPress 4.1.2 is available as of April 21, 2015. WordPress versions 4.1.1 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site (WP blog).

tldr; mysql → special characters → truncation → input validation → output sanitisation → xss → time to update WordPress.

Introduction: MySQL strict mode

Early this last year, I was reading a blog post about how MySQL’s utf8 charsets only support 3-byte characters. I recommend reading the article if you like PILE OF POOs (by which I mean the character of course). In short: a character that is encoded in UTF-8 can technically be between one and four bytes in length as per RFC3629. You would need a utf8mb4 charset if you’d actually want to store 4-byte characters.

When you insert a string containing a 4-byte character into a utf8 column, the default MySQL behaviour is to truncate the rest of the string after (and including) the occurence of the 4-byte character. This is prevented by using MySQL’s strict mode which ensures that the data is valid before it gets stored.

Strict mode controls how MySQL handles invalid or missing values in data-change statements such as INSERT or UPDATE. A value can be invalid for several reasons. For example, it might have the wrong data type for the column, or it might be out of range. If strict mode is not in effect, MySQL inserts adjusted values for invalid or missing values and produces warnings.

The adjusted value in this case is the truncated string. I should mention that MySQL displays this truncation behaviour not only for 4-byte characters, but also invalid byte sequences for all character sets, which means that utf8mb4 is just as vulnerable, as well as more exotic charsets. The only exception is latin1, which accepts just about anything. To prevent these truncations issues, you would have to enable MySQL strict mode manually when establishing a connection to the MySQL server, as it is not enabled by default.

  • Example (before insert): ex𝌆tic
  • Example (after insert): ex

I was wondering how this knowledge could be used as a possible attack vector. The behaviour of MySQL when it is not in strict mode reminded me a lot of null-byte vulnerabilities that popped up in the past. Things go wrong when data truncation is in play.

How this affects WordPress

I started picking web applications which would be my victims to try this behaviour on. Some projects enabled MySQL strict mode when establishing the database connection. WordPress did not have strict mode enabled. Perfect.

I did not have to look far. WordPress’s core comment functionality appeared to truncate my crafted strings! By default, placing comments is handled in the WP core, although plug-ins such as Disqus can replace this functionality.

Additionally, you are allowed use a limited set of HTML tags in your comments: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • A nice user could comment: <abbr title='Web log'>blog!</abbr>
  • A not so nice user could comment: <abbr title='Web𝌆log'>blog!</abbr>

Both comments pass through the input validator of WordPress, but only the first one gets stored correctly. The second one is stored as <abbr title='Web. This comment effectively breaks the well-formedness of the HTML page, since the closing quote and tag token are not there.

Now imagine what would happen if you made another comment under a crafted username such as: cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100%'

After successful submission of both comments, the HTML output would look as follows:

XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<div class="comment" id="comment-1">
    <div class="comment-author">
        Testing
    </div>
    <div class="comment-content">
        <p>
            <abbr title='Web
        </p>
    </div>
<div class="comment" id="comment-2">
    <div class="comment-author">
        cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100%'
    </div>
    <div class="comment-content">
        <p>
            Injected
        </p>
    <div>
</div>

You get the following HTML as a result:

XHTML
1
<abbr title='Web......cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100%'>

This piece of code will effectively result in script execution as soon as the victim hovers the element. This technique works only when there are no other single quotes between the comment text and the author name, and is thus dependent on the current WordPress theme.

Output sanitisation

Now, if the above was too difficult, there appears to be another way. As long as your comment contains a newline, some sort of output sanitisation will happen which will replace the quote character with &#8220;.

This means that submitting the following payload would be enough:

XHTML
1
2
sometext
<blockquote cite='x onmouseover=alert(1) 𝌆'>

We now have script execution that is no longer dependent on the current WordPress theme since quotes get escaped.

XHTML
1
<blockquote cite=&#8220;x onmouseover=alert(1) ...>

Payload screenshot:

wpxss

Payloads can be crafted in a way that they are invisible to the victim. When the victim now reaches the comments page, script execution will occur. As a proof of concept, I created a payload that adds a new user to the adminstration panel, meaning you need an administrator to visit the injected comment page. The same could be done to download and install a plug-in that executes malicious server-side code. I will not share the PoC right now as it got lost (see below…).

Some limiting factors

The vulnerability only affects certain character sets. If you’re using the latin1 charset for columns in your database, you are likely to be safe. However, utf8 was the default in WordPress, which has now changed to utf8mb4 and has several advantages.

It’s worth noting that in the default setup, comments need approval from the admin. Although (also by default), when your first comment gets approved, you won’t need approval for your next comment 😉 This leaves ample opportunity to first convince the admin that you are prim and proper, and then go scriptkiddy on him.

Be aware that data truncation not only affects the comment functionality but really all of the WordPress core and plug-ins. You should upgrade your WordPress version either way. Many other yet undiscovered attack vectors may exist because of this. For instance, while writing this blog post, I accidentally truncated half of the post by inserting an invalid byte sequence *sigh*.

Fixing this issue

Fixing this issue was a long process. As it affected the WordPress core at the database layer, the fix had to be tested thoroughly to make sure that websites in all kinds of set-ups would still work as expected, regardless of the charset they are using. WordPress is written to work on any system that has PHP and a webserver, regardless of installed features. As a consequence, installing WordPress is a breeze, but development requires the introduction of complex cases to ensure (backwards-) compatibility. Tests were done to see if it was possible to enable strict mode in WordPress, but this was reverted later on because it broke compatibility with too many plug-ins.

Bits and pieces of the patched code were being pushed to the VCS trunk as soon as October 2014. Meaning that it is unlikely that you can conduct a successful XSS on version 4.1.1, the previous WordPress version.

I believe a lot of websites were vulnerable for this stored XSS vulnerability. The Forbes website mentions that there were 60 million WordPress websites in 2012, and that number is increasing each day. If only one out of 60 is vulnerable, then still more than a million websites are open for exploitation. Thankfully, WordPress has an auto-update mechanism in place, so you are probably already patched up by now if you’re a blog owner.

I’d like to thank Andrew Nacin, Gary Pendergast and Mike Adams from the WordPress team, and everyone else who worked on patching this issue. I hope to see some more details on the patching process from their side on the WordPress blog or at a conference in the future.

Timeline
23 Feb 2014Responsible disclosure to WP team
31 Mar 2014Issue acknowleged
7 May 2014Initial patch received from WP team
6 Sep 2014More details sent to WP team
20 Oct 2014Things are happening in the background
20 Feb 2015More things are happening in the background
21 April 2015WordPress 4.1.2 security release
23 April 2015Blog post made public
Reverse engineering the HITB binary 100 CTF challengeSECCON 2015 - Reverse engineering Android APK 2 - 400 writeup
Comments: 6
  1. Bogdan Calin
    2137 days ago

    Dude, this is the coolest vulnerability ever and ever!????However :) .....

    ReplyCancel
  2. Bogdan Calin
    2137 days ago

    Instead of the ???? it was actually your character that was supposed to truncate the rest of the comment :)

    ReplyCancel
  3. Josh
    2132 days ago

    Does this depend on MySQL version? I tested against my own 4.1.1 instance and it refused to post the comment.

    ReplyCancel
    • cedric
      2132 days ago

      Bits of patched code were included in earlier WP versions throughout the year. Version 4.1.1 already refused comments that would be stored truncated in the database. If you want to test this vulnerability you should have better luck with WP 4.0.

      ReplyCancel
  4. Fahad Rafiq
    2123 days ago

    Thanks for the helpful article. The previous version of the WordPress, update 4.2.1 was meant to specifically address the XSS vulnerability within the WP core. However, the developers rushed the Zero-Day exploit fix and failed to fully address the security issues. Now, they’ve patched further security holes. For a quick summary on what WordPress 4.2.2 is about, I found this article helpful: http://www.cloudways.com/blog/wordpress-4-2-2-security-update/

    ReplyCancel
  5. Jacelyn Richards
    2118 days ago

    Obviously very well said, as handling a WordPress website is becoming a tough challenge nowadays due to the increase in threats of hacking. Moreover many administrators felt relieved with the release of WordPress 4.2, hence as instructed once the plugin patch is available, the admins will install it right away and can minimize the exploitation as I read it in a blog in http://goo.gl/3Rc7XE . What will be your view regarding that?

    ReplyCancel
Pingbacks: 66
  1. WordPress 4.2 UNIX-
    2137 days ago
  2. Release of the WordPress 4.2 with fixing serious vulnerability | GreatSoftLine.com
    2136 days ago
  3. WordPress Under Attack As Double Zero-Day Trouble Lands | PJ Tec - Latest Tech News | PJ Tec - Latest Tech News
    2134 days ago
  4. WordPress Under Attack As Double Zero-Day Trouble Lands « Malaysia Daily News
    2134 days ago
  5. Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched
    2134 days ago
  6. Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched - WordPress Themes Agency
    2134 days ago
  7. Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched | Material Design Shell
    2134 days ago
  8. Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched |
    2134 days ago
  9. WordPress 4.2 Stored XSS | Bram.us
    2134 days ago
  10. Wordpress Stored Cross-Site Scripting Zero Day Vulnerability | Threatpost | The first stop for security news
    2134 days ago
  11. Details on WordPress Zero Day DisclosedDigital Era | Digital Era
    2134 days ago
  12. WordPress 4.2 XSS
    2134 days ago
  13. WordPress < 4.1.2 XSS POC
    2134 days ago
  14. Millions of WordPress sites at risk of hijack after zero-day released | KrazyWorks
    2134 days ago
  15. New Security Flaw Allows Attackers to Hijack WordPress Sites | brettwilson1170
    2134 days ago
  16. WordPress vulnerable to stored XSS researchers find - Computer Parts For Sale
    2134 days ago
  17. Just-released WordPress 0day makes it easy to hijack millions of websites [Updated] | NC Computer Tech | Computer Repair | Holly Springs
    2134 days ago
  18. Critical Site Update for Wordpress 4.2 with Scripting Vulnerability - Legacy Marketing Services
    2134 days ago
  19. Hackers Could Take Over WordPress Blogs with a Single Comment | Sandora News Aggregator Portal
    2134 days ago
  20. Just-released WordPress 0day makes it easy to hijack millions of websites [Updated] | TechDiem.com
    2134 days ago
  21. Details on WordPress Zero Day Disclosed - DigitalMunition
    2134 days ago
  22. Dauerstress für WordPress-Admins: Neue Lücke für XSS-Angriffe entdeckt | t3n
    2133 days ago
  23. Angreifer können aktuelle WordPress-Versionen kapern - Meta Thrunks Security Blog
    2133 days ago
  24. WordPress < 4.1.2 XSS POC
    2133 days ago
  25. Millions of WordPress Websites at Risk of Hijacking — Security Gladiators
    2133 days ago
  26. Wordpress : une faille critique affecte plusieurs versions récentes | Reparateur PCReparateur PC
    2133 days ago
  27. ?WordPress urges users to update after comments exploit released | Nagg
    2133 days ago
  28. ?WordPress urges users to update after comments exploit released - 02XL.com
    2133 days ago
  29. Wordpress XSS Harry Blog
    2133 days ago
  30. WordPress Core Engine Stored XSS Vulnerability Patched | Threatpost | The first stop for security news
    2133 days ago
  31. WordPress Under Attack As Double Zero-Day Trouble Lands | Innovation Design | Just another WordPress site
    2133 days ago
  32. WordPress Patches Zero-Day VulnerabilityDigital Era | Digital Era
    2133 days ago
  33. WordPress 4.2.1 Security Release – This is a critical security release for all previous versions | ~II~The Watch Towers ~II~
    2133 days ago
  34. WordPress 4.2.1 Security Release – This is a critical security release for all previous versions | NewsInQueue.com
    2133 days ago
  35. WordPress 4.2.1 Security Release – This is a critical security release for all previous versions | NewsINQ.com
    2133 days ago
  36. 0-day WordPress | Threatpost
    2133 days ago
  37. WordPress Issues 4.2.1 to Patch Critical XSS Vulnerability | WebSpace Reviews
    2133 days ago
  38. WordPress Hack With A Single Comment | WordPress Tutorial By Ayesha
    2132 days ago
  39. Actualización de seguridad para WordPress 4.2.1
    2132 days ago
  40. Top Hosting News | WordPress Issues 4.2.1 to Patch Critical XSS Vulnerability
    2132 days ago
  41. WordPress Issues 4.2.1 to Patch Critical XSS Vulnerability | Wordpress Blog Hosting Companies
    2132 days ago
  42. WordPress XSS 4.2
    2132 days ago
  43. [?] WordPress < 4.1.2 XSS POC | PHP & Java
    2132 days ago
  44. ?WordPress urges users to update after comments exploit released - Tsepa
    2132 days ago
  45. Isaac Price | Critical flaw found in WordPress commenting system
    2132 days ago
  46. 0-day WordPress | Threatpost
    2131 days ago
  47. Millions at risk with Critical Wordpress Zero-day Vulnerability | DruShield
    2130 days ago
  48. WordPress Under Attack As Double Zero-Day Trouble Lands - Tsepa
    2130 days ago
  49. The trojan Emoji | Post Status
    2123 days ago
  50. WordPress Devs Sacked the Trojan Emoji! « Barnabas Adedoyin
    2121 days ago
  51. The trojan Emoji | Post Status | James Reads
    2120 days ago
  52. WordPress ou lorsque la moitié des sites Web du Net sont vulnérables | Data Security Breach
    2116 days ago
  53. WPTavern: Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched - Webnesday
    2115 days ago
  54. Just-released WordPress 0day makes it easy to hijack millions of websites [Updated] • techringer.com
    2108 days ago
  55. WordPress Under Attack As Double Zero-Day Trouble Lands | Welcome to Web Development and Designing to SEO.
    2106 days ago
  56. Post Status: The trojan Emoji - Webnesday
    2098 days ago
  57. SB15-222: Vulnerability Summary for the Week of August 3, 2015 | 007 Software
    2029 days ago
  58. SB15-222 Vulnerability Summary for the Week of August 3rd 2015 « ECI Blog @WordPress
    2027 days ago
  59. SB15-222 Vulnerability Summary for the Week of August 3rd 2015 | Blogg'n @ ECI
    2027 days ago
  60. SB15-222 Vulnerability Summary for the Week of August 3, 2015 | ECI Networks
    1966 days ago
  61. How to support full Unicode in MySQL databases | vantran's NaiveHack
    1958 days ago
  62. La historia de Unicode y su adopción en la web / Blog AGETIC
    1570 days ago
  63. Millions at risk with Critical Wordpress Zero-day Vulnerability | MageShield | Secure & simple magento maintenance
    780 days ago
  64. Millions at risk with Critical WordPress Zero-day Vulnerability
    410 days ago
  65. New Security Flaw Allows Attackers to Hijack WordPress Sites – My WordPress Website
    409 days ago
  66. Tech En bref : une faille critique découverte dans WordPress | KANO
    173 days ago

Leave a Reply Cancel reply

cedric

Uncategorized

2138 days ago

110,755
Recent Posts
  • Tracing API calls in Burp with Frida
  • SANS Holiday Hack Challenge 2015 writeup
  • SECCON 2015 – Reverse engineering Android APK 2 – 400 writeup
  • WordPress < 4.1.2 Stored XSS vulnerability
  • Reverse engineering the HITB binary 100 CTF challenge
Recent Comments
  • Tech En bref : une faille critique découverte dans WordPress | KANO on WordPress < 4.1.2 Stored XSS vulnerability
  • New Security Flaw Allows Attackers to Hijack WordPress Sites – My WordPress Website on WordPress < 4.1.2 Stored XSS vulnerability
  • Millions at risk with Critical WordPress Zero-day Vulnerability on WordPress < 4.1.2 Stored XSS vulnerability
  • h4niz on Tracing API calls in Burp with Frida
  • Millions at risk with Critical Wordpress Zero-day Vulnerability | MageShield | Secure & simple magento maintenance on WordPress < 4.1.2 Stored XSS vulnerability
Archives
  • January 2017
  • January 2016
  • December 2015
  • April 2015
  • June 2014
  • December 2013
© 2013-2017 Cedric Van Bockhaven