WordPress sites under attack from newly found Linux trojan • Hacker News Board

Re: WordPress sites under attack from newly found Linux trojan

#81

Post by snowwrestler » Thu, Jan 05, 2023, 3:44 AM UTC

progval wrote: post #57

snowwrestler wrote: post #52

Earlier quoted context omitted.

Wordpress typically has write access to itself so it can auto-install updates right away, which is also a good idea for security. But I t’s definitely a tradeoff in that it also increases the potential harm from bugs.

Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?

When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical.

But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on the side of fast and easy patching over ideal server settings.

And honestly it’s hard to fault that decision; the vast majority of attempts on WP sites target known and patched vulnerabilities. Even this article notes “sites running outdated or unpatched versions of these WordPress tools are at risk.” (emphasis mine) Anything that helps people patch faster is probably the right choice for the WP community.

Re: WordPress sites under attack from newly found Linux trojan

#82

Post by deafpolygon » Thu, Jan 05, 2023, 6:40 AM UTC

snowwrestler wrote: post #81

progval wrote: post #57

Earlier quoted context omitted.

Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?

When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical. But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on…

This is what I did when I was admin of a multi-site WordPress install (over 6,000 individual blogs hosted via this one instance). Too many people wanted their own plugins and themes, so I had to come up with a secure method for updating and controlling what gets inside.

Re: WordPress sites under attack from newly found Linux trojan

#83

Post by quags » Fri, Jan 06, 2023, 10:52 PM UTC

BirAdam wrote: post #46

sschueller wrote: post #10

I don't think linux has anything to do with it. It injects JS code into an existing wordpress site to redirect visitors to spam/scam etc. Any plugin that is allowed to write to disk and has a vulnerability is a problem. "Linux.Backdoor.WordPressExploit.1 is a trojan application for 32-bit and 64-bit Linux operating systems that targets x86-compatible devices. The backdoor is written in the Go (Golang) programming lan…

Yeah, typically, a web server should be setup such that the web servers process runs as say: www-data:www-data, and then the web files should be: joe:www-data and those web files should be 644. In this manner, the web server process can read the files, but the files can neither be written to nor run. This very basic stuff that most of the world seems to ignore completely.

This is a valid and secure set up - and should be considered if you are running your own Wordpress site - but not the standard in shared hosting. Most users are isolated from each other and run php under their user name. A reasonable shared host will have some security set up that will protect their clients, and there are plenty to outsource to. This type of exploit is blocked for example using imunify360 with php defense and the waf rules while allowing php to run under the username.