As I’ve gotten involved with helping the WordPress.org theme review team, I’ve seen some strange things. One of the stranger ones was a theme virus that actually propagated from one theme to all others in a WordPress installation. That one was awfully clever, but it ultimately didn’t really do anything but propagate and generally be a pain in the ass.

However, today, @chip_bennett discovered that one of his themes had been copied and was being redistributed by a site called top-themes.com.

It had malware inserted into it that is of a much more malicious and spammy nature. Further investigation reveals that ALL of the themes on that site contain basically the same code. This code is not actually “viral”, but it’s definitely malware and it’s worth investigating to see some of the ways people try to hide their spam.

So today, I’m going to dissect it and serve it up on a platter for everybody to see.

Infection Point

We’ll start with the most obvious starting point, and that is in the functions.php file. At the very end of the functions.php file, we find a call to “get_custom_headers();”. An innocuous enough sounding name, so we go find that function. Here’s the first part of the function:

Right away, something is wrong. It’s getting the location of the screenshot file (DS is defined elsewhere as the Directory Separator, which makes it work on both Linux and Windows boxes). That doesn’t make a whole lot of sense, the screenshot is supposed to be displayed by the admin interface only. Let’s read on.

The “pack” function is one that isn’t used much. It’s a means of manipulating binary files. The “explode” function is a way of splitting a string by some characters. So what this code really is doing is to find a particular string of hex digits in the screenshot file, split it across that boundary, and then get only the first part of that (the actual screenshot file), thanks to the array shift. This gets used later.

In other words, he’s appended something onto the end of the screenshot file, and this code reads it in, finds it, then gets a copy of it. What could this be? Turns out to be a ZIP file.

If the zip_read function is available, he makes a wp-additional directory and puts the ZIP file there. Then he simply unzips the malware file into the target theme. This requires a bit of explanation.

Elsewhere there is a function called “find_writeble_path”. This function doesn’t limit itself to the current theme’s directory. Instead, it looks through all installed themes on the system and tries to find all themes that has permissions set to allow it to be written to. So in all of the above, he’s really looking for any theme that he can infect with the malware contained in this archive. The “array_shuffle” line is his way of picking a random theme.

So he unzips the malware to that theme then adds code to himself to that makes it try to read and execute this wshell.php file.

But if the wp-additional directory full of malware has already been created somewhere on the system, then the above code doesn’t run. If it finds the malware directory, then it skips that and just does the following:

This code reads the file that the malware code is in right now (with file_get_contents(__FILE__) ). Then it explodes it along the get_custom_headers function. Finally, it writes it back out to the file itself.

Basically, using the explode and array_shift method, it finds the get_custom_headers function code, then writes the functions.php back out without that code or anything after it. Now that the malware has done its job, this code basically self deletes, to make it not traceable. All that’s left is the wp-additional directory that contains the malware, and the include it wrote to the beginning of the file to load that malware.

Here’s where it also erases itself from the screenshot, using the $screenshot variable it saved earlier.

This just makes it load the now-decompressed wshell.php malware immediately, instead of waiting for the next page load.

Also note how the code doesn’t run on localhost installs? If you look closely, the self-removing code does run on those installs. Meaning that if you run this theme in a test bed, then it removes itself without infection. This is to make it harder for people to analyse the code, since it disappears the first time you run it on a local test system.

The Malware

So what is this malware? Well, there’s two parts to it.

The first part is a standard PHP Shell install, essentially giving a shell backdoor to anybody who knows the location of the malware and the username and password. This is a massive security hole, obviously.

The second part is somewhat custom. It’s in the wshell.php file that the above malware tries so hard to get you to include. Essentially, this installs a spamming system of fairly wide ranging scope.

The first thing it does is to notify its master that it exists. It does this by making a connection to 188.165.212.17 and sending what looks sorta like SMTP commands, but which are probably customized in some way. But basically it tells this server where it’s installed and how it can be accessed. After it gets confirmation, it sets a parameter to make it not send this again.

The spamming system itself contains a number of commands. The way it gets commands from the attacker is by looking for them in cookies with a name of “wsh-cmd”. So in this sense, it’s kind of like a server. The attacker has some kind of a client that talks to your server via the normal HTTP, but sends it hidden commands via this cookie.

The commands allow the attacker to view a list of writable files in your themes directory, and to view any specified readable file on the system. It avoids triggering mod_security systems by base64 encoding files that it sends around. But the main thrust of the system is to allow the attacker to insert links into, and remove links from, any writable theme file.

Essentially, it’s a remote-controlled automated link spamming tool.

The attacker can send URLs to your system and it will insert them into theme files. He can later remove those links. There’s a lot of code to allow it to generate proper links, to insert them into specific lines, things of that nature.

