Backdoor Found In WordPress Plugin With More Than 200,000 Installations (bleepingcomputer.com) 84
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.
Re: (Score:1)
There's a plugin for that too.
And here I thought SharePoint was bad (Score:2)
I have pretty much given up at the idea of any somewhat ok CMS. They all are terrible, insecure, or take 6 months to figure out how they work for experienced programmers with clients who want things done yesterday. Drupal was such a nightmare that I never bothered to learn.
It seems easier to write your own code than to use such a system.
Wordpress is a joke. Easy to use but inpractical and a great example why you need an I.T. department to monitor and keep things upgraded.
Re: (Score:3)
Try Kirby CMS.
Re: (Score:2)
Roll your own and keep the source encrypted and under lock and key. If you don't have the resources for that. Then it's only a matter if time before your site is hacked if you're using and CMS
That's a recipe for disaster too. Security through obscurity won't keep you safe. You will not be able to think of all possible attack vectors. Other people will.
LK
Re: And here I thought SharePoint was bad (Score:2)
Agreed.
I built my own lightweight framework that I use for my clients projects.
Re:And here I thought SharePoint was bad (Score:5, Insightful)
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 (Score:4, Interesting)
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.
some people with word press don't get shell / ssh (Score:2)
some people with word press don't get shell / ssh to the server. So the small business who does not want to pay for that (added costs at some hosts)
And they need to make edits without waiting for some managed service to make even the very small changes.
Re: (Score:1)
HTML is also quite cheap and simple to setup, and simpler if it can be exported from a document editor (especially if that document editor can meaningfully handle multiple pages). If someone happens to have a decent website hosting service (one which updates software and keeps unrequested features disabled), that very simple solution is pretty unlikely to cause security problems.
If the website is mainly to promote a small business and provide contact information, with maybe an occasional blog post, chances
Re: (Score:1)
> HTML is also quite cheap and simple to setup
Never heard of it. Is it based on node.js?
Re: (Score:2)
But is it web scale? [youtube.com]
Re: (Score:1)
Typically you use only a small subset, but the hard part is knowing what you'll need in the future. WordPress's large catalog means you are fairly likely to find a plugin close to new feature requests. It's the network effect in action. PHB's and marketers will often see something on a trendy site and go into me-too mode.
Re: (Score:2)
Typically you use only a small subset, but the hard part is knowing what you'll need in the future. WordPress's large catalog means you are fairly likely to find a plugin close to new feature requests. It's the network effect in action. PHB's and marketers will often see something on a trendy site and go into me-too mode.
Nope PHBs do not care beyond the next quarter and right this minute. Technical debt is not debt as IT is a cost center etc. Just whip something up quick or they will wonder why they are paying you if another guy can get the job done quicker etc. Then when they want more (most of the case not) you can worry about that problem.
I have not seen anyone say hey can you spend a full year or 6 months on the ultimate end all to be all which we will use for a decade with a long term strategy etc. HA! Most of the time
Re: (Score:2)
Has it been 6 weeks since the last WordPress exploit was reported? That shit runs like clockwork.
WordPress is not a CMS, it's a blog script playing dress-up. It was lousy code when it was first vomited forth in 2004, and having not changed much since, is utterly horrendous code now.
I say things like that often, and from experience I know that the only defenses of WordPress that ever get offered are argumentum ad populum canards, "it's so easy" (you chose it for yourself, not based on client needs), and "I
Comment removed (Score:4, Informative)
Re:And here I thought SharePoint was bad (Score:4, Insightful)
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.
Re: (Score:2)
The vast majority of people who deploy WordPress sites don't know a damn thing about development. They charge an unsuspecting rube $1200 or more to spend an afternoon configuring plugins and spending $50 on a theme. They don't know anything about code, server management, or anything actual developers would know.
Re:And here I thought SharePoint was bad (Score:5, Informative)
[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 [owasp.org], there is no excuse.
Re: (Score:2)
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: (Score:2)
I replied to parent, but there is a trick with MySQL--you can call the parameratized api call, but most MySQL drivers will convert this into raw SQL. In Wordpress, the internal api call to use a parameratized query will do this--on the wire and on the database, it is as if you never did this from a security point of view. I know as my company makes a product that can add a security layer to Wordpress between it and the database, and only for a few rare plugins did we have to support parameratized calls to
Re: (Score:2)
For anyone following up this part of the thread, see my reply here [slashdot.org]
Re: (Score:2)
The fact that the debate in this thread is happening proves my point. Yes, people should be trained to do paramertized queries. But SQL-injection is just one of many potential security flaws that takes time to learn, understand, and ensure you follow best practices to avoid the security risk. Well-supported frameworks most likely have already gone through those growing pains and have the benefit of many-eyes. Something your roll-it-myself solution most likely would not have.
Re: And here I thought SharePoint was bad (Score:2)
I don't disagree with using frameworks, but you specifically claimed that parameterized queries are still vulnerable to SQL injection. That's a very big accusation with huge implications, did you mean to make that claim or did you actually mean something else?
Even if you are using a framework if you're working on an even slightly serious project you'll likely need to make your own db calls sooner or later...
Re: (Score:2)
Re-read the thread and who the authors are of the various comments. I never said anything about parameterized queries being subject to SQL injection.
Re: (Score:2)
Parameteritized queries against MySQL are often converted into non-parameratized queries for performance reasons. This is the DEFAULT behavior of most MySQL drivers. Most programmers don't even know it is happening behind the scenes, and the protection they thought they have is lost.
Re: (Score:2)
Most programmers don't even know it is happening behind the scenes, and the protection they thought they have is lost
Some of the protection they thought they had is lost. Most the bugs at the driver layer are pretty well shaken out because they are so widely used and well tested. While its not impossible, Its still pretty unlikely.
Re: (Score:2)
I'm going to need a citation for that, because PHP's MySQL driver doesn't behave in that way and I can't imagine anyone else's MySQL driver being worse.
Not to mention a Google search reveals nothing and it would be a pretty common complaint if parameratized queries regularly broke when dealing with the ' character.
DIY CMS Blues [And here I thought SharePoint (Score:3, Interesting)
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
Re: (Score:2)
I do like your idea of a statically generated site. That is a good way to avoid security flaws in man
Re: (Score:1)
If you only put public-intended material on your Internet site, then there are no secrets there to steal. (Disable versioning also, relying on only off-server backups.) Vandalism would be the worse case, assuming you don't leave some loose FTP or network path back to your internal systems.
Re: (Score:2)
Re: (Score:1)
Why did you need a DOM parser?
Re: (Score:1)
I've just used mostly "dumb" string substitution for similar projects. If the HTML is bad, that's on the HTML template writer. One can usually test it in a browser with the markers in place. For loops, one can use nested substitution rather than invent a flow-control engine.
Re: (Score:3)
'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 y
Re: (Score:2)
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.
It probably makes more sense just to embed someone else's comment system at that point, even if you're hosting it, only separately from your main site.
Re: (Score:2)
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.
Actually I'll bet this would be rather easy to do with wget or curl or something.
Re: (Score:1)
Wget usually uses FTP, doesn't it? Either way the concept is similar: on a timer or special request, new and changed files are uploaded and obsolete ones deleted via a preset process that checks date stamps. The system has to make sure they stay in sync with the internal (staging) version. Maybe once a week a total refresh is done to cover any gaps.
As somebody pointed out, certain dynamic features like blogs and discussion groups probably won't be timely enough this way, but if it's only a small portion o
Re: (Score:2)
wget -r -np -k http://localhost:8000/ [localhost]
It will recursively download all the files statically into a directory in your current directory. Then you can upload that to AWS or wherever. You could even make it a cron job, so it updates every hour or something.
If the client insisted on using Wordpress dynamically from the
Re: (Score:1)
For non-trivial sites, you probably don't want to re-generate the entire site each time. Also, that may not remove old content properly. Typically a site has images and PDF's also. Some kind of file "delta management" is in order to only mirror what was added, changed, or deleted since the last pass. Delta-based replication is hard to be easy, efficient, and reliable at the same time.
Re: (Score:2)
Once it's 'downloaded' locally, then only uploading the changed shouldn't be too hard using rsync (or similar). There are probably other tools you can use too. I'm going to experiment more with this later, but this is a good idea, thanks for brainstorming it with me. I wouldn't have thought of it if you hadn't suggested it!
Re: (Score:1)
Sites for medium or large orgs can have several thousands of files. I don't see how a simple tool can scan & compare those in a timely manner. Managers like to see some changes show up pretty quick. There may need to be a "quick mode" and a slower but more thorough clean-up mode/process, like a nightly batch.
Re: (Score:2)
Sites for medium or large orgs can have several thousands of files.
Several thousand files is nothing on a modern CPU, and you know it. Even diff -rq [directory] will quickly scan through a hundred thousand files.
Re: (Score:1)
But you have to transfer that info from source to the destination server. The CPU is not the bottleneck.
Take server A and server B with only an SFTP connection between them. How do you know what is different between them, in terms of the web content folder tree?
I agree most of the time we only need to send a "delta set" of changes, but there should be a consistency check at least once a week because bleep can happen. If we over-complicate the info exchange between the servers, then we have the security prob
Re: (Score:2)
Re: (Score:1)
I'm skeptical, it's a lot of info about files that needs to transfer.
Re: (Score:2)
I'm willing to bet AWS has some support for something like this too, but I'll have to verify later when I have time to play around with this problem.
Re: (Score:1)
No, most use dynamic CMS's, the very things we were looking to avoid in this thread. Some CMS's do have dynamic replication built in, but somebody had to build them in, and it only partly solves the security problems we were trying to avoid by going static-file.
Worse case? We want timely file
Re: (Score:2)
Anyway I'll be experimenting with this because I think it's such a good idea. It should work with large data sets, and the code required to implement it should be short.
Re: (Score:1)
It's not a one-shot upload, you have to keep them in sync with the expected files, and not leave old stuff floating around for Google to keep listing. The boss won't care about how much safer you are over WordPress if his/her Big Important Page is not up or missing updates.
Sure, one can slap scripts together to get it 99% in sync, but 99% is not always good enough. Reliable replication over limited bandwidth is not a trivial problem.
Re: (Score:2)
but 99% is not always good enough.
Yes it is lol, don't kid yourself. We're talking about systems built on Wordpress here.
Re: (Score:2)
There's plenty of frameworks and libraries to do that. Also, if you separate your content authoring servers from your content publishing servers, you usually get that (Drupal, WordPress, and many others CMS platforms can easily be setup this way. AEM for example (very very expensive) works that way by default). This only protects against certain types of attacks of course. For example, there's no way to inject SQL through a Wordpress flaw if your public-facing publishing server only has read-access to the d
Conflating nonfree & free software is the joke (Score:5, Interesting)
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.
Re: (Score:3)
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 [wordpress.org] has repeatedly served malware.
Re: (Score:3)
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: (Score:2)
It's not a CMS issue. It's a shit code issue. The more accessible you make software, or a programming language, the lower the barrier of entry is, and the more programmers get involved, no matter how crap their skills are. Wordpress is one of, if not the, single most popular blogging software available because it's so easy to set up and extend.
And as can be expected, it has a ridiculous number of half-assed poorly written plugins that by all rights should never have seen the light of day. If they did so
Re: (Score:2)
I've been impressed with Grav as of late. No database to worry about, all done in flat files using Markdown. Very nifty and nowhere near as insecure as Wordpress
Re: (Score:1)
Next time hire competent staff. Difficult, but possible!
Re: (Score:1)
LOL not with code this shitty, at least.
Re: (Score:2)
what do you mean? thats just what happened.
however he/she who sold it should have been suspicious about selling it in the first place. why would you need to buy open source software? you wouldn't. what he was buying was the install base.
What's old is new (Score:2)
Same here with old WordPress plugins being bought and used to install backdoors in people's sites. One can assume that a tried-and-true plugin would be implicitly trusted which makes this case more unsettling.
I'm sure the WordPress team will be looking at ways to avoid a repeat, but I wonder: could WordPress site owners co
My top three ways to protect yourself (Score:5, Informative)
> 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: (Score:1)
Working as a systems monitor at a webhost for ~2 years, about half of the accounts that we suspended were mismanaged WordPress installs. Of those, perhaps 3/4 were people attempting to do SEO "blogs" on overcrowded shared servers (with shared IPs, good luck with that). Most common issues were... database abuse trying to wrangle million pages of "content", network/worker process abuse trying to ingest "content" from the greater internet, and search engines suddenly attempting to index said "content". Comment
LavaSoft did the same thing (Score:1)
Bait and switch behavior when a company builds a good reputation for trustworthy software then sell it to an untrustworthy company to exploit that trust are a real problem: LavaSoft Adaware did the same thing!
> 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.
LavaSoft Adaware used to be a trusted antimalware program but it
Didn't Equifax Use Wordpress.... (Score:2)
... for their disaster response site after their massive data breach?
Why, yes, yes, they did!
https://krebsonsecurity.com/20... [krebsonsecurity.com]
At what point do they declare the foot completely blown off and stop shooting?