Backdoor Found In WordPress Plugin With More Than 200,000 Installations (bleepingcomputer.com)

According to Bleeping Computer, a WordPress plug that goes by the name Display Widgets has been used to install a backdoor on WordPress sites across the internet for the past two and a half months. While the WordPress.org team removed the plugin from the official WordPress Plugins repository, the plugin managed to be installed on more than 200,000 sites at the time of its removal. The good news is that the backdoor code was only found between Display Widgets version 2.6.1 (released June 30) and version 2.6.3 (released September 2), so it's unlikely everyone who installed the plugin is affected. WordPress.org staff members reportedly removed the plugin three times before for similar violations. Bleeping Computer has compiled a history of events in its report, put together with data aggregated from three different investigations by David Law, White Fir Design, and Wordfence. The report adds: The original Display Widgets is a plugin that allowed WordPress site owners to control which, how, and when WordPress widgets appear on their sites. Stephanie Wells of Strategy11 developed the plugin, but after switching her focus to a premium version of the plugin, she decided to sell the open source version to a new developer who would have had the time to cater to its userbase. A month after buying the plugin in May, its new owner released a first new version -- v2.6.0 -- on June 21.

Comments

Re:And here I thought SharePoint was bad

[Dynedain]

I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.

Conflating nonfree & free software is the joke

[jbn-o]

This situation doesn't back up your point at all. Technical considerations about features and what's easy to learn versus hard to learn are remarkably subjective. What's objectively clear is that Sharepoint (a proprietary CMS) doesn't allow users to inspect what it's doing, alter the code, or share improved versions. Any problems with Sharepoint have to be fixed by the proprietor (Microsoft), and a backdoor in Sharepoint may well not be viewed as something that needs to be "fixed" from the proprietor's point of view.

WordPress, by contrast, respects a user's freedom to run, inspect, share, and modify. Site owners can decide how much time and effort they want to put into keeping their WordPress install secure. If they find a problem, improvements can be vetted, shared, and completely understood. The limits of review and improvement are the site owner's to choose and site owners retain the freedom to fully control their site (so long as they host on free software systems). Even bad free software (for any definition of "bad") is better than nonfree software because users have software freedom. Writing one's own code would grant one the freedoms only Microsoft gets with Sharepoint.

It's not fair to WordPress to conflate a WordPress plugin with WordPress itself ("Wordpress is a joke") or being horribly vague about what is so bad about various free CMSes. WordPress can't take responsibility for what others put in their WordPress plugins. They can only delist the malware plugins and describe why users shouldn't run that plugin downloaded from another source.

Finally, your point fails to describe how this particular WordPress plugin is critical to useful WordPress sites. This matters to WordPress' main audience—nontechnical users—who might want to know why they should not want particular functionality the plugin ostensibly delivers, or how to get comparable functionality another way. Lots of users aren't technical and won't know why they shouldn't install a bunch of plugins, or how to vet the plugins they find provide genuinely necessary functionality (including not blindly accepting every upgrade but vetting the changes along the way). I don't like malware either, but it's not fair to conflate software freedom with non-freedom (as if nonfree software was inevitable or just as reasonable a choice, an alternative), or to blame one party (WordPress in this case) for another' choices, and objections are far more useful when they are specific.

My top three ways to protect yourself

[raymorris]

> Could WordPress site owners could do more to protect themselves?

Here are three suggestions.

1. Do not have plugins installed that you don't use. A large percentage of Wordpress hacks that I have investigated involve plugins that are no longer in use. The only software that is guaranteed to not make you vulnerable is software you have not installed.

1b. As a corollary, if most of the features of Wordpress are things you are not going to use, do not install WordPress. Smaller, simpler code we'll have fewer vulnerabilities.

2. Hacks, either built-in back doors or simple vulnerabilities, tend to use certain PHP functions such as which can execute external commands, such as exec() and popen(). These can be disabled in php.ini. Disabling these functions will prevent hackers from using them, and they tend to indicate poor quality code anyway. If disabling these function stops the script from running, it *may* have been a poor quality script to begin with.

3. Tools are available to scan PHP code looking for suspect portions. These tools can also look for functions such as exec() or popen which should be looked at to see if they may be either venerable or back doors.

Somebody may say that they use a exec or popen either to retrieve web Resources with wget or to run the imagemagick binaries. It's a better idea to use PHP's built in HTTP functions and to use the imagemagick API via the imagemagick extension. The imagemagick binaries are the UI, the USER interface,to imagemagick. Applications should use the application programming interface or API, not the UI.

Re:And here I thought SharePoint was bad

[AC-x]

[Avoiding] SQL-injection attacks is a really hard problem

NO! Avoiding SQL-injection vulnerabilities is a basic part of website coding and extremely easy to do, there is no excuse.