Comment by legutierr | Hacker News Reader

Comment by legutierr | Hacker News Reader

Parent Full thread

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.

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.

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.

Reply on news.ycombinator.com