Summary

Also, this sort of thing should tell you why we ban certain types of things from the WordPress.org theme repository. We can’t scan for specific malware, as it’s too easy to get around that sort of scanning. Scanning for functions that most of these malwares use is simpler and more effective. And all of our themes go through human-eye review as well, with anything even slightly dodgy getting brought up before a mailing list of experts who can take a look and determine what is what.

It is sad to see themes being used to distribute this garbage. Some of the steps used to hide that garbage are pretty clever though. Imagine what this person could do if they choose to use their powers for good!

Excellent post Otto. Thank you for sharing this valuable knowledge! I’ve been using the same theme forever (which I made and probably need to upgrade to 3.0+ compatibility haha), but I have a lot of friends and clients that use WordPress, I will be sure to pass this along!

No matter how well hidden, eventually a “payload” has to turn back into code and be executed.

Has anyone considered using an automated-test approach?

1) Load a WordPress install and the theme into some kind of test rig, based on the code at: svn.automattic.com/wordpress-tests/
2) Generate hash values for every file in the install, including the plugin files.
3) Have the test code visit every page on the “site” and record the HTML produced.
4) Parse the captured HTML, looking for links that shouldn’t be there.
5) Re-hash all the files in the install, and find any that have changed.

And if anything “bad” is discovered, refuse the template.

Much of the code needed to do this stuff is already built! …see svn.automattic.com/wordpress-tests/

It raises two issues, though. One from a non-too-technical perspective, the other from a more technical one.

The range of approved themes available via WordPress is not exactly what you’d call impressive and the majority look like they were designed back in WordPress 1.0 days. That pushes people like me into the wider marketplace.

Why not build Theme Check into the next service release of WP, not just be available as an option. It would then become a sort of charcoal filter for code before it was installed.

It would be great if some form of anti-virus could be included in core to protect end-users, but sadly I doubt this will happen. I have a bad feeling Matt would rather use this as part of his long-running crusade against non-GPL themes. It’s in his interests to scare people off downloading themes from third-party sites. I really hope I’m wrong, as in reality most users neither know nor care about malware or licensing issues, and hence aren’t going to protect themselves.

Also, it’s so hard to get a theme into the official directory these days, I’m not surprised most of them are by code monkeys rather than graphic designers and that their aesthetic qualities reflect this.

If there was some kind of malware checking in the core, then these spam authors would simply write their code to not be detected by it. There’s an infinite number of ways to hide things like this, you simply can’t catch them all and it doesn’t make any sense to get into an arms race over it.

Simply educating users about only downloading themes from trustworthy sites should be enough. Perhaps it isn’t.

Also, getting a theme into the official directory is a lot simpler. Use the Theme Check plugin and fix the issues it lists before submitting your theme and it will be a lot more likely to pass review.

This is no longer merely about a crusade against non-GPL Themes (although that, too, is an issue, since most of these sites also mis-apply licensing). This problem transcends the GPL-only issue. Users who look outside of official channels in order to find free WordPress Themes will get compromised Themes.

Also, I disagree completely that getting a Theme into the repository is unduly onerous. It might take a while, but that is a function of having an insufficient number of Theme reviewers.

This problem transcends the GPL-only issue. Users who look outside of official channels in order to find free WordPress Themes will get compromised Themes.

Well, if GPL were not such a religious issue then people wouldn’t be being driven beyond the official repository to find themes, because wordpress.org would be open to a much wider range of work. It would be possible to vet non-GPL theme developers and link to reputable ones from wordpress.org, in the same way as currently happens with commercial themes. Security ought to transcend GPL-zealotry, but, again, I’m not convinced it will.

And as for getting into an arms race, I was under the impression that was an inevitable consequence of trying to deal with spam and malware. It’s all very well to say that people who go off-piste looking for a theme forfeit the right to protection, but you need to bear in mind that if they do get hacked, they’re probably going to blame wordpress rather than their theme, and ultimately that’s going to be bad for wordpress.

WTF are you talking about? This has nothing to do with the GPL at all.

If you don’t want to release a theme you created under the GPL, then don’t. That has nothing to do with spam and malicious software.

And no, we’re not going to allow non-GPL software onto WordPress.org. In fact, we go even further and don’t allow any *paid* software onto WordPress.org either. WordPress is free and it will remain so.

If you want to play in the sandbox with the other kids, then you obey the rules like everybody else does. That’s not zealotry; that’s standing by a set of principles.

If you don’t want to release a theme you created under the GPL, then don’t. That has nothing to do with spam and malicious software.

