WordPress 5.2: Mitigating Supply-Chain Attacks | Hacker News Reader

WordPress 5.2: Mitigating Supply-Chain Attacks

paragonie.com

107 pointsCiPHPerCoder37 comments

Criminals: We can break 33% of the internet with one wrench!

Because that's what this still comes back to. If you can bribe or intimidate one developer with valid credentials, you can sign as many hashes as you like, if nobody else reviews and catches that commit, the users are toast. And even if Wordpress has a strict review policy, what about the plugins? There are some furiously popular examples out there made by very small teams, well outside Automattic's control.

All in all, there are thousands of people out there that one or two swings of a wrench mean that a massive network of servers become compromised. And in many cases you might not even need that. Hack the personal computer of one of these people, and you're 99% done.

Sleep well.

I set up a WordPress site for a family member a couple years ago and threw wordfence on there just to see what the ecosystem is like. I get near daily alerts of attempted hacks mostly from Eastern Europe. Most common thing is trying to brute force the login page.

Any improvements to WordPress security are welcome. It's got such a huge target painted on its back. Reminds me of windows in the 90s.

As for what I learned, I would move the admin login page and disable common usernames like admin and anything derived from the site url. Probably stop 90% of attacks just with that.

That’s good info, thanks. I just happen to be looking into WP security right now.

Would you recommend wordfence in addition to the changes you mentioned?

I highly recommend wordfence. I have it set to immediately block anyone after a single failed login attempt.

It's fairly resource-intensive, though. I've seen whole servers brought to their knees because of plugins like WordFence -- an unintentional DoS, so to speak. Many of the defenses employed by WordFence would be orders of magnitude more efficient if implemented at the level of the http daemon or firewall. Unfortunately, WordPress plugins must cater to the lowest common denominator, shared hosting.

If what you’re dealing with is thousands of attempted brute force attacks on a daily or weekly basis, a wordpress plugin might not be the solution.

Sure, but you don't know that until the attacks actually begin, and anyone can attack any site for any reason these days. Meanwhile, most people who run WordPress sites don't know how to do anything more complicated than installing a plugin. Being a developer who caters to that market has its own charms and challenges.

to offer a counter opinion I found wordfence highly obtrusive, annoying and full of dark patterns in an attempt to upsell you to premium. They present in their dashboard ALL attacks within their entire network as if those were attacks on your site in particular which is misleading. If the project permits the best practice is to convert the site into fully static HTML (WP2Static, SimplyStatic) and keep the backend site/database separate and local only.

So if I know the username of someone who admins your website I could shut them out with a single POST request? Seems a bit risky.

It's a small site. Not a concern.

I'm really happy with ninjafirewall. Here's a comparison: https://translate.googleusercontent.com/translate_c?depth=1&...

> I get near daily alerts of attempted hacks mostly from Eastern Europe.

Everything you put on the Internet gets daily attempted attacks. The issue is... nobody should care about attempted attacks. Of course people will try to bruteforce your passwords. If you have any kind of software that warns you about these attacking attempts that's not helpful at all. What you want is to make these attacks do nothing. In case of bruteforce attempts it's clear how to do that: don't use insecure or reused passwords.

If you have enough control of the server it resides on, one of the best things you can do is to deny it access to write to the PHP files of the Wordpress install (which requires that you use WP-CLI via command line to do updates), and setup automatic updates by calling WP-CLI through a cron job or however you want to automate that.

When a Wordpress install has write access to its own PHP files, then a vulnerability can do more harm obviously since it can modify the Wordpress install itself and thus more easily "infect" the installation. Denying write access cuts off many attacks from doing significant harm. BTW WP-CLI can also do checksums of your install.

I wouldn't fret too much about seeing attempted hack attempts. If you have enough logging turned on for a public web server, you'll see a constant stream of hack attempts for all types of languages / frameworks. I did this the other day and saw what I recognized as a variety of different attacks targeted at PHP, Rails, and Java.

