Thread

Hi there,

I’ve had a problem this week with one of my EE sites and I’m not sure whether the breach is because of my EE configuration, or something to do with my hosts.  I’m still in my first year of EE development and it’s the first time I’ve ever had to deal with a website under attack so would appreciate any input on where to start.

My site was relaunched last month following an upgrade to v1.6.1.  As I’ve just started using TextMate and CSSEdit, I changed at this time to using the Save Templates as Text File option and therefore created a templates_file folder (set to 777) within my renamed system folder.  Access to the renamed system folder isn’t masked, and I’ve set up a redirect from admin.website.com to http://www.website.com/renamed_system/ to enable my sole contributor/user of the site to easily access the control panel.  Apart from a simple contact form, I’m not using any blogging functionality or anything involving comments etc - it’s really just a simple CMS setup.

Last week I noticed somebody had added links from the sidebar of my website to a dodgy looking external site - and that on closer inspection some of the template pages also included JavaScript at the bottom of the page relating to these external links.  I’ve no idea where they came from or how they gained access.  My contributor user doesn’t have access to edit the template files, but the changes were definitely made to the template files themselves (i.e. the suspicious code was in the text template files, rather than having been added in one of the weblog entries).

I immediately took the site offline and have changed all the passwords for both my EE logins and the FTP access to the site.  However I need to know how the changes were made to ensure that it doesn’t happen again.  I guess it could either be:

-  someone gained admin access and changed the files within EE control panel (but if so how?  I think it is more likely the changes were made to the text files themselves)
-  someone exploited the 777 access to the template_files directory (it’s hosted on a shared server) - in which case I need to get in touch with the hosting company
-  something else?

Can anyone advise on what might have gone wrong, and how I can avoid it happening again?  Is it best practice to stop using the Save Templates as Text Files option once you finish creating the site and updating the templates themselves?  Also - should I now mask the (renamed) system folder - and is there anything else I need to do?

Many thanks for your help.

James A

Not an expert in this but having seen the few other instances where the template text files have been altered it’s usually been one of two things…
1) Another (less secure) script like phpBB is either running or installed and the hacker has gained access through that vulnerability. Is there anything like that installed in your environment?
2) Your host has a security problem. Who is your host?

This usually has nothing to do with EE or the fact that you are using template text files other than that there are files for the hacker to alter.

That said, I know the admins are always concerned about exploits/breaches so as much info as you can give about your host/environment will help them.

Thanks for the really quick reply.

Hm - I think you may be on to something with the third party scripts.  I’ve moved from using the inbuilt gallery to using PHPFlickr to pull my gallery photos from a Flickr account in conjunction with the lightbox.js script which uses prototype.js and scriptaculous.js.

(apart from that the only other script is AWStats, installed via the hosting control panel)

In order to use PHPFlickr I’ve had to enable PHP on my gallery page.  I’m wondering if this could be the source of the problem.  Moreover - I’ve used a bit of PHP to handle the pagination so that 16 photos are displayed per page, with page being taken from a query string.

As I’m writing this, alarm bells are ringing in my head.  I know nothing about XSS etc - but is it possible that someone could make a change to the template files because I’ve allowed PHP and used a query string?

If so - I feel very foolish, but at least I know what needs to change.

Don’t have any insight beyond my post but hopefully an admin will jump in here shortly and investigate further. Security Breach in the title should get their attention 😊

(apart from that the only other script is AWStats, installed via the hosting control panel)

I would also check to see what version of AWStats you are running, there have been security issues in the past with it.  I would also of course suggest you contact your hosting provider directly about the issue in general.

Thanks - AWStats is version 6.7 which looks like it’s safe from known exploits.  I’ll definitely contact the hosting company (http://www.xilo.net) too to see if they have any input.

I’ll amend the PHP so that the query string handling the page number can ONLY handle a 1 or 2 digit page number (something that I realise now I should have done anyway) - but apart from that I think that side of things is ok.  My hosting company have just (finally) updated to PHP5 so I should be able to get photos from Flickr without having to use PHPFlickr, so that should remove that from the equation.

I’ll also mask the (renamed) system folder and probably for my own peace of mind change back to using DB templates rather than text files.

However - if there’s anything related to EE I’ve missed, please do let me know.

Thanks again for your help,

James

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.  It seems that others above have covered the major bases.  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.

Also, make sure that you check config.php, path.php, and index.php for any iframes or javascript inserted in those files.  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.

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.