Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Reflected XSS Bug Patched in Popular WooCommerce WordPress Plugin

Automattic has patched a reflected cross-site scripting vulnerability in the WooCommerce WordPress plugin.

An extension of the WooCommerce WordPress plugin, used by 28 percent of all online stores, has been patched against a reflected cross-site scripting vulnerability.

The vulnerability was found in the Product Vendors plugin, which allows an existing ecommerce site to support multiple vendors, products and payment options. Versions 2.0.35 and earlier are affected by this vulnerability, and site owners are urged to patch immediately.

Automatic updates are available, but are dependent on a site’s configuration, and many site operators do not enable them.

“At the time of discovery it was a zero day on the current version,” said Logan Kipp, WordPress evangelist for security vendor SiteLock. “If this was discovered by someone else, it could have been a real problem.”

Kipp said the reflected XSS bug was found in a particular field on the sign-up form available for new vendors through the plugin.

“Theoretically, this is weaponizable by sending a crafted link to any party who has a set of logins on that website,” Kipp said. “And if they have an active session, you could hijack that session.”

An attacker could email that crafted link to an already established vendor on a site running WooCommerce. If the vendor is logged in and clicks on the link, an attacker could capture the session and run scripts on the vendor’s browser, taking control of any functionality they have, Kipp explained.

“The chances are very high that if they are the webmaster, they’re going to be logged in at the time of clicking the link and they’re going to have very high privileges,” Kipp said. Kipp characterizes XSS as a tool to gain higher privileges.

“It’s a means to go further, a foothold,” he said. “So while in itself it may not cause any direct damage to the website, we could potentially gain administrator privileges by hijacking sessions.”

Unlike persistent cross-site scripting bugs where an attacker can drop arbitrary code on a site through some interaction that was not filtered, reflected XSS means that an attacker can inject executable code only onto a session rather than into the application. These types of attacks are more common, Kipp said.

“A lot of times it’s overlooked because people don’t take it seriously. It’s a huge problem because folks don’t always grasp that maybe it can’t modify the website itself, but this is a perfectly weaponizable vector to target visitors,” he said.

An attacker can craft a URL, for example in this case, to automatically submit the entries they put into the form so that as soon as a victim clicks on the link, the malicious script is executed. In the case of the WooCommerce plugin, there’s a high chance of potential vendors having a question about the form and luring the site admin to execute a malicious script.

The vulnerability was disclosed to Automattic, the parent company behind WooCommerce, through its HackerOne bug bounty program. SiteLock was awarded a $225 which it donated to the WordPress Foundation.

“The great thing about patching cross-site scripting vulnerabilities is that it’s very simple inside your own code,” Kipp said. “It’s all about properly sanitizing the interactive arguments. In this case, it’s interesting to find that every other field of this form was properly sanitized with the exception of this one. It’s common to see this. It was probably a feature added after they developed the extension, probably by a second developer who did not follow the same practices.”

Discussion

Missing in your article is a mention that this type of vulnerability isn't something that hackers are trying to exploit on the average website at this time. That is likely in part due to something else important that is left out, which is that all of the major web browsers other than Firefox provide XSS filtering, so a hacker would have to hope their target is using Firefox or figure out a way around that protection for exploitation to be successful.
If you are going be covering vulnerabilities in WordPress plugins it would probably be more helpful to the public if you covered vulnerabilities that are actually being exploited and or have not been fixed.
There was a real zero-day vulnerability being exploited in a plugin a couple of weeks ago that you didn't cover.
With the vulnerability discussed in your article, as long as those using the plugin were keeping their software up to date they would have already been protected, but there are plenty of vulnerabilities that haven't been fixed at the time of disclosure that could use more coverage. As an example, earlier this week we disclosed a PHP object injection vulnerability, which is a type of vulnerability that hackers have exploited against the average website, in the current version of a security plugin.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.