WordPress fixed god-mode zero day without disclosing the problem

Last week's WordPress patch run fixed a then-secret zero day bug that let remote unauthorised hackers edit or delete WordPress pages. The remote privilege escalation and content injection hole hits Wordpress versions 4.7 and 4.7.1 and allows all pages on unpatched sites to be modified, redirecting visitors to exploits and a …

[theblackhand]

So...

Now you can get you Wordpress site hacked if its running old "vulnerable" versions OR the latest, greatest version. And not just a little content changing, we're talking complete site compromise.

If only there was pattern here that showed whether you should still be using Wordpress...

[luminous]

Re: So...

What CMS would you recommend instead?

[Pomgolian]

Re: So...

Wordpress is not a CMS. It is a blogging tool.

If you want a proper CMS, one that has been well designed with the best components, take a look at www.concrete5.org

[luminous]

Re: So...

Look, originally it was not intended as a CMS but there are millions of websites that use it as a CMS. Sorry, but that now makes it a CMS. Look at all the plugins and themes that are available that are nothing to do with blogging.

Concrete5 looks interesting but way too much in its infancy on first glance.

[Pomgolian]

Re: So...

>Sorry, but that now makes it a CMS

...using a monkey wrench as a hammer repeatedly does not make it a hammer. It's still the wrong tool for the job.

[UncleNick]

Re: So...

Concrete5 needs shell_exec() turned on to even start up - which I've just had to turn on for a customer :(

(and it shell_exec()'s generated code in parts as well, so that's not open to abuse in any way is it?)

[Ian 55]

well designed with the best components

.. and yet it uses PHP?

[Anonymous Coward]

Re: So...

What CMS would you recommend instead?

I'd go with Joomla, but I need facilities that go past just presenting output & blogging (the ability to set up groups of users, for instance) and if there is one thing you should not do with WP is trying to bend it into something that it is not suitable for by means of plugins.

That said, Joomla has stupid things too, like defaulting to sending passwords in cleartext email, but at least it has 2FA built in. I guess the key problem for most people is that it isn't all for free, but for me that ensures the eco system does at least something to live off other than ^&$% advertising and stealing people metrics.

I hear others have good results with drupal, but that strikes me more as a good toolkit for people with a programming background. Hard to set up if you don't have the skills, but if you do or want to go really *BIG*, drupal seems to be the way to go.

If you just need a blog but want it more fancy there are places like Squarespace (link to a description + competitors) which basically amounts to putting a few building blocks together. It's too inflexible for my needs, but I know some people that are quite happy with it.

However, like in the movies, whatever technology or approach you choose counts for nothing if your content sucks. If your content is good, you can even get away with raw HTML..

[Anonymous Coward]

Re: What CMS would you recommend instead?

If possible, avoid any CMS that allows web-based or app-based editing. They're too cumbersome for their main use case - editing by non-web-developers/designers - anyway.

One option for a read-only site is to do your editing in a private Wordpress instance, scrape it with wget or a static site generator plugin, and upload the resulting html files to your public site.

If you must have comments or other interactive features, you're screwed. You will get hacked.

[the-it-slayer]

Re: So...

@luminous - if you want a proper blogging tool, Ghost works awesome (developed/started by a guy who came from Wordpress)

CMS on the other hand, they all have their pros/cons.

[Stevie]

Re: So...

"Now you can get you [insert any computer software] hacked if its running old "vulnerable" versions OR the latest, greatest version."

There; fixed that for you.

PS All your blog are belong to lightbulb.

[Anonymous Coward]

How the hell

do sql injection vulnerabilities still keep happening?

Prepared statements have been around since forever and they make it impossible for this to happen.

Then again, it's WordPress, they are famous for always inventing new attack vectors.

[Anonymous Coward]

Re: How the hell

WP still uses its own cruddy SQL preparation layer (wp-includes/wp-db.php). It's ingrained in thousands of popular themes & plugins. They can't change it without breaking 25% of the internet.

I know for a fact that there were sqli vulns in recent WP versions, likely unrelated to the REST API and therefore still unpatched. I looked for them myself without success. All I can is, this code is a steaming pile of crap.

The only solution is to nuke Wordpress -->

[Anonymous Coward]

Re: How the hell

> 1 thumb down

> 1 thumb down

Hello, shill. Try harder.

[Ogi]

I think the black hats already knew.

Part of my job involves administrating wordpress instances (I know, *shudder*, but clients demand it, and pay good money for it).

Anyway, for a long time it seemed impossible to actually secure the bastard. No matter how up to date wordpress was, hackers somehow managed to compromise it and inject random snippets of PHP code in random areas. These snippets would connect to their server and pull in more php files with legit sounding names, spawn remote shells, and then they set up a complete environment, with redirects etc... (interesting tit bit, they primarily wrote their nasty in Perl, the PHP was just used to load up and get the reverse shell).

Cleverly, they only redirected if the referrer was a search engine. If you went to the site directly it worked as normal, but if you go via a search engine, it would do all kinds of nasty. As me and the clients went directly to the site, we didn't notice for a while until we got emails from site visitors mentioning the site was hacked.

