Any WordPress Plugin or theme that leverages the genericons package is vulnerable to a DOM-based Cross-Site Scripting (XSS) vulnerability due to an insecure file included with genericons. So far, the JetPack plugin (reported to have over 1 million active installs) and the TwentyFifteen theme (installed by default) are found to be vulnerable. The exact count is difficult to grasp, but both the plugin and theme are default installs in millions of WordPress installs. The main issue here is the genericons package, so any plugin that makes use of this package is potentially vulnerable if it includes the example.html file that comes with the package.
DOM-based XSS
The XSS vulnerability WordPress is experiencing is very simple to exploit and happens at the Document Object Model (DOM) level. If you are not familiar with DOM attacks, the OWASP group explain it well:
DOM-Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the Document Object Model (DOM) “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
That means the XSS payload is never sent to the server side and is executed directly at the browser. So even someone using our WAF, can be vulnerable since it never gets a chance to see it. In this case, we were able to virtually patch the exploit, but DOM-based XSS are very tricky to block.
DOM-based XSS are also a bit harder to exploit, since it requires some level of social engineering to get someone to click on the exploit link. However, once they manage to do that, it provides the same level of access as other types of XSS attacks (reflected or stored).
0-Days in the Wild
What is interesting about this attack is that we detected it in the wild days before disclosure. We got a report about it and some of our clients were also getting reports saying they were vulnerable and pointing to:
http:// site.com/wp-content/themes/twentyfifteen/genericons/example.html#1<img/ src=1 onerror= alert(1)>
In this proof of concept, the XSS printed a javascript alert, but could be used to execute javascript in your browser and take over the site if you are logged in as admin.
Remove the genericons/example.html file
Fortunately, the fix for this one is pretty straight forward. Remove the unnecessary genericons/example.html file or make sure you have a WAF or IDS that is blocking access to it. Because of the low severity, but mass impact we reached out to our network of hosting relationships in an effort to virtually patch this for millions of WordPress users as quickly as possible
The following hosts should have virtually patched or hardened your environments from this issue as of a week ago:
- GoDaddy
- HostPapa
- DreamHost
- ClickHost
- Inmotion
- WPEngine
- Pagely
- Pressable
- Websynthesis
- Site5
- SiteGround
We cannot forget one of the basic principles of security, in which we must maintain a pristine environment in production. This means we remove debug or test files before you move into production. In this case, Automattic and the WordPress team left a simple example.html file that had the vulnerability embedded. What’s more concerning here is the reach the plugin and theme have combined; they are installed in many cases, by default in all WordPress installations. Simple oversight, that could have devastating impacts on unsuspecting website owners and businesses alike.
Note that despite being a DOM XSS, any sites behind our Website Firewall is already protected, but if you do not have a WAF or IPS protecting your site, we highly recommend removing the example.html from inside the genericons directory.
AJ Syed Ali
Moe O
Eli Trevino
John Castro
Rianna MacLeod
Sucuri Malware Research Team
Ben Martin
Cesar Anjos
Fernando Barbosa
Justin Channell
23 comments
Thanks for this, it is worth adding that the examples.html can be found in the following places:-
wp-content/themes/twentyfifteen/genericons/example.html
wp-content/plugins/jetpack/_inc/genericons/genericons/example.html
There also seems to be a similar file in the 2014 theme but I am not sure if it is vulnerable in the same way, it does not appear to contain any javascript so I am guessing not.
How does one go about getting added to the list of hosts notified about these types of things in advance for patching?
Shoot us an email (at soc@sucuri.net) and we will notify you directly if there is ever an issue that affects you guys (or whenever we do a pre-disclosure to hosts).
The updated versions of Jetpack and the Twenty Fifteen theme were released earlier this afternoon. Do you update your posts about security issues with information about the updates?
Now we’re at JetPack 3.53. That’s 3 releases in 27 hours. They even switched stable settings backwards in the log! Automattic is the problem…not Sucuri.
The prior 3.5.1 and 3.5.2 updates had nothing to do with this vulnerability, they were remedying a deprecated API on the part of Facebook pertaining to share counts. There was a missing callback argument on 3.5.1 leading to caching issues on the remote server, that had to be rectified in 3.5.2 — which we pushed out promptly before too many people had caught the update.
Regarding today’s 3.5.3 update, Jetpack had been previously made aware of the issue, and was working with the Core Security Team toward a coordinated update and disclosure. Unfortunately, we weren’t given any advance notice of this post, so the timing caught us before preparations were complete. Once the news was released — as the cat was then out of the bag — we pushed the update as quickly as we could, to secure as many users as possible. Hence another point release in short order.
Certainly not our preference on how things aught to be done, but we’re doing the best we can to be good open source citizens and working with all the other players involved.
Thanks for the explanation. Updates are appreciated, as the log shows both Bug Fixes and Security Hardening.
Unfortunately, I’m one who looks for WordPress-related updates and pushes them quickly across sites, since there have been so many security updates across the realm in the past month. So, I did experience Security false positives in Wordfence with 3.51 and ended up jumping around four versions across various sites today…
Oh well, my comment was sour, but just meant as a pushback. Sucuri and Core Security Team are both doing great jobs–yes good open source citizens all around. Thanks!
What in genericons/example.html made it possible for the attack? Why is the readme.txt file safe?
Out of the default themes it looks like it only affects the twentyfifteen theme. The problem is specifically in this JQuery call: jQuery(document).ready(function() where the window.location.hash.split(‘#’)[1] is unsanitized.
So easy to miss, but it highlights the importance of sanitizing ALL user input!
As correctly mentioned by Eric. The problem is with window.location.hash.split(‘#’)[1] part.
WE have tested the same issue and you can patch it using the “encodeforHtml()” function which is used to convert the variables to their corresponding html entities.
After using the same function it will look like this.
If Jetpack or TwentyFifteen are not active, is the site still in jeopardy?
Even if the theme/plugin are not active, this particular file is still accessible publicly, so I would assume it’s still a potential vector. If you’ve updated WP core to 4.2.2 today, it should have removed these files for you automatically.
Thanks. It seems Jetpack has had a string of several vulnerabilities lately. It does not seem to have an auto-update. You’d think by now that all plugins and themes would have an auto-update feature to close the window of opportunity between the time when a vulnerability is discovered until the time the the plugin is manually updated by the site owner.
In case you’re a sys admin maintaining shared hosting servers, you can quickly get a list of affected accounts with: find /home/*/public_html -type f -name “example.html” | grep “genericons”
It isn’t the most elegant way, but it does the job. Of course, you
may need to adjust it to match your environment (e.g. /home2, /home3 etc..).
I would be a little careful in assuming this problem can only occur in files named example.html. Any plugin developer who decided to include this vulnerable genericons package could have easily changed the filename of the example.html file or just used parts of the code and inserted into their own plugin development. It would probably be safer to look for the combination of “genericons” and the vulnerable code “window.location.hash.split(‘#’)[1]”. At least from our preliminary searches, this is a pretty unique combination and won’t occur very often outside the context of this specific vulnerability.
You are right, but scanning all files for that piece of code would be extremely resource consuming, in case of a shared hosting server (500-1000 websites per server in my case). So, doing quick grep only on filenames was good enough for initial impact assessment.
I understand your point, it would depend on how many files you would have to scan. Just wanted to make sure people don’t think the issue could only be restricted to files named example.html. Although at this point I have not heard of it being found in any other filename.
It’s doubtful that a plugin author boosted the impacted part of the file and used it elsewhere. The primary issue is that example.html called an outdated version of jQuery via a CDN. The current version (what is included in WordPress itself) isn’t effected.
I can’t take credit for this, but it makes me smile:
>> WordPress is an unauthenticated remote shell that, as a useful side feature, also contains a blog.
That feature should be under the settings in everyone’s wordpress install – not on another website.
@spiralscripts:disqus – I am having slightly “minor” difficulties trying to locate wp-content/plugins/jetpack/_inc/genericons/genericons/example.html within my site. I don’t use the theme but I am using JetPack… I appreciate your help! Thank you!
thanks for the nice information in the post
Comments are closed.