Live data from Hacker News

WordPress sites under attack from newly found Linux trojan

darkreading.com

51–60 of 83 posts

Re: WordPress sites under attack from newly found Linux trojan

#51

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…

> I don't think linux has anything to do with it.

The title is accurate, but I think a lot of people are objecting in comments here due to a general conflation of two separate concepts:

1) An exploit or vulnerability

2) A virus or trojan

An exploit/vuln is a bug in software (Wordpress in this case) that allows unauthorized access - a virus/trojan is an app with malicious intent: one typically needs to take advantage of an exploit (or social engineering) to install & execute said app. Like any app, it's generally developed for a specific platform (in this case, Linux).

---

TL;DR: The Wordpress exploits are known - the news in this article is about a specific Liunux app being deployed using those exploits. The bugs in Wordpress are not the news.

Re: WordPress sites under attack from newly found Linux trojan

#52
post #46

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.

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.

Re: WordPress sites under attack from newly found Linux trojan

#53
There is a nice writeup about the exploit which includes more information about the indicators of compromise (IOCs) on the (drweb) site:

https://vms.drweb.com/virus/?i=25604695

For example, the binary file has a SHA1 of 215a4470063080696630fb6015378938e8c16a15. It reaches out to a C2 server with the IP address 109[.]234.38[.]69. It injects a script called "lone.js" which contacts another server. Etc.

Someone has also submitted it to Virustotal very recently, and there is additional information available to explore. https://www.virustotal.com/gui/file/7ab779b39a7ff2a8e4e4957e...

Yara is among the tools which can be used to search a system for these IOCs provided a set of rules written in the appropriate syntax.

Re: WordPress sites under attack from newly found Linux trojan

#54
post #15

Earlier quoted context omitted.

Do you need a cow the WordPress is, for a blog? Static Site Generators like Hugo or Jekyll work great.

I've been a fan of the 'simply static' plugin for wordpress for a few years now. Basically, install wordpress on a server, make it accessible only to authorized users (vpn, acl, htauth, whatever works best for you), then have it deploy to an apache server or s3 bucket. The WP designer feels at home. Has a simple deploy button. The pages load significantly faster. Works well most of the time. Sometimes forms can be a…

I know that it seems like a great place to plug your favorite plugin but my point is:

Why run WordPress to serve static site when you have SSGs?

Re: WordPress sites under attack from newly found Linux trojan

#55
post #34

Earlier quoted context omitted.

I wasn't surprised to read that once again the plugins were the cause of the security issues. I don't know what the dynamics are for WordPress plugin developers to write this much vulnerable code, but WordPress itself has had very few vulnerabilities over the years. Even still, the vulnerabilities this plugin exploits have CVE numbers starting with 2016 and 2019. I'd say that you can use WordPress for websites perfec…

> I don't know what the dynamics are for WordPress plugin developers to write this much vulnerable code, but WordPress itself has had very few vulnerabilities over the years. I think it’s a microcosm of the larger PHP problem: it’s a language and environment which is really easy to get started with, but requires significant skill and experience to use safely. The core developers of both have made some improvements bu…

WordPress's problems have nothing at all to do with PHP. WP is currently lagging PHP best practices by about a decade. You could in theory swap all the PHP out for, I dunno, Ruby, and if the WP architecture didn't change then it would still have all the same problems.

Re: WordPress sites under attack from newly found Linux trojan

#56
post #36

This article is written so badly.. I suspect it could be a ChatGPT or some variant.. > which targets 32-bit versions of Linux and also can run on 64-bit versions of the platform. I don't fully understand what they mean by this.. > Vulnerabilities are not uncommon. Pointing out the obvious here. But in general Wordpress has a high surface area of attack sure, but it allows bad 'developers' to publish websites which ar…

Agreed, it told me precisely nothing.

Re: WordPress sites under attack from newly found Linux trojan

#57
post #46

Earlier quoted context omitted.

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.

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?

Re: WordPress sites under attack from newly found Linux trojan

#58
post #34

Earlier quoted context omitted.

> I don't know what the dynamics are for WordPress plugin developers to write this much vulnerable code, but WordPress itself has had very few vulnerabilities over the years. I think it’s a microcosm of the larger PHP problem: it’s a language and environment which is really easy to get started with, but requires significant skill and experience to use safely. The core developers of both have made some improvements bu…

WordPress's problems have nothing at all to do with PHP. WP is currently lagging PHP best practices by about a decade. You could in theory swap all the PHP out for, I dunno, Ruby, and if the WP architecture didn't change then it would still have all the same problems.

A decade is being kind of generous. But your comment is spot on.

Re: WordPress sites under attack from newly found Linux trojan

#60

Earlier quoted context omitted.

There are a number of challenges that, together, are specific to the WordPress platform: - WordPress's documentation for plugin development is not great, especially for new plugin developers. Somebody recently posted a link on HN to a small WP plugin they had developed, and it took only a few minutes to spot several things that were a bit wrong with their plugin. It wasn't their fault; the only way to know these thin…

> So, most WP sites end up looking like an accreting disk of plugins. I've seen sites with nearly a hundred plugins installed. I took over a site - woocommerce install - with ... 68 plugins. When I've mentioned that over the years it's almost always met with "no, that's not right - no one does that - you don't know what you're talking about - they did it wrong"... etc. Thanks for reiterating this. When 'redir ssl' an…

Yep. Here's a recipe that'll get you a buttload of plugins every time: a WooCommerce site with coupons and physically shipped goods, mixed with article content, built and managed by an M&A agency, on budget hosting.

Akismet, WordFence or iThemes "Security", Contact Form 7 (and its extensions), WooCommerce (and its pile of extensions), one (or more!) page builders, WP Super Cache, Yoast (and related), a sidebar widget, a chat widget, a Google Tag Manager widget, social media plugins...

The M&A approach to WP development is often, "it's broken, let's see if we can fix it by installing a plugin..."

Post reply on HN