An old piece of malware is storming the WordPress community, enabling its perpetrators to take control of sites and inject code of their choosing.
According to WordPress security company Wordfence, which published a detailed white paper on the malware earlier this week, WP-VCD isn’t a new piece of malware. It dates back to February 2017, but it has recently become even more successful. The company says that it has topped their list of WordPress malware infections since August this year. New features have been added to the malware, but its core functions have remained the same.
The malware spreads through pirated versions of WordPress themes and plugins that the attackers distribute through a network of rogue sites.
If administrators looking for free WordPress functionality download these assets and use them in their own WordPress sites, then they’ve essentially infected their own servers.
This is an ingenious attack vector because the criminals distributing the plugins don’t have to worry about finding new exploits in WordPress code or hacking legitimate extensions. Instead, as Wordfence explains, the crooks are exploiting human greed:
The campaign’s distribution doesn’t rely on exploiting new software vulnerabilities or cracking login credentials, it simply relies on WordPress site owners seeking free access to paid software.
Once it has infected one site, the malware then installs a backdoor for its operators and communicates with its command-and-control (C2) server before spreading to others hosted in the same infrastructure. Finally, it removes the malicious code in the installed plugin to cover its tracks.
The backdoor lets the attackers update the site with new malicious code, which makes money for its criminal peddlers in two ways. First, it uses search engine poisoning techniques to manipulate search results and lure unsuspecting users to malicious sites.
Why has the WP-VCD WordPress malware been so effective? Wordfence explains that its attackers can use infected sites to propagate their malware:
Malvertising code is deployed to generate ad revenue from infected sites, and if the influx of new WP-VCD infections slows down, the attacker can deploy [search poisoning] code to drive up search engine traffic to their distribution sites and attract new victims.
The WP-VCD malware is tricky to clean because it injects malicious code into other files on the system, and keeps an eye on infected files to reinfect them automatically if the admin tries to clean them up.
What to do?
Naked Security’s plugin advice for WordPress administrators is:
- Minimise the number of plugins you have. Always remove plugins if you aren’t using them any more. Keep your attack surface area as small as you can.
- Keep your plugins up to date. Blogging software such as WordPress can keep itself updated, but you need to keep track of the plugins yourself.
- Get rid of plugins that aren’t getting any more love and attention from their developers. Don’t stick with ‘abandonware’ plugins, because they’ll never get security fixes.
- Learn what to look for in your logs. Know where to go to look for a record of what your web server, your blogging software and your plugins have been up to. Attacks often stand out clearly and early if you know what to look for, and if you do so regularly.
Oh, and don’t steal software.
Technically, there’s no reason why pirating software should be more dangerous than acquiring it lawfully – an exact copy is, after all, an exact copy. But the shady nature of rogue software download sites means that the only thing you can be sure of is that you’re dealing with crooks.
2 comments on “WordPress sites hit by malvertising”
“Oh, and don’t steal software.” You cant steal GPL software, it’s open source.
if we adopt a non-technical definition of “stealing”, and take it as meaning to “rip off and use unlawfully”, then you certainly *can* steal GPL software. (You can even rip off software that’s under a more liberal BSD or MIT licence, if you take it and use it in violation of that licence.)
Most importantly, the GPL strictly requires that you publish full source code of any project in which you incorporate even the tiniest amount of GPL-licensed code. Simply put, you can’t bury GPL code in a closed-source project and keep the whole thing closed. That’s particularly relevant if you use, say, the Linux kernel in your latest $10 webcam firmware. You then have to publish the code of your whole firmware – something that companies sometimes ‘forget’ to do in order to discourage bug hunters (perhaps because they are scared of what might show up in even a basic security audit) or to complicate the job of modifying the firmware yourself. Technically and legalistically, a company that does such a thing hasn’t “stolen” the software, but in common parlance I think the word fits well enough, in the same way we talk about having a car “stolen” when what we really mean is that a crook “took it without consent”.
Of course, the existence of an entire class of software that can’t be “stolen” (e.g. anything in the public domain, such as SQLite) doesn’t invalidate the advice “don’t steal software” :-)
The other side of the “free software” coin is that, although free software means there is never any purpose in crawling around in the underbelly of the Internet of Pirated Stuff to find it, the mere fact that it is free doesn’t magically make it secure, thus our other warnings about watching out for software, inlcuding free software, that has essentially been abandoned by its developement team and isn’t getting any cybersecurity love any more.