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 language and executes attackers’ commands. Its main functionality is to attack websites based on the WordPress CMS by exploiting vulnerabilities in outdated versions of plugins and themes for this platform. If an attack is successful, the webpages of such sites are injected with a malicious JavaScript that redirects website visitors to other sites."
"Linux.Backdoor.WordPressExploit.2 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 language and executes attackers’ commands. Its main functionality is to attack websites based on the WordPress CMS by exploiting vulnerabilities in outdated versions of plugins and themes for this platform. If an attack is successful, the webpages of such sites are injected with a malicious JavaScript that redirects website visitors to other sites. This backdoor is a modification of the Linux.Backdoor.WordPressExploit.1 malicious application. It differs from it in the address of the C&C server, the address of the domain from which the malicious script is downloaded, and its additional list of vulnerabilities to exploit."
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.
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.
> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?
In theory yes. In practice no.
I think a big reason that PHP grew popular years ago was that basically all you needed in order to set up a PHP site on a host was FTP access, and in certain cases DB credentials. For example, case in point, for WordPress you only need FTP and DB access.
Certainly it was the case for me back in the day, when I started learning to program with PHP. I was still using Windows back then and I knew nothing about Linux or any of the other Unix-likes at the time. All I had was my Windows XP computers with XAMPP, and free hosting which provided me with FTP access. Many free hosts would give you MySQL DB credentials also I think.
Cron and things like that would have been beyond my abilities at the time, and beyond what I was given access to by the free hosting companies.
>> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?
> In theory yes. In practice no.
FWIW, after my one and only Wordpress installation was cracked via a vulnerability identical to the one reported in this thread (back in 2010-ish), i did exactly that: made all of the files and dirs read-only to the web user, and made the read/write only during upgrades.
Since ditching that site, though, a couple of years later, WP has remained on my blacklist and i've neither touched it nor recommended its use (and actively recommend against it for anyone who asks because of its long, glorious history of being cracked). To this day, WP is still the only server-side software i've ever run which was cracked from the outside.
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.
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.
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.
When a Virus targets I.E. or Office macros or other software, in general it all gets clumped up as Windows viruses and no one bats an eye.
IMO I think the platform the binary payload is targeting is a valid criteria to characterize a threat, so no problem in calling it a Linux virus, just as we have no problem calling those "Windows viruses".
This is why I shy away from the Wordpress ecosystem. You end up relying on a mass on plugins and you have to just hope they work together and don’t do anything sketchy. I’ve always felt worried by that.
With other open source systems, there are large active repositories involved so you can trust things a lot easier. Although the npm / react ecosystems make me a little worried too, since dependencies are added so causally
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 are connected to sensitive services all without needing even the first comprehension of security. This is its worst feature.
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.
How is that a nice write-up? It's describing the malware as both a backdoor and a trojan, but it's not a trojan and nothing in the description indicates that it's a backdoor. And after reading the write-up it's not even clear to me whether the Go program is running on the same machine as the WordPress (if it is, why does it need to exploit plug-in vulnerabilities? If not, how does the Go program itself spread? Is this where the "trojan horse" part comes in?)
I would agree that the author of the write-up took some creative liberties in applying certain malware category terms like "trojan" and "backdoor" and that it lacks the polish and depth found in other reports from malware reverse engineers.
However it contains enough basic information for a site operator to search their logs and filesystem to see if they have those indicators of compromise. It's "nice" in the sense that someone published the details of an attack quickly and provided some key details to the community, who can expand on these findings or use them in signature-based antivirus detection tools.
I also linked to the Virustotal report which has more information about the go executable including headers, exported symbols and debug information that you can see for free, and which has more detailed analysis for security researchers who have an enterprise subscription.
I wouldn't really call it "creative liberties", I would simply call it misleading the reader. Words mean things, and seeing it described as a "trojan horse" might lead you to think you're safe if you haven't downloaded and run anything dubious.
But I agree that among the BS, there is useful information there. It's worth reading for people who may be affected even if I don't think it's "nice".
What would you consider a misleading about its description of the behavior as a “backdoor?
The write-up describes it as a persistent executable payload and goes on to enumerate the C2 commands that it reportedly received from a remote server, for which some IPs are provided.
Whether or not it’s a trojan depends on how it got onto the system in the first place. There isn’t more information in the article about how the system was infected, but maybe the author didn’t have evidence to share. That doesn’t mean it’s wrong, just that more details would be needed to substantiate that aspect of the attack.
Wordpress is great for rapid prototyping but as history has shown, relying on third parties for additional functionalities in production environments, comes with great risks.
Most usage of Wordpress today are definably not blogs, but full blown websites with many functionalities not found on a blogging software.
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 perfectly fine as long as you maintain your web server platform like any web server platform: with regular security updates and migration or mitigation plans if those updates are breaking anything. Running a website under your own control is not the one-time setup that many WordPress hosting sites promise customers. It usually doesn't take much time to hit the update button, but if you can't spend an hour a week/month making sure your website is still up to date, you shouldn't host your own stuff. Pay someone to manage it for you instead.
> 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 but the community culture still has room to go and there’s a huge discoverability / training gap for all of the people who are just getting started — WordPress is incredibly popular so there’s a constant stream of people who just want to change their site and haven’t thought about all of the different angles for attack.
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.
That's definitely not true in the sense that PHP, even in the latest versions (much less the versions most servers run), still has a lot of the fast-and-lose culture around correctness and things which are pretty uncommon outside of PHP these days such as putting files in a webroot where they're accessible to the world unless you remember to specifically prevent that and do so perfectly, and the endemic problems around aggressive type coercion or optional error handling. In our hypothetical swap for Ruby, Python, etc. those classes of error would either disappear completely or become much less common.
More importantly, however, note that I mentioned the cultural components: people learn bad habits from all of the old tutorials and tons of low-quality code floating around, and there isn't a culture of aggressively correcting that. The half-life on that stuff is a lot longer than the time it'll take to get people to upgrade to PHP 8, especially when more people got some Facebook-style “move fast and break things” ideas without the “… use linters and write tons of tests so you can ship that often” part.
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 things are wrong is by having some trial-and-error experience with the platform. There are a variety of plugin templates floating around, many of them aren't kept up to date, and none of them are designed to guide new plugin developers through all of the process.
- WP core largely allows plugin developers to do whatever they want. There are no built-in guardrails or restrictions on how to do things like handle user input or file uploads. You can choose to use WP's APIs, or ignore them and roll your own. Because of the first issue, developers often roll their own.
- The WP ecosystem is highly commercialized. WP site owners are conditioned to pay for features, and developers are incentivized to build plugins as cheaply as possible and charge for them.
- Stock out-of-the-box WP is basically just a blogging engine. Any other feature you might want to add gets delivered as a separate plugin. Because of the commercialization aspect, it's more common to install 5 different plugins to handle 5 features, rather than one "suite" plugin.
- It's really easy to install a plugin. There's a store. You enter a search term and click "install". Non-technical site owners do this all the time. In an ideal world, that would be really cool, but the downside is that they have no ability to evaluate the quality or safety of different plugins.
- So, most WP sites end up looking like an accreting disk of plugins. I've seen sites with nearly a hundred plugins installed.
- WP has some pretty good auto-update features baked in -- critical updates can be automatically installed and regular automatic updates can be enabled -- but a busted update can still break a site, and because of the commercialization of plugins, license and renewal problems can prevent security updates from getting installed. Because of the a la carte aspect of the WP ecosystem, dependencies can creep in that cause complications with updates. Every agency I've worked with that has WP sites has got some stale or broken updates on one or more of their sites. I've yet to see an agency that has everything fully up to date; it takes dedicated effort to do that, and once the development phase of a site is over and done with, site owners and agencies/developers don't want to continue sinking a ton of money into maintenance. They want fire-and-forget.
- WP has entirely ignored all of the modern changes to PHP development. There's no built-in support for composer. WP is PHP 8-compatible, but doesn't take advantage of its features. Because every WP database contains a hairy mix of configuration, content, and sometimes code, you can't do proper branch development for entire WP sites. There was a project that tried to drag WP kicking and screaming into modern branch development (https://versionpress.com/), but the release of Gutenberg forced these developers to start over and they walked away. This is exactly the sort of problem WP core should be addressing, but they aren't interested.
- This all means that the most talented developers largely want nothing to do with WordPress. Well-managed development processes are extremely painful, there's money in it but the money's better elsewhere, maintenance is a drag, and you too often have to troubleshoot some other plugin developer's conflict with your code.
- Last but not least, there's a "code review" process involved in uploading a WP plugin to their plugin repository, but it's not great. They have some really misguided notions of "security". I worked on a project that integrated a modern code editor into a plugin, which would have been a step in the right direction for managing one aspect of a WP site. (You often need a way to deploy small bits of custom code on a per-page or per-category basis, and managing these little bits of code with existing tooling is terrible.) This update got rejected by WP's security team. We had a lot of back-and-forth about it; their position was that having a modern code editor embedded in the site makes it less secure. They couldn't explain how it was different from any other of the built-in customizations available to site administrators, they just didn't like the idea of it. A plain text box for snippets? Sure! Copy-and-paste random stuff you find on the web? Sure! Using WP core's built-in editor for the functions.php file? Sure! Embedding CodeMirror? No way!
Altogether, it's a really big mess and I don't foresee it ever getting better. WP core can't make any of the big changes that would be needed to address some of these because it would cause too much friction with users, agencies, and the rotten plugin ecosystem.
I've had an arms-length relationship with WP for years, essentially seeing it as a valuable tool for non-savvy people to quickly and cheaply DIY a website, but WP is actively hostile towards modern development practices and after my last exchange with their review team I gave up on the platform for good. Dealing with WordPress hurts my soul every time. I'd rather do anything else.
> 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' and 'log visitor' and 'Fedex' and 'ups' and 'usps' and 'shrink image' functionality are all externalized to different vendors, the 'modularity' of a system requires trusting dozens of disparate development processes, greatly increasing the potential for security problems.
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..."
Absolutely, the WP ecosystem cultivates this mindset.
The reliance on plugins to do a lot of heavy lifting (admittedly, a lot of these stray far from the original blog engine WP provides) but that is because WP is used as more than a blog now, more than a CMS, it's like a core with a myriad of swiss army knife appendages.
It's the same tradeoff with any package ecosystem: improved convenience but less control over the codebase. Leave any JS project alone for a couple months and as soon as you `npm install` you'll see something like "30 vulnerabilities (4 low, 8 moderate, 14 high, 4 critical)"
The core WordPress is one of the most secure software in the world: there are thousands of people trying all the time to find exploits and the codebase is public. Go take a look at what CMS whitehouse.gov (one of the highest-profile hacking targets out there) is using.
> The core WordPress is one of the most secure software in the world: there are thousands of people trying all the time to find exploits and the codebase is public. Go take a look at what CMS whitehouse.gov (one of the highest-profile hacking targets out there) is using.
While I believe the core is reasonably secure, lots of plugins and webhosts aren't. Simply making the website code read-only would take care of a lot of issues, but then your auto-update won't work.
You can make the the code read-only (from the web-server's perspective) and have auto update if you use a tool like WP-CLI and a cron job.
I've had a few customer's sites on WP for decades without any hacks. But I also carefully restrict their plug-ins, and disable PHP in any of the upload directories.
The idea of tons of 3rd-party plugins, with WordPress and also Drupal, is just disastrous for security.
Anyone with any ability to write a little PHP would be far far better off building their site in a CMS like ProcessWire [1], which has a very small core, but a extremely powerful content (PHP) API [2], which means you can replicate pretty much everything you have in Wordpress and Drupal with a few API calls in your templates.
This means you build your listing and presentation-logic custom made with the minimal amount of code needed, and the attack vector shrinks to pretty much nothing, as long as you don't voluntarily do something stupid.
I'm not understanding how this is a trojan. Is it a plug-in which the admin has to install? Is it some other unrelated application which the admin has to download from the web and run which infects WordPress sites? How do the 30 vulnerabilities fit into this?
And what part of it is a backdoor? It looks like the C&C server can only tell the software what page to redirect to? That's not the sort of access I generally associate with a "backdoor"...
After my experience running a WordPress blog back in the mid-late 2000s, I swore off of it. Even with the meager traffic I got I saw a constant barrage of linkfarm exploits and the like that occurred with even the most brief lapses in keeping WP up to date.
Haven't had a blog in about a decade, but when I spin one back up it'll be with a static generator like Zola[0] running on a provider like Netlify[1]. Comments are nice to have but not worth the hassle that comes with a dynamic app or the moderation overhead required to keep comment spam at bay.
I think it's to prevent virus scanners from detecting the IP listed in the web page. If your (super aggressive) AV engine has been updated to include these IoCs and you're just trying to read more about this virus, you don't want it to trigger a block.
Is there any good literature discussing the rise of server malware? It seems to me it's much more common now and PC malware (regardless of OS) is more rare.
Interesting choice of words at a time when you can't even rely on all major distributions to provide x86-32 builds anymore.
Of course, there are still based distros that won't forcibly obsolesce hardware that isn't even a decade old, but you have to know them and can't just assume it's supported anymore.
Yup. I don't know what kind of mentality wants to punish users for rejecting ads. I guess you have to take the view that the ads are more important than the content.
But what does that say about the content? To me, it says that the content is worth even less than the ads I'm already deliberately blocking.
Many companies seem to put the company website under the control of marketing. That's OK, until the marketing department goes megalomaniac, and decides that all company operations amount to marketing. So much for the website.
> It exploits 30 vulnerabilities in a number of plugins and themes for this platform. If sites use outdated versions of such add-ons, lacking crucial fixes, the targeted webpages are injected with malicious JavaScripts. As a result, when users click on any area of an attacked page, they are redirected to other sites.
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 bit tricky, but the sites I've deployed it with usually don't have many of them.
For tech-oriented people, yes, static site generators can be quite great.
For non-tech people? There's the reason why Wordpress is so popular: you can either use any of the tons of "hosted Wordpress" providers or throw it up on some cheap ass LAMP virtual server, hell even most providers' FTP space is usually enough. There are tons of themes, tons of plugins with integration to pretty much everywhere, and tons of anything from freelancers to huge media agencies to help you out.
Like it or not, Wordpress is the equivalent of English. Almost everyone relevant sans the French speaks it.
I think they added some detection to block archiving tools and as such some addons will break the site, or perhaps better wording on my part would be that the site will break some clients.
This is a valid question, but the answer is somewhat simple. The open source code is both widely used and easily studied. Because of this, it gets targeted. As it can be studied, the vulnerabilities are both known and talked about. In the case of proprietary software, the owners are neither going to be quick to admit a problem exists, nor quick to allow study of their system(s) to discover the cause (in most cases, exceptions to this obviously exist).
Security vulnerabilities are everywhere, but only in widely-used open source code is the discovery of a vulnerability likely to be both known and discussed.
And it's almost always older versions of plugins that are vulnerable; however, at some point a plugin update will break the website and then you don't upgrade because there's more important things to do ...
It's the dependency loop of Wordpress really - people can't update the core because their plugins don't work with new core (yet, sometimes never), so their (outdated) core remains an exploit.
The core main task is execute millions of actions/hooks offered without any control to be exploited by plugins. So "not hacking the core of wp" is really "hacking the core of wp"
Well, I would argue that one should write a web framework if he/she wants to do so. There is no other reason really.
Running anything on the web has risks, some more than others. Likewise, there are tradeoffs to any given plan.
Wordpress itself isn't some terrible thing, but an outdated version with 100+ plugins that is poorly administered is likely to be an unauthenticated root shell that happens to also function as a website. This is true of any web framework though.
"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 language and executes attackers’ commands. Its main functionality is to attack websites based on the WordPress CMS by exploiting vulnerabilities in outdated versions of plugins and themes for this platform. If an attack is successful, the webpages of such sites are injected with a malicious JavaScript that redirects website visitors to other sites."
https://vms.drweb.com/virus/?i=25604695
"Linux.Backdoor.WordPressExploit.2 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 language and executes attackers’ commands. Its main functionality is to attack websites based on the WordPress CMS by exploiting vulnerabilities in outdated versions of plugins and themes for this platform. If an attack is successful, the webpages of such sites are injected with a malicious JavaScript that redirects website visitors to other sites. This backdoor is a modification of the Linux.Backdoor.WordPressExploit.1 malicious application. It differs from it in the address of the C&C server, the address of the domain from which the malicious script is downloaded, and its additional list of vulnerabilities to exploit."
https://vms.drweb.com/virus/?i=25604745