Regarding usernames: note that Wordpress will, by default, expose those usernames in things like posts (author's username is revealed). I had to modify my theme to make that stop, and even then I'm not 100% sure it's not leaking somewhere I missed. Maybe you want to do all content editing with a user that has reduced privileges and only use your admin user when necessary.

> I'm not 100% sure it's not leaking somewhere I missed

have you checked the REST endpoint?, namely site.tld/wp-json/wp/v2/users

By default all user names are exposed that way.

This plugin allows you to rename the login page - https://wordpress.org/plugins/rename-wp-login/. It says untested with the last three versions of WordPress, but we use it on all our sites and have had no issues. It also doesn't redirect non-logged-in requests for /wp-admin/ to the login URL like the standard setup, so it doesn't make the new login URL available in any way. We were experiencing server slowdowns because of brute force attacks and this plugin really helped.

The best thing to do after that is to set up an .htaccess rule to return a 401 Forbidden error for /wp-login.php, because even with the plugin above the request is processed by PHP, which can still slow things down depending on the intensity of the attack.

This is obviously just security through obscurity, and you need other security measures in place too. Having said that, I find plugins like WordFence are overkill and often confusing, although we build WP sites from scratch so we control a lot of that side of things ourselves, and use a WP-focused hosting service which takes care of the other things like server-level security.

Could you recommend some real[0] WP-focused providers? Since the company I work for has several WP websites with relatively high traffic we've been looking for such providers, tested some but ended with having some VPSes to have the ability to set them up properly. Since those servers are self-managed this is obviously a sub-optimal solution as we have to maintain them, so a reliable hosting provider would be great.

[0] "real" as opposed to provider that has a great WP-related pitch but in-reality this is just a regular shared hosting with no actual wordpress oriented optimization/enhancements.

We've been using a VPS-1 on Pagely for a few years now, and are generally very happy with the service. They take away the management of Ubuntu and security hardening etc, but give you control where you need it such as SSH access - I've written a few bash scripts that use WP-CLI to make it easier to manage multiple sites. We've had one or two small issues, but all fixed quickly, and nothing of the sort that made us start looking elsewhere. You sometimes have to be persistent with first-line support, but things generally get escalated appropriately if necessary.

The one real gripe I have is that they rewrote their control panel as an SPA, and I think it's made it much less usable. It's difficult to do things like open a link in a new window, and state doesn't always remain or update in the right way - for example, you can lengthen and sort a list, go to an item, use the back button and you have to lengthen and sort the list again. However, I don't use that control panel enough to make it a serious time drag, and they're apparently writing an API which should cover most of my use cases.

Do not use that plugin. It has a unintentional back door where you can just bypass it completely and get the login screen. All of the forked plugins that are based on it, that I have seen, have the same issue.

Plus, since it's more than 3 versions old, many of the security plugins will flag it. If it's your site, that's fine. If you have set a site up for someone else, it's hard to explain that it's ok to use this plugin.

Can you give me more detail than "unintentional back door"? I'm obviously interested, but it's difficult to know what to do without more of a pointer on what the issue is.

Edit: Found this - https://github.com/ellatrix/rename-wp-login/issues/27 - and can reproduce that behaviour, so I'm going to start looking for something new, or potentially taking over that plugin.

Edit 2: This seems to be a maintained fork that is in active development and covers the issues on the original abandoned GitHub repo - https://wordpress.org/plugins/wps-hide-login/

I have a mostly static website that's not powered by WordPress in any way, yet my logs are full of requests for wp-login.php and such. Attempted attacks against WordPress are just the normal background radiation of the web these days.

I really like WP-Cerber: https://wordpress.org/plugins/wp-cerber/

The update mechanism itself is still insecure, as the wordpress instance must have the ability to exchange its own source code - something you'd at least call risky. Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.

PHP has composer, a dependency management system. There's an option to build a wordpress project using composer.

Even more, there's even a boilerplate project that you can use to bootstrap your new wordpress setup - see https://roots.io/bedrock/

Problem is that there's a ton of shared hosting providers that won't support such a setup, as it would require a lot of modifications to 1-click-installers for WordPress. General WordPress users have no idea about such things, and the demand for more elegant solutions is therefore quite small.

That, and the fact that WordPress popularity stems from the fact that it's fairly easy to set-up without technical know-how, makes it unlikely that another path will be chosen in the close future.

> Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.

This isn't wrong but I'd argue it's a lower priority concern than you believe it is.

A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)

https://paragonie.com/blog/2016/10/guide-automatic-security-...

