5 ms·

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

75 points by ValentineC 11y ago

iokevins 11y ago
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 11y ago
  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-bad.html https://blog.sucuri.net/2016/03/when-wordpress-plugin-goes-b...
- leepowers 11y ago
  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/ https://wordpress.org/plugins/advanced-custom-fields/
cies 11y ago
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 11y ago
  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.
  - AustinG08 11y ago
    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.
  - cies 11y ago
    I stand corrected. Still I think many other CMSes have this functionality in core and thus allow plugins to extend on it.
  - CM30 11y ago
    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 11y ago
      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.
Karunamon 11y ago
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 11y ago
  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.
- Otto42 11y ago
  Plugins do not auto update by default. You have to specifically turn those on, and not via a switch, but via code editing.
matthewarkin 11y ago
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 11y ago
  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 11y ago
    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.
legutierr 11y ago
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 11y ago
  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 11y ago
    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.
jbeja 11y ago
You somehow disgust me.
- dang 11y ago
  We've banned this account for repeatedly violating the HN guidelines. We detached this comment from https://news.ycombinator.com/item?id=11231283 https://news.ycombinator.com/item?id=11231283 and marked it off-topic.
PostThisTooFast 11y ago
It's "plug-in." If hyphens are beyond you, stop dicking around online.
Otto42 11y ago
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.

75 points by ValentineC 11y ago

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 11y ago
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-bad.html https://blog.sucuri.net/2016/03/when-wordpress-plugin-goes-b...
leepowers 11y ago
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/ https://wordpress.org/plugins/advanced-custom-fields/

cies 11y ago

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 11y ago
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.
- AustinG08 11y ago
  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.
- cies 11y ago
  I stand corrected. Still I think many other CMSes have this functionality in core and thus allow plugins to extend on it.
- CM30 11y ago
  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 11y ago
    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.

Karunamon 11y ago

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 11y ago
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.
Otto42 11y ago
Plugins do not auto update by default. You have to specifically turn those on, and not via a switch, but via code editing.

matthewarkin 11y ago

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 11y ago
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 11y ago
  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.

legutierr 11y ago

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 11y ago
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 11y ago
  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.

jbeja 11y ago

You somehow disgust me.

dang 11y ago
We've banned this account for repeatedly violating the HN guidelines. We detached this comment from https://news.ycombinator.com/item?id=11231283 https://news.ycombinator.com/item?id=11231283 and marked it off-topic.

PostThisTooFast 11y ago

It's "plug-in." If hyphens are beyond you, stop dicking around online.

Otto42 11y ago

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.