Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPress 5.2: Mitigating Supply-Chain Attacks

paragonie.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#21

Post by mr__y »

nileshk wrote: post #13
someexgamedev wrote: post #5

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…

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 c…

> 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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#22

Post by Angostura »

dplgk wrote: post #14

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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#23

Post by ddebernardy »

huxflux wrote: post #3

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

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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#24

Post by avian »

someexgamedev wrote: post #5

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 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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#25

Post by ahje »

kiesel wrote: post #20

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 op…

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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#26

Post by mr__y »

frereubu wrote: post #19
someexgamedev wrote: post #5

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…

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 beca…

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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#27

Post by oliwarner »

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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#28

Post by eitland »

> 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:-)

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#29

Post by Ninn »

eitland wrote: post #28

> 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.

Re: WordPress 5.2: Mitigating Supply-Chain Attacks

#30

Post by CiPHPerCoder »

kiesel wrote: post #20

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 op…

> 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?"

Post reply on HN