Thread

One of my EE installs has a malware infection, and it *seems* to be within the EE install itself. I’ve love any pointers trying to diagnose the problem further.

The basic symptom is that the following piece of malware: http://pastie.org/2716106

Gets prepended on-the-fly to the start of every EE template when it’s sent to the browser.

Here’s what I’ve figured out so far in trying to reproduce it:

1. It never occurs for any static files (html, css, or php) hosted on the website
2. It only ever occurs ONCE per browser session
3. It occurs upon the SECOND request by a browser (eg. I load up test.html fine the first time, I refresh, the script is inserted and I get redirected).
4. It affects every template, and every type of template, that I have in the EE install
5. I’ve tried creating new template groups, new templates, etc.
6. It only occurs when a template is accessed directly via the URL (not for includes/embeds)
7. I’ve checked my .htaccess and index.php file, neither have been tampered with.
8. The malicious code snippet is dynamic code - the URL occassionally changes, and the ‘rnd’ value does as well.

Initially I thought it was a DNS problem. Then I thought it was an Apache thing on the web host. But if it was Apache - it should affect files outside of EE, right?

But if I create a static version of a file hosted in EE (eg. my /includes/screen.css) and access it, it’s fine. The malicious code is only prepended if I delete the static file and access the one in EE. I can’t repro the issue with any non-EE files.

In summary, it seems that any content requested which is routed through EE’s index.php and served up from the database suffers this problem.

My question is this - how can I track & diagnose this further to figure out where on earth the malicious code is getting inserted?

I need to figure out what the problem is so I can not just solve it, but stop it happening again (there must be a vulnerability being exploited *somewhere*).

My htaccess is configured as follows:

RewriteEngine On
RewriteCond $1 (files) [NC]
RewriteRule $1 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/$1 [L]

And I’m running EE 1.6.7 on PHP/MySQL.

(I should add - obviously this issue reoccurs on all browsers, OS’s, and ISPs. And it’s only affecting the one EE install).

Hi, Sam. The first thing I’d do is upgrade to 1.7.1, which will refresh your files.

  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.

Thanks for the quick reply Sue…

Ahhh - path.php. Found the problem. I think I checked every file in the install except that one.

Here’s the malicious code snippet (I’ve formatted it slightly but it was all on one line): http://pastie.org/2720080

Doing an update to 1.7.1 now (I wanted to find the problem first).

Wow, that’s definitely not good. Did running the upgrade take care of things? If so, the next step is to work with your host to make sure you lock down the exploit the hacker was able to use to gain this kind of access to your server’s files!