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

And here I thought SharePoint was bad

[Billly Gates]

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:And here I thought SharePoint was bad

[Khyber]

Try Kirby CMS.

Re: And here I thought SharePoint was bad

[corychristison]

Agreed.

I built my own lightweight framework that I use for my clients projects.

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.

Re:And here I thought SharePoint was bad

[Dracos]

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 make tons of money with it" (WP "developers" are hucksters who never earned a cent of that money).

Re:And here I thought SharePoint was bad

[Anonymous Coward]

among open source 'cms' or 'blogging' backends, wordpress is probably one of the safer ones, overall.... *****IF***** you stick with what automattic ships (or use *their* hosted and managed product).

when you self-host or use a cut-rate shared hoster, add a shit-ton of un-vetted plugins, and don't know what the fuck you're doing.. *that's* when wordpress (and pretty much any other similar software) absolutely falls apart...

believe me.. MOST people, even people who claim to be professionals, don't know fuck-all about server security and keeping software patched, or leave their clients high-and-dry once the setup and initial launch is completed and the check has cleared.

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.

Re:And here I thought SharePoint was bad

[Anonymous Coward]

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 are a few static HTML documents & supporting files are all that is really needed, and that maybe a decent solution would be to make it simple to configure document editor to export HTML directly to a website...

Re: And here I thought SharePoint was bad

[Anonymous Coward]

"Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem"

wtf? what are they teaching young developers in collages these days?

Re: And here I thought SharePoint was bad

[Anonymous Coward]

It's got holes too. Lots of them. They all suck and are tragically insecure with no remote possibility of becoming secure. Small projects equal smal dev teams with huge egos and no resources for security audits. Big projects are slow to fix problems and attract idiot devs who make insecure plugins. No CMS is secure.

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

Re: And here I thought SharePoint was bad

[Miamicoastguard]

PHP

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

[Dracos]

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

