ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Bad 1.7.1 build number seems related to hacked site

June 10, 2011 10:21am

Subscribe [7]
  • #16 / Jun 14, 2011 4:34pm

    spacewalk

    106 posts

    I’ve sent yet another request for help to Dreamhost but no reply so far.

    To clarify: *what* strikes you as a good indication that the attack is coming from somewhere else? The replacement of the file “core.system.php”?

    I was thinking the opposite: that it suggested that a hacked file was being stored somewhere in the hosting account and periodically moved into the system folder (which is NOT named “system” on my EE installation).

    It’s definitely a file replacement. My current 1.7.1 build 20110520 version of core.system.php has a copyright of “2003 - 2011” in the comment block at the top; when the file is hacked, the copyright date is “2003 - 2010”.

    Another peculiar thing: I’ve already reported that when the core.system.php file is hacked, my EE control panel footer reports EE 1.7.1, but with an earlier, incorrect build number. However, I never had that earlier build of 1.7.1 installed. I went straight from 1.7.0 to 1.7.1 build 20110520.

    So the modified “core.system.php” is possibly not a hacked version of a file found in my own installation and then stored for later re-use. If that’s true, it might suggest that the attackers modified their own copy of EE’s core file.

    I’ll let you know what Dreamhost says. As I’ve already noted, they’re complaining about my having directories set to 777, but this is what the EE installation guidelines call for. I’d like some advice about stricter permissions that will work for such directories as cache and images.

  • #17 / Jun 14, 2011 6:01pm

    Kernon

    173 posts

    Just curious—have you kept a record of the modification dates of the php file?  It that too hasn’t been faked, AND if it was periodic, it might indicate a (hidden) cron job of some sort.

  • #18 / Jun 15, 2011 7:58am

    John Henry Donovan

    12339 posts

    spacewalk,

    You may actually have a trojan or malware on your own machine which may allow somebody, bot or otherwise entering your site via FTP. The trojan may be sending your FTP details to another source

    You need to determine if a) you are the only user with FTP account details for this host b) run a virus scan on your own machine. Once you are certain you are clean and only then change your FTP password.

    To be sure even get your host to change the password for you

    Normally if you have this type of hack you will see files all change at the same time usually each day so matter how many times you replace them with clean versions they will be replaced.

  • #19 / Jun 15, 2011 9:58am

    spacewalk

    106 posts

    Thanks. A few days ago, I deleted the only other FTP user account on the hosting server. I’m definitely the only user logging in now, and I always do so from the same machine. It’s a Mac and I ran ClamXav on it three days ago and came up clean (except for some attachments in my spam folder that I have not opened). However, I’ll run the AV software again today and delete all suspect files.

  • #20 / Jun 15, 2011 3:31pm

    Brandon Jones

    5500 posts

    Hi spacewalk,

    What I meant was that the complete file replacement of a file that PHP does not have write permissions for indicated the attack was coming from outside of EE. Hopefully Dreamhost can determine the source. They can also help determine if more restrictive file/directory permissions are possible on their server; but it looks like those permissions are unfortunately hard-coded in EE 1.x. In EE 2.x you can change the constants.php file to easily use different permissions.

  • #21 / Jun 15, 2011 3:39pm

    spacewalk

    106 posts

    What I meant was that the complete file replacement of a file that PHP does not have write permissions for indicated the attack was coming from outside of EE. Hopefully Dreamhost can determine the source. They can also help determine if more restrictive file/directory permissions are possible on their server; but it looks like those permissions are unfortunately hard-coded in EE 1.x. In EE 2.x you can change the constants.php file to easily use different permissions.

    Thanks. I understand your point now.

    As to permissions, if they’re hard-coded into EE 1.x, I’m stuck with them because there is no budget (right now, anyway) for upgrading this site to EE 2.x.

  • #22 / Jun 16, 2011 12:47pm

    Sue Crocker

    26054 posts

    Hi, spacewalk, anything new on your end?

  • #23 / Jun 16, 2011 5:01pm

    Kevin Smith

    4784 posts

    Hi spacewalk–

    Restrictive file permissions on the host are one of the many efforts you can take against hacking, but it’s by no means the only one. Since that’s not available to you at this time, I’d recommend working with Dreamhost to make sure all other protections against hacking are in place. Make sure you’ve got strong passwords, of course, and you may want to take a look at Noah Stokes’s article on his experience with being hacked on Dreamhost.

  • #24 / Jun 16, 2011 5:09pm

    spacewalk

    106 posts

    Yes, I’ve been working on this quite a bit, and today is the first day in more than a week that the site has not been hacked. Yesterday, I changed two things: the password for database access, and the name of the EE system directory.

    In retrospect, I should have changed only one of them at a time, because now I don’t know which did the trick, and it would be nice to know. But in any event, my core.system.php file was not replaced with a hacked one today.

    Regarding Dreamhost, they HAVE tried to be helpful. A couple of support people made good suggestions, but with caveats and limitations. Here is some of their disclaimer language:

    It can be very difficult to find how this is happening. ...  Unfortunately, performing a forensic analysis of how this happened in
    your case, or conducting a full security audit or repair of your sites/code is beyond the scope of the support that I can provide. That
    said, I am happy to point you in the right direction.

    I have cleaned this up in the past, and had the site stay clean for a month only to be hacked again. So I’m not excessively confident. However, this time around I’ve taken more aggressive steps than in the past, so I’m hopeful.

    Thanks for your help.

  • #25 / Jun 16, 2011 5:15pm

    Kernon

    173 posts

    Noah Stokes’s article is interesting, but I don’t see that he explained exactly what the “backdoor” was, or how to locate it.

  • #26 / Jun 16, 2011 10:04pm

    spacewalk

    106 posts

    I felt much the same way about the Stokes article. It was interesting (and his terminal commands were helpful to me). But he stopped well short of telling the whole story in satisfying detail. And he was the first EE user I’d seen who was talking about pretty much the exact scenario I’m going through, so it was slightly frustrating.

    Anybody know of other accounts?

  • #27 / Jun 17, 2011 4:15pm

    Brandon Jones

    5500 posts

    Hi spacewalk,

    Typically there is another file on the account that is allowing access; a remnant of an old Wordpress install for example or even an old mailer script lying around. Hopefully Dreamhost can help identify that, but if not it may be time to look at other hosting options, unfortunately.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases