Pharma Hack

[POWERFULHORSE]

A site I manage has been compromised by the "pharma hack". I'm trying to determine if a vulnerability in ProcessWire has been exploited or if the problem is with the site's webhost, but not really sure where to start. Has anyone else come across this before?

[cstevensjr]

The quick answer, Regardless of the hack, if you are using shared, VPS or even dedicated server hosting, even ProcessWire can be affected.  

If the site that you manage is using the same user account and/or on the same virtual/physical server as a compromised WordPress or Joomla site, any compromise  can indeed affect the ProcessWire installation.

If there are no old/new WordPress or Joomla  installations under the situations I described and you are having this problem, then yes there may be an issue with ProcessWire.  Please let us know if this is the case, however I doubt if it is, since we would have already seen this occur in other ProcessWire installations worldwide.  PHARMA is an old hack, but it doesn't mean it hasn't been updated.

Either way, you need to work with the security team at your webhost to identify and mitigate any issues.  Please keep us informed on your progress clearing this issue up.  

Best Regards,

Charles

[POWERFULHORSE]

Thanks for this Charles. It does indeed seem that the situation is what you've described in your post. The client's site is hosted on a shared hosting package and I'm assuming some other site has been compromised. I identified the problem as a single php file, "upgrade.php" that was in the root public_html folder, was around 6k. I deleted this and it seems to have fixed the problem. I'm assuming from this that it's not an issue with ProcessWire, as I know the WP/Joomla exploits inject code into locations/files specific to those installations.

I'll keep an eye on it to make sure it doesn't return, and will get in touch with the webhost.

Thanks again.

[DaveP]

I recall back in the days I was using Joomla (or it might have been as far back as Mambo), and I installed a file explorer type plugin, which immediately gave me access to every hosting account on that server! Needless to say I soon moved away. While that was a long time ago, there are clearly some servers are still badly misconfigured and it pays to be vigilant.

[ryan]

upgrade.php is not a ProcessWire file. I'm guessing maybe it was a leftover from a previous WP or Joomla install? It sounds like it could be related to the exploit you experienced, but be careful not to assume it ends there. 

ProcessWire's core does not have very many input opportunities on the front-end of your site. Actually, the URL itself is really the only input ProcessWire deals with on the front-end, and that is validated by the htaccess before being sent to PW, and then thoroughly sanitized then validated again by the core. As a result, it's unlikely for ProcessWire itself to be exploited in the same ways that some other CMSs might be, simply because there are a lack of input opportunities to a guest visitor. What ProcessWire does instead is give you an API that lets you control all the aspects of when user input results in something output. If there were to be an exploit on a particular PW site, it would be much more likely to be the result of the code unique to that site, or a 3rd party module, rather than PW itself.

If you were dealing with a site that had other software running, either presently or in the past (perhaps WP powering a blog alongside) then it'd be much more likely for that to be the source of the issue than PW. In fairness to WP, most exploits have to do with 3rd party WP plugins or themes and not WP itself. WP and Joomla are also much larger targets than PW, so they are usually broken into with automated scripts rather than actual people sitting at their computer. 

When you've got a site that you know has been broken into at the filesystem level (like yours might have been), it's unusual for it to be limited to just one file. There are usually backdoors built elsewhere. Even if the site is fixed for the moment, it's good to still think of everything as tainted until proven otherwise. I'm not necessarily a fan of restoring from a backup in this case, unless you know for certain that the backup itself does not contain the exploit. Sometimes a backdoor will be present for months before taken advantage of. If you had Joomla running on this server a long time ago, the exploit may have originated there and simply been hidden somewhere on the file system. 

The first thing you'd want to do is remove any other software installed on the server that doesn't need to be there–old copies of WP, Joomla, etc., or files leftover by them. If you aren't certain, then just move it to a non web accessible quarantine directory. For your ProcessWire site, you don't need anything in your web root directory except for: /wire/, /site/, /index.php and .htaccess. 

Remove your entire /wire/ directory and put in a new fresh copy, as well as your /index.php and /.htaccess file. Basically do the same thing you would do if performing an upgrade. 

In /site/modules/ you may have some 3rd party modules installed. Replace each of the directories in /site/modules/ with fresh copies. This is the same thing you'd do if upgrading those modules.

That essentially leaves /site/ and everything in it to analyze. If the hack originated from an automated script targeting DrumlaPress, chances are it left your PW installation alone, but you never know–it might have gone after every single PHP and JS file it could find on the file system. You'll want to look for anything unusual in your /site/templates/*.php files and /site/config.php file. By unusual, I mean anything that you didn't put there. Start by looking at the beginning and ending of each file. Red flags are usually extra <script> statements, base64 function calls, exec function calls, extra JS attributes on markup elements that you didn't put there (like onclick), include or require statements with variable names in them or referencing files you don't recognize. Also consider that new directories may have been introduced anywhere. I would download a copy of your entire /site/ structure and analyze it locally, looking for any extra files or directories that you didn't put there. Also be on the lookout for extra .htaccess files, and give them a close look if you find any. Meaning, you'll need to make sure you are seeing hidden files (those preceded with a period). Compare your /site/ structure to a /site-default/ structure as included with a new copy of PW. 

Once you've cleaned your /site/ directory or at least verified that it's clean, make a good backup of your site so that you've got a known clean starting point (hopefully). Open a browser to your site with Chrome and go to View > Developer > Developer Tools. Click to the "Network" tab. Reload the page. Look for any offsite requests that you don't recognize. That may reveal something hidden that might still need to be cleaned, but hopefully not. Now click to the "Elements" tab. This shows the post-JS markup of your site. Look for any generated elements that you don't recognize, especially at the end or beginning. This again can reveal extras that have been added into your page by an exploit. 

Lastly (or maybe firstly?), take a look at your file permissions. If on a shared host, you want to be certain that your files aren't readable or writable to other users on the same server. Especially your /site/config.php file, and your /site/assets/ directory (and everything below). What permissions are ideal here depend on the web host and what type of PHP they are running, so it's best to inquire with them on how you can have files writable to your website that aren't writable by other accounts. 

Btw, I have never seen or heard of a compromised PW installation, regardless of what other compromised software was running on the server. I have seen plenty of compromised WP installations that had PW running alongside them. Thankfully, the PW installation has always been left alone, with the exploit limited to the WP installation. But it's best to go into these things assuming everything on the server is tainted, so always play it safe. 

[muzzer]

Wow, very thorough instructions Ryan. As you say it's unlikely PW will be exploited in a DrumlaPress manner, but still, this is a really great writeup largely relevant to cleaning any hacked website. Should perhaps be pinned?

[POWERFULHORSE]

Thanks for such a detailed writeup Ryan. I've been through almost every item on the server and it seems the problem was limited to that single php file in my case, but still a hugely helpful post that I will keep bookmarked. My initial hunch was that it wasn't PW that had been compromised, I'm now certain the problem was down to the shared hosting package the client is using.

[RyanJ]

The site does not happen to be hosted on GoDaddy does it?

[POWERFULHORSE]

Nope, tsohost.

[RyanJ]

GoDaddy hosting had a similar issue not too long ago with what you described. They of course never admitted fault, but coincidentally, every WP site that was affected just happened to be hosted on GoDaddy. I had a client site that was affected numerous times. I cleaned up the affected files and two days later it was there again. I moved the cleaned site to a new host and never had the issue again. *knocks on wood*

[Craig]

It might be worthwhile contacting tsohost to see if they can identify the cause or route that was taken.