Sunday, May 25, 2008

Tin Pahaarer Gaan

I came across Birendra Chattopadhyay's work when, I believe, I was in high school or in first year of college. My impressionable mind immediately fell in love with his work. He was never a mainstream poet. But his poetry borne a unique and strong voice which I seldom found in others. Around the same time I found a cassette published by School of People's Art which contained songs and recitation of Birendra Chattopadhyay's poems. The songs were created out of his poems by Binoy Chakrabarty. He did and excellent job. Together with the poems and this cassette, Birendra Chattopadhyay made a lasting impression.

I loved a long poem called 'Tin Pahaarer Gaan' literally "The song of Three Mountains" or "The song of a mountain called Tin Pahaar". I starts with 'Pahariya madhupur metho dhulipoth' and continues to give a vivid and wonderful imagery. Around that time I also started composing songs. So I put tune to it - not tothe whole poem though. I stopped when I thought was the right moment for a song to stop. This was 1988-89. I kept it to myself and never published it. In 2007 I arranged it. This is that song.

Sunday, May 11, 2008

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 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('

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

PHP Shell Screenshot

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:

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 - Now, still foo.php can execute bar.php via http. Your include will simply say,

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

Now, suppose, instead of hard-coded 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');

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

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.