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

[Khyber]

Try Kirby CMS.

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.

Re:And here I thought SharePoint was bad

[Billly Gates]

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.

There is Django and several frameworks that are easy to learn and fairly secure if you know what you are doing. How many sites need all these things CMS provides? If they do then a complex monster like SharePoint might be useful but these are small unless you work for a fortune 500 company.

The people who use Wordpress are small business owners and most customers who want something cheap to setup and forget. Wordpress is defective by design as it doesn't auto update and have all the plugins auto update and be 100% compatible with itself. The whole thing is defective by design as 75% of the people who use do not have an I.T. department unlike those who work with these monster CMS packages and even if they do have an I.T. guy or two they never will check Wordpress as the boss might be pissed if the update breaks something etc.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:And here I thought SharePoint was bad

[Billly Gates]

Outside of silicon valley not everyone knows code. That is the problem. People read a book or remember doing a hello world in HTML with Netscape back in the day and assume it is easy and uncomplicated and do not understand what is at stake and how the whole computing stack from the application layer down to the network and physical work and interact. Just because some sweet .com sites work like magic means it was easy and simple to develop.

There is a market for those who buy template sites from hosts. They should stick with that if they do not know what they are doing or want to pay someone to develp and maintain.

DIY CMS Blues [And here I thought SharePoint

[Tablizer]

It seems easier to write your own code than to use such a system.

I've been down that road, but managers kept asking for additional features that were readily available in existing CMS's or their pluggins. I spent a lot of time re-inventing the wheel and was always behind.

I'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection. (The internal draft may be dynamic.) It's harder to hack static HTML. I know generative CMS's exist, but they never caught on for some reason.

And it's not that WordPress is "bad", it's that any flaw found exposes a vast number of sites due to its ubiquity (and plugin ubiquity). I've found security flaws in my roll-your-own system. Humans make mistakes. It relied on security-through-obscurity, not perfection. STO is a consolation prize in security-land.

Re:DIY CMS Blues [And here I thought SharePoint

[TheRaven64]

'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection

This is what Jekyll does and it's supported by GitHub pages. It's very easy to set up so that a post-push git hook regenerates the site and sets the permissions so that the web server process can read it but can't write anything in that directory. The down side is that you don't get any dynamic content (comments and so on). I've never been quite motivated enough to write a comment system that stores everything in an append-only log and has write access to precisely that one file, so if it's compromised you can always just roll back to the last pre-compromised state.

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

[drinkypoo]

Drupal was such a nightmare that I never bothered to learn.

What version? I've been using it a long time, and it's come a long way, although it's always been pretty spectacularly easy to come up with a simple site. What's tough is migration between major versions, if you use many modules.

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.

Re:And here I thought SharePoint was bad

[lien_meat]

Mod parent up!

If you can't write a database-backed app that always uses prepared statements for every single insert, update and where clauses, in this day and age, you have no business releasing it, even internally. This is basic DB-related knowledge. It is trivial to prevent, with any effort at all.

Re:Conflating nonfree & free software is the j

[drinkypoo]

It's not fair to WordPress to conflate a WordPress plugin with WordPress itself

The difference between Wordpress and other CMSes (like Drupal) is that their official repo has repeatedly served malware.