Comment by legutierr | Hacker News Reader

Comment by legutierr | Hacker News Reader

Parent Full thread

What surprises me more is that we don't hear about these kinds of attacks more often. The value of WordPress is the massive ecosystem--you can find almost any plugin or theme you can imagine. But every plugin and every theme is a potential vector of attack.

What's to stop any theme author from inserting an on-page credit card number scraper into an obfuscated javascript file or a modified version of jQuery? Just look for common WooCommerce field names on every page load, and if you find something, wait for the visitor to enter their card information and then phone home by loading an image or something else innocuous. I'm not aware of anything that any of the theme distribution channels would be doing to detect or prevent this kind of thing.

Given how easy it would be to construct this kind of attack, given how hurriedly theme-based WordPress sites are built, and given the budget limitations of people setting up theme-based WordPress sites, I tend to think that the main reason we don't hear more about these kinds of attacks is that no one is seriously looking for them.

I suspect we don't hear about this stuff more because the WordPress site and its directories for plugins and themes are moderated and code (generally) checked for possible exploits and stuff. Is it perfect? No, and as the article example shows, updates seem to be checked a whole lot less than new submissions.

But we don't hear about it more because most examples presumably get caught in theme/plugin review shortly after submission. The process isn't perfect, but the moderators do catch most attempts to do stuff like this.

And it's not happening through third party sites, because most people are advised to steer clear of free themes and plugins hosted outside the official directory.

I hope that the moderators are catching this stuff, and if they are that's great. But for moderators to catch the kind of attack that I'm describing the moderation process would require a detailed code review of all included javascript files, a rejection of any minified or obfuscated javascript files, and some kind of process to verify that any included or referenced js libraries haven't been tampered with. Is that something that is reasonable to expect--or even possible to expect--from human moderators? And what are the specific guidelines that moderators follow? Is it verifiable that they are looking for the right things?

I worry that, if it's hidden well enough, and if the attacker is smart enough not to be too greedy, a scraper could be there for years without anyone realizing it. The signature that such an exploit would leave behind--unlike what is described in the article--would be minimal if it were detectable at all.

Furthermore, I'm not as confident as you are that people who are acquiring themes are necessarily getting them from sites that are doing the kind of review that is necessary to prevent this. Even if people are avoiding free themes (and I'm not sure that they are) there are dozens if not hundreds of paid sites out there.

A thorough review like the one you suggest is perfectly reasonable to expect. They already reject plugins for 'encrypted' code:

https://wordpress.org/plugins/about/guidelines/

And for stuff like phoning home without informed consent. Presumably the WordPress team has to check every line of code to do that, so they catch out any of said attacks during that check.

I amended my above comment to note that the official WordPress distribution channels are not necessarily the ones that are most at risk for this. And for what it's worth, the rationale given in those guidelines for banning obfuscation is that it is not GPL-friendly--not for any security reason.

It's not a total ban, either: "However, note that some systems, like Paypal donation buttons, use encoded code as part of their normal operating mechanism. This is not considered to be 'obfuscated' as this is simply how these types of systems operate and it is not a choice by the plugin author."

That seems like a reasonably-sized loophole.

Disclaimer: I wrote those guidelines.

The "Paypal" loophole is specifically because the first version of the guidelines had people constantly emailing us asking if this Paypal code snippet was okay. All the Paypal code snippet does (or used to do) is to include the relevant form data for "who to pay" in a base64 encoded mechanism instead of including the email address directly in the HTML code snippet. People didn't know what the code was, or if it was okay, and I wanted them to stop asking.

We still look for suspect code, and obfuscation that makes no sense is right out. We even reject minified JS, unless the minified JS is distributed from upstream code and can be verified to be unmodified from the original upstream source.

Well in that case, it's better than it used to be:

http://premium.wpmudev.org/blog/free-wordpress-themes-ultima...

The part about searching for themes in Google says that you get better results now than you used to.

As for what stops third party sites doing this? Well for paid ones, reputation. You allow through themes with lots of security issues and backdoors, and customers start getting hacked and well... people might start steering clear of you in future. So the marketplaces and theme shops have an incentive not to act like scumbags.

For free sites? Guess reputation there too. You're right that we could see this happen in some cases, but not doing the proper review process is a losing proposition for the site as well as the users.

The problem with the current theme/plugin review process is that it only takes place on the initial submission. A malicious individual could submit an innocuous plugin to the repository and change the code afterwards, which is similar to what happened in this case.

Right, just hook an event handler on to a CC form. Couple lines of code.

Reply on news.ycombinator.com