Warning: Hacking attack on Revo 2.2.4 using "Core Services" plugin

Just wanted to make a record of this in case someone else is affected. Happened on a bunch of MODX Revolution 2.2.4 websites of ours on March 11, 2014. All sites had the same plugin enabled called "Core Services" with the result of a blank page on the frontend (manager still worked fine). The Error Log showed "PHP Parse error: syntax error, unexpected $end" which is what caused the white page/ 500 error.


Code is below and is running some sort of hacking script/file access. I'm still investigating how they got in exactly (I suspect the database as there are no records in the Manager Log or modified files) and will be updating to latest MODX versions to hopefully prevent further attacks.

The "Core Services" plugin code:
[ed. note: twincreekmedia last edited this post 10 years, 10 months ago.]

Same thing happened to me at the same time - I was running 2.2.11 and hadn't upgraded yet. Presumably this is fallout from the security hole that 2.2.13 patches? I have multiple installs on the same server, and only one was affected - the one that runs the high-traffic, high-profile site.

I'm still trying to figure out what happened. I'm not convinced this is a hack.

Let me know what you find out - any insight you have is greatly appreciated. All 3 of the sites that were affected were hosted on the same MySQL Database Server with that plugin added as the last item into each plugin table.

Decoding some of that attack code I found that it embedded the WSO 2.5 PHP Shell. I haven't found any other modified files on the affected server.

OK never mind, it's a hack, of the standard link-spam variety. The reason I was skeptical is that it broke the site - a hacker wouldn't want to be so obvious. After studying the code for a while, I'm convinced that the plugin itself is a hack, but breaking the site was a mistake on the part of the hacker.

The plugin is designed to add links to every page of your site. However, the hacker wanted to be able to update the links dynamically, and apparently didn't want to do that by using an external data source. So the plugin is designed to be self-modifying - that is, if the hacker sends an HTTP request with appropriate GET and POST parameters to any page on the site, the plugin will modify itself and rewrite its own code with new code supplied by the hacker. I'm still not clear on exactly how it gives itself permission to do this, it looks like it's designed to look for an admin user in the users table and then log in as that user. Was that the security breach? If so - wow, that's really bad.

This would have worked perfectly, except that I think the other day the hacker made a mistake in modifying the code, in such a way that the cache file for this plugin causes a PHP error and breaks the site. Maybe the idea was to try to work around the security fix?

Still investigating. The server log should reveal everything that happened, as the plugin is managed by HTTP requests which should show up in the log.

Anyway, it makes me feel a lot better that it was clearly designed for link spam - as opposed to something more nefarious, like zombifying your server.

Interestingly, mine was not the last plugin in the table - it was 14, whereas phpThumbOfCacheManager was 15. I updated phpThumbOf on Feb 18 so that means the plugin was installed before then.

I've probably been hosting this bastard's spammy links for weeks. Grrrr...

The hacker also created a user, called connectorsAdmin with email address f**kyoumodxrevolution2@asdasd'.'ru

By the way - obvious, but if you haven't already, change your database password and delete any spurious users.

Thanks for the heads-up! Looks like he got a bit more "undercover" and created a user called "support" with email support@[websitedomainname] on each site. Content tables look clean.

Yeah, I found that user too. The other one was a clumsy feint... which leads to another comforting thought: this hacker isn't very good, or they would have covered their tracks better. I don't think this is the work of a serious professional. I think this was done for kicks and/or revenge. It's entirely possible that the objective was simply to establish total control over the infected sites, not to actually do something with them.

Then again, maybe that's just wishful thinking, and everything we've seen so far is just cover for a much deeper hack that will persist long after we think we've cleaned it up.

Another random bit of info, not sure if it's useful - the attacker created the users on 3/5 and logged in to one of them once. However, the plugin had been in place since before 2/18.

You probably want to delete that plugin code from this thread and make people ask for it -- otherwise you're providing a blueprint for other hackers to follow.

Most of the hacks I've seen over the past 2 years are not isolated: they all have communicated to other hacked machines in a distributed fashion. More than one of them worked to do click-fraud -- links were popped up and instructions were sent to or received from other infected machines.

The only kosher response here is to restore from a known good backup. It's very difficult to track down payloads on an infected site, and often these backdoors and payloads are bookmarked so their locations are known to the network of hacked machines, and sooner or later a cron process or something will come knocking and try to re-establish access to the machine. You miss one of those files and the whole site/server goes down. It's a bitch to be sure.