In the end, I gave up. I disabled exec/eval in php, and set the wordpress directories to read only. This stopped the break ins in their tracks.

As most of the "content" in wordpress is held in MySQL, turns out you can set the whole thing read-only when in production. Only the auto-updates and plugin install need write to the actual directory, so I have a script to "lock" and "unlock" wordpress directories when the clients want to update/install plugins.

Does mean I no longer run the latest wordpress (because the auto-update can't work when the directory is locked), but illogically, it hasn't been hacked since, which has given me (as the sysadmin) some lovely peace and quiet.

Only thing I have to care about now is SQL injection vulns, but thankfully that hasn't happened in the years I had hosted wordpress, and if it does, I have regular backups of the DB (hourly dump to ZFS, then snapshot).

[Tim Brown 1]

Sigh

I just had a look at the details of the bug. It was found in the new REST API that Wordpress enabled by default for the first time in 4.7.0

When I read the patchnotes for 4.7.0 I sighed inwardly at having a new API which I had no interest in using currently, enabled by default and I looked for a way to turn it off. It seemed that there was no easy way to disable it and the documentation I found cautioned against doing so anyway as the API is apparently used by unspecified core routines

Here's a quote from someone on StackOverflow:

"The REST API is not really a security issue, but I suppose some could surface in the future. It's much more important to look at Hardening WordPress - WordPress Codex and Brute Force Attacks - WordPress Codex

As of WordPress 4.7, the filter provided in core for disabling the REST API (via functions.php) was removed because the API is in core now. There is no official option to disable the API as some core functionality depends on it. So if you disable the API, you may see breakage because by default the API core and is available for use by themes and plugins and other sites."

(I bet the author of that reply feels pretty stupid about that first sentence now!)

The whole thing is just an accident waiting to happen. I shall look again at ways to turn off this unwanted API.

[Tim Brown 1]

And...

If you think the API is a good idea, just append

/wp-json/wp/v2/users

to any Wordpress blog base URL running 4.7 or greater and see the some of the information it's happy to offer up by default without any authorisation.

[Anonymous Coward]

Re: And...

The WordFence security plugin is able to block this potential hole. Your test above confirms this:-

{"code":"rest_user_cannot_view","message":"Sorry, you are not allowed to list users.","data":{"status":401}}

Not that I want this to sound like a promo for WordFence. While it's undoubtedly useful, it shouldn't be necessary to have it simply to block stuff like this API merely because WordPress itself won't let you do so. Strangely, a third party can manage it, but Wordpress themselves can't...?!

[Tim Brown 1]

Re: And...

Thanks, I have now found https://wordpress.org/plugins/disable-json-api/ which has been updated to disable the whole REST API for unauthorised users.

But I can't get my head around why the Wordpress developers haven't made this isn't the default state, If individual users have a use for the API then fine they could switch it on. But then again I don't see the argument for moving the API into core in the first place, rather than leaving it as an addon (where it started life). To me it smacks of a "look at us aren't we clever for doing this" type of thing, rather than something that is genuinely useful to most people.

There are all sorts of things you could build on top of the API, but I'm suggest that for 99% of them you'd be better off doing it a different way.

[Anonymous Coward]

Re: And...

Thanks for that (especially the "" was rather revealing as it reveals your new admin name you carefully changed from the "admin" default), but I can't help wondering what happened to the wisdom of leaving things disabled unless you really, really need them..

For me, this keeps WP firmly down on the list of CMS engines I'd want to be responsible for - if the authors themselves are busy creating new gaping holes, users don't stand much of a chance of keeping up security wise.

That said, I need to redo one site anyway as my own geolock prevented me from doing any admin while I was traveling, and that had some side effects. Sigh.

[Stevie]

Bah!!!

I believe this is entirely in line with Tsyber Tsar Giuliani's recent technical bulletin on the matter.

[cd]

Comments

I've used Wordpress for a long time, since shortly after it came out. I think they are sincere but there are logic gaps that make me wonder about the kind of brownies they serve at Automattic.

For example, some of their quasi-official support bloggers were suggesting that it didn't matter if someone knew their login name, yet were also suggesting two-factor auth. So perhaps 1.75-factor for them. Wordpress allows a completely unrelated login name for any account, which if done right makes for blithe log reading; the typical attempts --apparently based on stolen office worker/Yahoo logins-- aren't even close.

Interesting that a week after updating to 4.7.2, one host sends a nervous email about making sure I'm updated. This story explains that anomalous behavior.

Just tried the json exploit, have wordfence running but it still prints out. Off to solve that now. Thank you.

[Tim Brown 1]

Re: Comments

I'll just point out that the various plugins to disable the API only do so for unauthorised users, so if you install one then you need to log out from the admin panel to see it in action, otherwise the API will still return any info you request.

I really, really wish they'd just kept all this shit as a plugin though, which is where it belongs.

[Anonymous Coward]

Re: Comments

I understand why they moved it into core: they don't have a plugin dependency system and a bunch of plugin devs want this API as a dependency.

Like all attempts to improve and extend Wordpress, the whole thing is an exercise in turd-polishing.

[Pomgolian]

Re: Comments

+1 for "an exercise in turd polishing".