The goal of an automatic update mechanism should be to prevent the rampant exploitation of 1days, like what happened with Drupal not too long ago.

If you had to choose between "owned within 7 hours of the advsisory" or "less theoretically secure in a constrained environment but still securely self-updating" in the CMS/blog threat model, the latter wins.

There's no easy way to rearchitect WordPress to support the principle of least privilege and process isolation for their auto-updater in a way that ensures everyone still uses it. So for the time being, that's worthy of being called out, but isn't a big enough deal to label the whole shebang insecure. Because "insecure in which threat model?"

> A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)

That's right, and I also think the popularity stems from the simplicity and the fact that it existed when the whole blog thing took off.

There's actually the option to provide your FTP credentials in the admin console and have wordpress update itself over an FTP connection. It is process separation, then, but OTOH potentially exposes your webspace credentials to an attacker. :-)

Can you elaborate on the specific threats you're thinking of?

I'm picturing a WordPress environment where all the source code owned by root with R+X permissions for www-data and nobody else, and an "Uploads" directory owned by root that has R+W for www-data with no X.

So assuming we have locked down permissions but still running a vulnerable plugin; we still have code execution and can ex-filtrate secrets via Uploads or create symlinks or upload malicious payloads. We just can't use the webserver to change code. You could still steal credentials that give us access via other means.

By being able to modify executable files on the webserver, an attacker can add a backdoor through a security hole quite easily. Without, he could just make use of the security hole as of itself.

Perhaps HN should give Wordpress a thumbs up for once! I start, nice.

Agreed, Wordpress has come a long way,along with PHP for that matter. Both deserve a little more praise and less criticism for the warts of bygone days.

There has been chatter about doing this for over 8 years in the WordPress bug tracker, and I vaguely recollect chatter about it even earlier, around when automated updates were first introduced. What's surprising is that this hasn't been done earlier, and speaking personally I do not think this deserves any praise - on the contrary.

https://core.trac.wordpress.org/ticket/18577 - Updates and downloads should be delivered securely (signed and delivered over SSL), opened 8 years ago, partially closed 6 years ago (because it began to use SSL).

https://core.trac.wordpress.org/ticket/25052 - Updates and downloads should be signed, opened 6 years ago, closed 6 days ago.

https://core.trac.wordpress.org/ticket/39309 - Secure WordPress Against Infrastructure Attacks, opened 2 years ago, closed 12 days ago.

I think this is very good because it reduces the attack surface for people who track current code.

It's important to remember a large set of un-updated nodes will remain. Not that anyone can do much, but equally not that the entire surface of bad Wordpress will go away. I would be interested how big the long tail is. one third? more?

It is also worth thinking about the code signing problem firefox just had, and reflecting on the possibility of the hack in the head still taking place: either a denial-of-service or a bad code intrusion risk remains.

Its far far less likely, and it can be mitigated, but this is the reality of distributed systems: You can only do the best you can, nothing is guaranteed. (even TMR units fail)

> In the future, we will be working to implement a system that allows vendors to sign their own releases and publish these signatures (and related metadata) to an append-only cryptographic ledger.

Without dismissing all crypto currencies this seems more immediately practically useful:-)

Soo, almost exactly like the Apple Store works? But just without a high performance database.

If you're curious:

https://paragonie.com/blog/2016/10/guide-automatic-security-...

https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...

I've written a lot about the design and utility of append-only cryptographic ledgers for this use case.

Mozilla has their own implementation based on Certificate Transparency: https://wiki.mozilla.org/Security/Binary_Transparency

Filippo Valsorda is working on bringing something similar to the Go ecosystem, based on a Trillian personality.

There's a lot of work going on, there's just not a marketing team behind these efforts, so you only ever hear about blockchains and ICOs.

I misread that as WordPerfect 5.2 ...

I have old WordPress blogs sitting around. They got hacked of course. Because they are so old, it would be a huge pain to upgrade. I restored from backup and chmod 550 the whole WP installation. Much easier than upgrading and less time than migrating to static blog framework.

If they are simplish blogs, I can't see that there should be any difficulty in updating WP and the theme, and you'll be doing the rest of the Internet a service.

Reply on news.ycombinator.com