Then maybe you guys should stop running around claiming that any free theme not hosted by wordpress.org is going to compromise your wordpress install. As far as I can tell, the problem is with third-party repositories collating themes by a variety of authors and injecting their code into it. Do you have any examples of a theme obtained direct from the author which pulls this crap? I’d genuinely like to know.

In fact, we go even further and don’t allow any *paid* software onto WordPress.org either

um, what about http://wordpress.org/extend/themes/commercial/ ? I wasn’t talking about hosting (I wouldn’t presume to tell Matt what to put on his servers); I was talking about linking, and how it might help to keep people away from disreputable sites by directing them towards trustworthy ones.

It’s just massively illogical to equate somebody like Sadish (who has been doing this for years, has a theme in use on wordpress.com and distributes only through his own site) with the second-hand theme warehouses which exist only to propagate spam. If the ‘non-GPL = evil’ mindset is just too deep to overcome and there’s no way you can tell people what third-party sites they can trust, could you not at least publish some form of watchlist advising users which sites to avoid?

I’m sure you know my opinion on the GPL-inheritance issue; that said, I have no problem whatsoever with the WordPress.org Theme Repository requiring hosted Themes to be 100% GPL-compatible.

To be honest: I have yet to find a non-commercial Theme submitted under a non-GPL license that wasn’t compromised in some fashion. Most Themes that are GPL generally wind up in the Repository (that backend-search exposure is a pretty darn big incentive). The one exception I’ve found is Leland’s Themes at ThemeLab. I don’t know if I would trust any other extra-repository, free-Theme distributor.

Given the state of the free-Theme environment right now, I am fairly confident in saying: buy a commercial Theme from a reputable developer, or get a free Theme from within the WordPress.org Repository. Anything else, and you will almost certainly get a compromised Theme.

I’m wondering if it would be possible to develop some sort of WPORG-hosted digital-signature database against which to verify Themes?

Outside of that, Theme developers are going to have to start looking at registering their Theme names as Trademarks, and then enforcing those Trademarks. Unfortunately, this route is very likely prohibitively expensive for free-Theme developers.

Nice analysis! And I didn’t even realize that PHP had a pack() function, though I’ve used it a lot in Perl over the years. I used to use it for formatting binary data to send/receive data to a mainframe interface on a trucking company website

Anyhow, that’s definitely a clever, devious, smart bit of ugliness there. If only the author would use his powers for Good!

[…] Theme loaded with malware was uncovered. Otto wrote up a dissection of the Theme in “Anatomy of a Theme Malware,” giving programmers, developers, and WordPress Theme hosts an inside look at the insidious […]

[…] old adage: “Too good to be true”, plays out in the inter­net world as well.Here’s an excel­lent expla­na­tion of how spam­mers use Word­Press theme to spread their malware.How do you avoid get­ting Word­Press Theme malwareAlways get free theme […]

I just still wondering why top-themes(http://www.top-themes.com/) still active.I tested to download some of the theme and it still have the blocks of functions/codes there.They can distribute those themes with malware if they can still operate.If all of the themes on that site contain basically the same code, why wordpress allow this site to continously distribute infected themes.

How do you propose for “WordPress” to disallow such sites from distributing infected Themes?

If such sites are violating the WordPress Trademark policy regarding domain names, then the WordPress Foundation has some recourse to take down trademark-violating domain names. Otherwise, WordPress has no more recourse than anyone else.

FYI, I contacted the registrar for top-themes.com, and got no response. I also reported the site to Google, and also got no response.

[…] Additionally, this malware sends notification to its creator about it existence on a server and allows him to insert links on writable theme files on a wordpress installation. Otto, the coder of my Gravatar Hovercards plugin, wrote a post called Anatomy of a Theme Malware where he explains the nature of this malware. Read here […]

[…] specifically WordPress Themes, Plugins, and out-of-date versions of WordPress. WordPress expert, Otto of OttoPress investigated a WordPress malware hack last year, uncovering the insidious methods they use. Having had two of my sites and a few […]

[…] and redistribution. However, these Theme modifications turned out to be insidiously malicious. As Otto explains, Themes distributed by the site in question had been hacked to (among other things) include a […]

[…] malware and it’s worth investigating to see some of the ways people try to hide their spam.via Anatomy of a Theme Malware » Otto on WordPress.Now, this is not intended to imply that all WordPress theme download sites are bad, or that you […]

It is good to find out that top-themes.com website is not providing anything regarding WordPress.

Otto are you responsible for ensuring the top-themes.com shuts down? If so congratulations! This is perhaps, the best way to tackle such people who are spreading malware by providing infected themes for download.

Thank you for the post as it is very helpful for WordPress Developers like me.