Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We operate a webserver farm hosting around 300 websites.

Yesterday morning a script placed .htaccess files owned by www-data (the apache user) in every directory under the document_root of most (but not all) sites.

The content of the .htaccess file was this:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://
RewriteRule .{REMOTE_ADDR}

Googling for that url (which is the md5 hash of "antivirus") I discovered that this same thing happened all over the internet, and am looking for somebody who has already dealt with this, and determined where the vulnerability is.

I have searched most of our logs, but haven't found anything conclusive yet. Are there others who experienced the same thing that have gotten further than I have in pinpointing the hole?

So far we have determined:

  • the changes were made as www-data, so apache or it's plugins are likely the culprit
  • all the changes were made within 15 minutes of each other, so it was probably automated
  • since our websites have widely varying domain names, I think a single vulnerability on one site was responsible (rather than a common vulnerability on every site)
  • if an .htaccess file already existed and was writeable by www-data, then the script was kind, and simply appended the above lines to the end of the file (making it easy to reverse)

Any more hints would be appreciated.


For those who need it, here is the script I used to clean up the .htaccess files:

TMP=/tmp/`mktemp "XXXXXX"`
find $DIR -name .htaccess|while read FILE; do
  if ( grep $PATT "$FILE" > /dev/null); then
    if [ `cat "$FILE"|wc -l` -eq 4 ]; then
      rm "$FILE"
      if ( tail -n1 "$FILE"|grep $PATT > /dev/null ); then
        rm $TMP
        cp "$FILE" $TMP
        LINES=`cat $TMP|wc -l`
        head -n $GOODLINES $TMP > "$FILE"
        echo $FILE requires manual intervention
share|improve this question
up vote 3 down vote accepted

There's an exploit of phpMyAdmin


# CVE-2009-1151: phpMyAdmin '/scripts/setup.php' PHP Code Injection RCE PoC v0.11
# by pagvac (, 4th June 2009.
# special thanks to Greg Ose ( for discovering such a cool vuln,
# and to str0ke ( for testing this PoC script and providing feedback!

# PoC script successfully tested on the following targets:
# phpMyAdmin 2.11.4,,, 3.0.0 and
# Linux 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)

# attack requirements:
# 1) vulnerable version (obviously!): 2.11.x before
# and 3.x before according to PMASA-2009-3
# 2) it seems this vuln can only be exploited against environments
# where the administrator has chosen to install phpMyAdmin following
# the wizard method, rather than manual method:
# 3) administrator must have NOT deleted the '/config/' directory
# within the '/phpMyAdmin/' directory. this is because this directory is
# where '/scripts/setup.php' tries to create '' which is where
# our evil PHP code is injected 8)

# more info on:

share|improve this answer
CVE-2009-1151. That is really old. – Lekensteyn Dec 21 '10 at 15:15
@lekensteyn: To be fair, if phpmyadmin is installed on a system, experience shows it is likely at fault. But you are right, that is a pretty old exploit. – Scott Pack Dec 21 '10 at 15:21
A Google Support Forum Discussion of 13 Dec 2010 mentions RewriteRule .{REMOTE_ADDR} and a commenter says the cause was this vulnerability. Unverified but I thought it might be worth knowing about. – RedGrittyBrick Dec 21 '10 at 15:34
This is likely the culprit. A quick find shows that there are about 10 instances of phpmyadmin on various hosted sites, very likely at least one is out of date. Thank you! – Brent Dec 21 '10 at 16:00

Since the attack seems to have come in through apache, I would do these two things:

  1. Chunk through all of the access logs looking for '.htaccess', i.e. something like
    grep -rn '\.htaccess' /var/log/httpd/*access*
  2. Look in the apache/httpd/whatever users home directory for a history file, often '/var/www' or something similar.

This will first tell whether the web user itself was compromised, or the attacker was utilizing an arbitrary command execution. It may also give a (potential) full account of what the attacker did. As silly as it sounds, most hacks like this rarely clean up after themselves and leave such evidence behind.

And, of course, if you have a group in your organization that performs security incident response or forensics examination, it might be worth handing the equipment over to them before you begin your own analysis.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.