Over the years, we’ve told users that the WordPress plugin directory is the safest place to download and install plugins from. This is due in large part to the dedication of volunteers who act as gatekeepers and review plugins before they’re added to the directory. Plugin updates, however don’t receive the same scrutiny as there’s too many of them.
Sucuri Security representative Denis Sinegubko, published an in-depth post that explains how an update to the Custom Content Type Manager plugin, which is active on more than 10k sites, turned into a security nightmare for some users. Custom Content Type Manager enables users to create custom fields for dropdowns, images, and more.
According to Sinegubko, a user by the name of Wooranker was added as a maintainer on February 5th. Wooranker is also listed as a contributor to the Postie plugin but according to its author, Wooranker does not and will not have access to change the source code. On February 19th, Wooranker pushed out an update that included the CCTM_Communicator.php file and inserted new code into the plugin’s index.php file.
On March 1st, MartinCDS created a thread in the plugin’s support forums and reported the following:
I recently updated a few of my sites and since then my site was hacked. According to my log files the code was injected via custom-content-type-manager/auto-update.php. I navigated there and there is a form input. Please fix this in the next update. I don’t see a reason for an automatic update anyways- this is a known vulnerability by hackers.
Other users also reported that their sites had been hacked due to the auto-update.php file. This file allowed the attacker to upload a c.php file into the plugin directory. The c.php file was used to create a more sophisticated attack shell named wp-options.php in the site’s root directory. The c.php file was deleted once wp-options.php was created, making it harder to detect.
Custom Content Type Manager is Fixed
Samuel ‘Otto’ Wood, who helps maintain WordPress.org, left a comment on the article acknowledging that the plugin has been fixed on the directory:
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.
To learn how the attack works, insight into who Wooranker may be, and to see a list of mitigation steps, I encourage you to read the post.
A Concerning Reminder
I feel bad for those who updated their plugins from a trusted source only to make their sites vulnerable to attack. Unfortunately, there is no way to prevent situations like these from occurring unless every line of code for each update is scrutinized by a security professional, but that doesn’t scale.
This doesn’t detract the trust I have for the WordPress plugin directory but users need to realize that what happened with Custom Content Type Manager can happen to other plugins as well. Your best defense is to use security scanning software of your choice that keeps track of file changes and to make routine backups.
There is only one way to make WordPress safe, but it’s never going to happen,because of marketing, and because the core developers are not serious about security (let the attacks and the propaganda begin).
Let’s not consider server security for now, and just concentrate on WordPress. There are 3 areas of concern – the core, the plugins, and the themes. Even if the core is secure (which it never is, since the core gets constantly being patched, but let’s assume it is), NOTHING is being done about plugins and themes. I’m not necessarily mean those from the repository, which btw, in this case it came and caused a huge situation, but I’m specifically referring to third party sources. Even if those sources are trusted (is there such a thing?), those “secure & trusted” sources can be compromised as well, look what happened to Linux Mint 2 weeks ago.
I said it a thousand times before, and I’ll say it again, since the core does not check for themes and plugins that are insecure to get activated, WordPRess is never going to be secure. So, if you try to activate a plugin or a theme, the core should check for security holes, and if it finds them, should refuse to activate the said plugin or the theme. At the repository, a big percentage of the plugins have security issues, which I can’t understand how they got approved to begin with. If you don’t believe me, download and run plugin tests with the “Plugin Inspector”, found at wordpress.org, and see it for yourself.
As I said before, this is never going to happen, since WordPress is run like a big government. Quality takes the backseat to activity. They rather have activity (43,000+ plugins for example), as oppose to 10,000 quality plugins, that will not put your website in danger.
There is no other way to maximize WordPress security, the core has to take action, and refuse any unsafe code to get activated. Until then, just like politicians and governments, everything else is just white noise, propaganda, and false sense of security.
I have nothing against the core developers, the plugin and theme teams who approve them, they have tremendously huge and important jobs and I do admire and respect them, but at least admit the shortcomings, and finally do something meaningful about the security issues. After more than a decade of developing WordPress, this is almost embarrassing. Security issues like this, should have been a huge priority over things like distraction free writing and other meaningless things, as an example the new shortcuts proposals, and among countless other things… All the people who are really in charge, are 100 times more intelligent than me, so I’m sure this has crossed their minds, but chose to do nothing, while keep telling us WordPress is safe. The reality is that unless you code your own themes and plugins, your WordPress websites will never be safe, as it stands today.