Popular WordPress plugin comes with a backdoor, steals site admin credentials | Hacker News Reader

Popular WordPress plugin comes with a backdoor, steals site admin credentials

news.softpedia.com

75 pointsValentineC29 comments

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.

For the curious: "The plugin in question was Custom Content Type Manager (CCTM), a popular WordPress plugin for creating custom post types that, in the three years since it was uploaded on the WordPress plugin repo, has amassed quite a following, being currently installed on more than 10,000 sites."

Also important to note that WordPress guru Otto commented the following on the Sucuri post about the vulnerability[1]:

"The plugin has been updated to 0.9.8.9, which is a copy of 0.9.8.6 (the last good version). This will remove the malicious code from the plugin, but not any code that was added to sites in the meantime. Please follow through with the Mitigation steps given by Denis in the post."

[1] https://blog.sucuri.net/2016/03/when-wordpress-plugin-goes-b...

10,000 sites is 10,000 sites too many for this type of vulnerability. But it's a relatively trivial install base, given that a competitor plugin (ACF) has over a million installs:

https://wordpress.org/plugins/advanced-custom-fields/

Note: The (legitimate!) plugin was apparently taken over by another author and then an update pushed the malware. The comments here as they stand make it sound like the plugin was always a backdoor, and that's not the case.

Another reason why autoupdates are a double edged sword.

This is a very good point (about autoupdates). That said, it's also to some degree why any sort of ownership change is a double edged sword, even in cases where updates aren't automatic. I mean, how many people check the software they're using hasn't been substantially modified when an update comes out? You could buy a popular program for Windows (or Mac OS, or any Linux distribution, or anything else), add in malicious code, push the update live and find 90% of users would 'upgrade' without even thinking.

Plugins do not auto update by default. You have to specifically turn those on, and not via a switch, but via code editing.

This functionality should become part of wp-core. Currently you need a plugin like CCTM, Types, Pods or ACF to upgrade WP from a blogger platform into a general purpose CMS.

Once part of wp-core it opens the road for plugins to extend on this functionality much easier, since all can depend on it being there.

The CCK module for Drupal became part of core recently. I haven't used Drupal since that happened, but I'm very curious what the experience has been like.

I recently bought the developer version of ACF and migrated a Drupal 6 site with many custom content types and fields to Wordpress. Quite a bit of work, but loads of fun to do.

So far, I'm quite happy with the result, and I much prefer the simplicity and familiarity that it provides for the client (the content 'admin'), among other things.

But the fact that ACF relies on one single developer makes me a bit nervous. I'd also love for it to become part of core...

Custom post type are part of the core though, there's just no admin UI for it. That's really all these plugins provide.

https://codex.wordpress.org/Post_Types

You should be defining them in your theme anyways for source control.

Exactly. It already is a general purpose CMS just by having the Page post type as well as the Post post type. I think it arguably is a great CMS for it's custom post type capabilities. I love me some WordPress.

No, you should be defining custom post types in a custom plugin for source control. That way, your code still works if they change theme, or you replace it when you remake the theme a few years down the line. Otherwise the client will inevitably switch theme, then find all their custom content inaccessible.

And I do think even though this API exists, it should definitely be improved upon and given a built in interface. I mean, don't other CMS scripts like Drupal provide a way to add custom fields and things in core, via a visual interface?

Yes, you should because dealing with keeping that in sync between dev, staging, production is a major hassle.

If you are changing your theme and using custom post types, you still have to modify the theme to support the custom post types. So copy and paste, or isolate the custom post types to a separate file and include in your functions.php.

If you're doing it any other way, then you honestly don't really know what you are doing.

Not really. If you're not running a test site, put the theme and custom plugins inside another folder and commit that to Git or SVN. If you are running a test site, oommit the wp-content folder, with the uploads directory and any third party code set as ignored.

And the way I suggest is also what a lot of WordPress experts suggest, as seen here:

http://justintadlock.com/archives/2013/09/14/why-custom-post...

http://www.wpbeginner.com/opinion/wordpress-custom-post-type...

https://www.smashingmagazine.com/2012/11/complete-guide-cust...

There are pros and cons for both methods.

Personally, I much prefer to put functionality in a plugin and the theme limited to the frontend presentation. To suggest that I don't know what I'm doing is, well... Incorrect.

Syncing production, staging, and dev is an unrelated and solved problem.

I stand corrected. Still I think many other CMSes have this functionality in core and thus allow plugins to extend on it.

There was a popular (4000+ active installs) Wordpress plugin for Stripe that up until recently (read a week ago) wasn't PCI compliant. I wouldn't be surprised if this sort of thing is more common than just one or two rogue plugins (maybe not as bad as stealing admin credentials, but at a minimum doing things that most people would not consider secure). I would think as a large portion of Wordpress users just download and install which ever plugin looks popular and doesn't verify / validate the actual code.

Don't we all do that? We install code from github, we run curl commands and pipe them through bash, we use apt or yum. How many people actually look at the code?

True, though to some extent I'd expect the moderation and reviews of people on Github or apt would be stronger than that of the average wordpress user.

Once we were notified of the issue, I manually removed the bad code and shut down further updates. If you have this plugin, update to the latest version immediately.

Reply on news.ycombinator.com