We finally have an opportunity to discuss our first two security bug bounty payouts for WordPress plugins, both for relatively minor issues. We actually paid them out in late October but we were waiting until after one them was finally fixed (the other was fixed within hours of the developer being notified) to write about the issue.
XSS vulnerabilities are not as big an issue as vulnerabilities that allow adding arbitrary code to a database or into a file. Because these two vulnerabilities are only accessible in the admin area, it limits there severity even more. If they were to be used by an attacker they would be used in a attack to target at an individual website instead of a mass attack. Most attacks on WordPress based websites are mass attacks.
A fix for NextGEN gallery was included in version 1.8.4 and a fix for WP e-Commerce was included in version 126.96.36.199.
Web Browser Based Reflective XSS Protection
We found that both Chrome 15 and Safari 5, whose protection come the WebKit rendering engine they share, were able to successfully block the attempted XSS.
We found that Internet Explorer 9 only blocked the attempt XSS if you were already logged into WordPress when attempting to access the malicious page. If you were not logged in you would be asked to login and then be taken to the malicious page where the XSS was not blocked. This is due to Internet Explorer disabling the protection for requests originating from the same website. This is one of a number of weaknesses in Internet Explorer’s protection discussed in the paper Bypassing Internet Explorer’s XSS Filter (PDF).
Firefox doesn’t currently provide any similar functionality, but with the NoScript add-on installed we found the attempted XSS was blocked.
Keep in mind that the web browser protections are not full proof and it is possible that XSS attacks could be crafted that can evade the protections.
Testing Security Plugins Against These Vulnerabilities
Now that updates for both plugins have been released the way to prevent these vulnerabilities is to make sure you are running the latest version, which should make sure to with any installed plugins, but what about similar vulnerabilities that developer are not yet aware of? The biggest protection that you have is that targeted attacks are rather uncommon, so you are unlikely to be exposed to this type of issue. Then protection comes from being careful when clicking on links and using a web browser that provides protections against this type of hack.
For this test, we tested plugins that did not require signing up for any service. We tested the following plugins:
For all four plugins we found that provided no protection. This is rather disappointing as this is just the type of thing they might be useful for. Most times when WordPress based websites are successfully attacked it is due to outdated software, which keeping software updated would have prevented, or it is due to a hacker gaining access to the underlying files that make up WordPress. In a case where the hacker has access to the underlying files the plugins cannot prevent access to the files (making files un-writeable is generally not effective as the hacker generally has the ability to make the writeable again) and the hacker could remove or modify the plugins. They could even modify the software to report that the website is still secure (You probably won’t find much security software of this type warning about this serious weakness, though it doesn’t appear that many hackers bother doing that as the software isn’t popular enough to be worth the time it would take to do that.).