
Popular WordPress plugin comes with a backdoor, steals site admin credentials - ValentineC
http://news.softpedia.com/news/popular-wordpress-plugin-comes-with-a-backdoor-steals-site-admin-credentials-501383.shtml
======
legutierr
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.

~~~
CM30
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.

~~~
legutierr
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.

~~~
CM30
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/](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.

~~~
legutierr
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.

~~~
Otto42
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.

------
iokevins
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."

~~~
stevesearer
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...](https://blog.sucuri.net/2016/03/when-wordpress-plugin-goes-
bad.html)

------
Karunamon
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.

~~~
CM30
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.

------
cies
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.

~~~
jawngee
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](https://codex.wordpress.org/Post_Types)

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

~~~
CM30
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?

~~~
jawngee
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.

~~~
CM30
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://justintadlock.com/archives/2013/09/14/why-custom-post-types-
belong-in-plugins)

[http://www.wpbeginner.com/opinion/wordpress-custom-post-
type...](http://www.wpbeginner.com/opinion/wordpress-custom-post-types-debate-
functions-php-or-plugins/)

[https://www.smashingmagazine.com/2012/11/complete-guide-
cust...](https://www.smashingmagazine.com/2012/11/complete-guide-custom-post-
types/)

------
matthewarkin
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.

~~~
ams6110
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?

~~~
matthewarkin
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.

------
Otto42
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.