[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:And here I thought SharePoint was bad

[Anonymous Coward]

> HTML is also quite cheap and simple to setup

Never heard of it. Is it based on node.js?

Re:And here I thought SharePoint was bad

[ebrandsberg]

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:And here I thought SharePoint was bad

[ebrandsberg]

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 the database. 99% of the wordpress ecosystem does not actually do this.

Re:And here I thought SharePoint was bad

[DarkOx]

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: And here I thought SharePoint was bad

[Lord Kano]

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

[Anonymous Coward]

It's based on Dom.Slap

Re:And here I thought SharePoint was bad

[AC-x]

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.

Re:And here I thought SharePoint was bad

[AC-x]

For anyone following up this part of the thread, see my reply here

Re:And here I thought SharePoint was bad

[ilsaloving]

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 some kind of app store style curation of plugin quality, then their repository of plugins would probably drop by 90+%.

And wordpress is just one example of many. The market is now flooded with shockly poorly written applications, because the phrase of the day is "Getting everybody coding!" instead of "teach people to code *properly*".

Re:And here I thought SharePoint was bad

[Tablizer]

How many sites need all these things CMS provides?

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:And here I thought SharePoint was bad

[lactose99]

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:And here I thought SharePoint was bad

[lactose99]

But is it web scale?

Re:And here I thought SharePoint was bad

[Billly Gates]

How many sites need all these things CMS provides?

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 there is just a business need that needs scratching for a moment.

Perhaps that is my experience.

Re:And here I thought SharePoint was bad

[Anonymous Coward]

I disagree, I used it for a few sites, it got the job done, non-technical people could use it to add more content, which was all they cared about. I would never hand code a website again, WP all the way.

Re:And here I thought SharePoint was bad

[Dynedain]

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

[AC-x]

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: And here I thought SharePoint was bad

[Dynedain]

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.

The internet is a giant exploit.

[Anonymous Coward]

Anything and everything on the net is insecure and broken. The plug should be pulled and replaced with something better.

Re:The internet is a giant exploit.

[Narcocide]

Next time hire competent staff. Difficult, but possible!

No denero.

[Anonymous Coward]

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.

So in other words one CAN'T make money on open-source.

Re:No denero.

[Narcocide]

LOL not with code this shitty, at least.

Re:No denero.

[gl4ss]

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.

Re:No denero.

[Anonymous Coward]

What she did was sell the user-base. sounds like she knew exactly what she did and didnt care. But at least she made a few coins on the poor people that were stupid enough to use her software.

Name names!

[Anonymous Coward]

Anyone know who the buyer was? The seller's site is /.ed. I'd want to audit if I'm using any other code by this person and check if it's backdoored also.

Where there's smoke there's fire.

What's old is new

[thereitis]

Old domain names are often bought to be used by spammers, as I understand the domain names have a good reputation behind them and can be used to exploit reputation based spam filtering.
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 could do more to protect themselves?

LavaSoft did the same thing

[Anonymous Coward]

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 its original developer sold it to a shady marketing company "Anti-spyware company Lavasoft AB is now owned by a set of online entrepreneurs who have been linked with misleading websites." https://www.scmagazine.com/lavasofts-new-owners-operated-misleading-websites/article/559189/
https://www.theregister.co.uk/2011/11/11/lavasoft_has_new_owners/

I found out when I googled after I spotted suspicious behavior by Adaware. Shameful!

some people with word press don't get shell / ssh

[Joe_Dragon]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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

[phantomfive]

The flaws in Wordpress are often over-stated. Sometimes you'll get a headline about a horrible Wordpress flaw, like this one that hurt over a million installations. Then you dig in, and actually you needed a rarely used feature to be enabled, and even then, it didn't allow you to inject SQL, at best it allowed you to see more images in your query than you should have. So the actual damage was very minimal.

I do like your idea of a statically generated site. That is a good way to avoid security flaws in many of Wordpress' use cases.

Re:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

Even vandalism is not possible with the particular vulnerability I linked to. The headlines were all hyperbole. 'Security' companies try to make any exploit they find seem as bad as possible to raise the profile of their company. That's why you see exploits with logos, too.

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.

Re:DIY CMS Blues [And here I thought SharePoint

[drinkypoo]

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:DIY CMS Blues [And here I thought SharePoint

[Anonymous Coward]

I do like your idea of a statically generated site. That is a good way to avoid security flaws in many of Wordpress' use cases.

I started work on such a thing about 10 years ago, using PHP to parse template HTML files and fill in custom content.

I gave up because the third-party DOM parser I was using was buggy and incomplete, but the test run worked pretty well and the site was FAST.

Make a content change and "recompile" with a shell script. It was dead simple to use, and the designers could just work with dummy content in the templates - straight HTML and CSS, no PHP code to fiddle with.

Re:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

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:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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 of the site, then maybe host that part on a separate server and system.

Re:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

Why did you need a DOM parser?

Re:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

wget downloads over http. It might have ftp options too, I don't know. Once you build your website in Wordpress, and say you have it running on port 8000, you can run something like this:

wget -r -np -k http://localhost:8000/

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 internet, you could give them an internal URL (or better, one only accessible through VPN), then have the cron job check.

Re:DIY CMS Blues [And here I thought SharePoint

[Anonymous Coward]

The PHP read in the HTML template, then replaced elements of the DOM with custom content.

The problem with doing substitution in one pass is that you don't know at any given time when you'll be done, whether there are duplicate IDs, errors, etc.

Re:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

If it's static, it's trivial :)

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:DIY CMS Blues [And here I thought SharePoint

[Dynedain]

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 database. (though there could still be tons of other types of security flaws).

Website security is a hard problem. The many-eyes approach helps to avoid the common pitfalls when you roll your own solution. As with anything else, there's a tradeoff in risk, maintainability, cost, and a thousand other factors that vary by situation.

Re:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

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:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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 problems we are trying to avoid by going static.

Re:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

rsync does that quickly and well (faster than sftp), and it will do incremental updates, too.

Re:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

I'm skeptical, it's a lot of info about files that needs to transfer.

Re:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

*shrug* It's kind of the problem that every web company everywhere faces. In the worst case, you could keep a local copy, write a script to check for changes against your new revision, then upload anything that changed.

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:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

*shrug* It's kind of the problem that every web company everywhere faces.

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.

In the worst case, you could keep a local copy, write a script to check for changes against your new revision, then upload anything that changed.

Worse case? We want timely file replication all the time. Co's I'm familiar with want stuff up within 15 minutes at times. If there is two-way checking, then you not only have bandwidth issues, but a potential pathway for hackers, which is what we were trying to avoid by going static-file.

If you work some examples out on paper, assume there will be burps and hiccups in the network etc., and see how it recovers itself. I can see folder-level check-sums being used and other such gizmos, but that requires sophisticated algorithms in order to be reliable, bandwidth-friendly, and timely, and likely have host-side processes. It starts to look like a database and thus one is reinventing database-ish tech. The more complicated it is, the more it is subject to the same kinds of attacks database-oriented CMS are subject to. Databases use things like check-sums and sequential transaction ID's to make sure stuff doesn't get lost when they implement replication. Files are not typically indexed on the attributes needed to do such timely. If they were, they'd start to be databases such that you might as well use a common database rather than be stuck with a specialized database staff won't be familiar with.

I know there are LAN-oriented tools for syncing files, but we are not talking LAN. Their techniques assume fast and cheap networking and/or lots of control over both servers.

I'm willing to bet AWS has some support for something like this too

Probably, but it's probably non-trivial to implement and has holes.

Re:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

We're talking about uploading a bunch of static files here, it's not rocket science. Despite the potential for problems, it's still better than running Wordpress straight. Obviously it would be better if this capability were built directly into Wordpress, but obviously it's not (unless you disagree with that point).

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:DIY CMS Blues [And here I thought SharePoint

[Tablizer]

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:DIY CMS Blues [And here I thought SharePoint

[phantomfive]

but 99% is not always good enough.

Yes it is lol, don't kid yourself. We're talking about systems built on Wordpress here.

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.

4th time

[Anonymous Coward]

Hopefully, the 4th time is the charm

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: My top three ways to protect yourself

[Anonymous Coward]

Thanks for the informative post!

Re:My top three ways to protect yourself

[Anonymous Coward]

I cannot figure why a hacker needs to install a backdoor in Wordpress. It seems to be quite redundant.

Re:My top three ways to protect yourself

[Anonymous Coward]

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 spam on "blogs" which allowed anonymous posting were also an issue. Surprisingly, despite many of these not being kept up to date, the vast majority of the security issues they seemed to have were seemingly periodic WordPress "worms" (ca. WP 3.0-3.5) that would spread rather quickly between the outdated installations... perhaps more surprisingly, we'd frequently find even older WP blogs that were grossly insecure that had never been compromised.

Why run PHP?

[Anonymous Coward]

It never ends well. Unless you are lucky.

Re:Why run PHP?

[Anonymous Coward]

Oh please. PHP is fine. It's the people that use it that are the problem

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.

wait what

[Anonymous Coward]

*yawn* a wordpress vuln. again.

Re:Frist!!

[Tablizer]

There's a plugin for that too.

Didn't Equifax Use Wordpress....

[forkfail]

... for their disaster response site after their massive data breach?

Why, yes, yes, they did!

https://krebsonsecurity.com/20...

At what point do they declare the foot completely blown off and stop shooting?

So did AdBlock... apk

[Anonymous Coward]

See subject & ALL about "AlmostALLAdsBlocked" bribed not to work by default http://www.businessinsider.com/google-microsoft-amazon-taboola-pay-adblock-plus-to-stop-blocking-their-ads-2015-2/

APK

P.S.=> Thought you *might* find that tidbit useful... apk