A question about config.php

Involved Joined: Sep 07, 2004 Posts: 354 Location: Sweden

I've seen somewhere that it is better to have you config.php file in home directory and link to it from nuke root. I've done it for a time ago but I have problem with entering to admin forum.

here is my code in config.php which I have in nuke's root:

Code:




<?php


@include_once("../../config.php");


?>

I have my nuke installed on a addon domain, if it has anything to do with my problem.

When I enter the forumadmin I just get a white page but every othe modules works fine.

Regards.

Sells PC To Pay For Divorce Joined: Posts: 5661

mm,it shouldnt be a problem..
have you turned on your error report...see what it shows with the blank page?

Posted: Sun Sep 03, 2006 5:05 pm

I wouldn't bother with trying to "hide" config.php. Make sure your Sentinel is relatively up to date and follow (and implement) the security threads here and you should be okay.

If the hackers can get into your config.php in your nuke root then they've already go enough access to do you substantial damage. Sticking it a couple levels "up" really doesn't accomplish much ... I don't think.

Posted: Sun Sep 03, 2006 5:14 pm

i allways used it like that, i never had it in my root.
btw,this subject is discussed a few times before....
it can be a problem for the forum,but it never was when i used it.

Posted: Mon Sep 04, 2006 7:49 am

Yes, this has been recently addressed in another forum by Evaders99. I have a feeling that one of the recent patches has "broken" this approach. Sorry, cannot remember if Evaders posted a "fix"...

Posted: Mon Sep 04, 2006 7:56 am

will this do ? Wink

[ Only registered users can see links on this board! Get registered or login! ]
Note that this may stop the forums admin panel from working.
You will need code to address the relative paths - or quicker use the full path

and read this... [ Only registered users can see links on this board! Get registered or login! ]

Posted: Mon Sep 04, 2006 8:26 am

Thanks a lot!

Posted: Mon Sep 04, 2006 12:58 pm

The working code for a subdirectory is :

<?php
if (stristr($_SERVER['SCRIPT_NAME'], "config.php")) {
Header("Location: index.php");
die();
}
if (defined('FORUM_ADMIN')) {
@require_once("../../../../../config.php");
} elseif (defined('INSIDE_MOD')) {
@include("../../../../config.php");
} else {
@include("../../config.php");
}
?>

The working code for a root directory is:
<?php
if (stristr($_SERVER['SCRIPT_NAME'], "config.php")) {
Header("Location: index.php");
die();
}
if (defined('FORUM_ADMIN')) {
@require_once("../../../../config.php");
} elseif (defined('INSIDE_MOD')) {
@include("../../../config.php");
} else {
@include("../config.php");
}
?>

This puts it above root which cannot be accessed via a shell script that allows you to look through all files within you nuke directory, mind you this does not stop people from viewing any other files like index.php.
Server setup will stop them from doing any damage to it. If setup correctly.

So in short, if security on the server is setup RIGHT, they cant edit the files, create new files with get_contents, but this does not stop people who have been given ftp access or have obtained it.

Posted: Mon Sep 04, 2006 1:16 pm

I tried inlude path but its not defined before the inclusion of config.php, not sure if thats why it wont work but I believe so.

Posted: Mon Sep 04, 2006 1:18 pm

darklord, I've tested now and it works great!

In this way I don't need to make changes to mainfile.php.

Thanks!

Posted: Mon Sep 04, 2006 1:20 pm

no problem.

Posted: Tue Sep 05, 2006 6:08 am

Quote:

This puts it above root which cannot be accessed via a shell script

I just want to clarify this as it lends into my question of necessity for doing this, or, to do it right... Bringing the config.php script out of the web root only keeps it from being accessed directly from the web server (i.e., Apache). However, this file is already, in of itself, protected from direct access by the web server with the code that is right up front as well as this only sets variables, which would be useless on its own.

The main "threats" to this file is if somehow the contents of it could be read by someone who should not see the db name, user and password. In order for this to be done anyways, the hacker would have to have found a hole in your code somewhere which allowed them to read this file's contents from PHP itself -- e.g., include or fopen. Well, putting this out of root doesn't help you there. If they can figure out your path and file name, it is no safer than if it was in the web root.

If you really want to use this method of "protection", you should create another directory outside your web root with some very cryptic name and place the config.php in there. Ah, but, then again, if you were concerned about them getting access to your config.php before, then you must assume that they can read this "stub" that was placed into your web root OR could read your mainfile.php and figure out where the real config.php is placed.

Do you see why I think all of this is is a failed attempt by FB to give you some sense of false security?

Now, to address the "shell access" question. If a hacker gets ahold of your account, or almost just as bad, someone elses (i.e., someone you is not as diligent as you in keeping up with security patches), the permissions on your files are paramount (also can depend on how PHP is being run with Apache - CGI vs. embedded). Most of us have to have group and world read permissions on our script files... guess what? If a hacker gets someone else's account, they may be able to read your config.php from the shell.

Sorry for this long post, but I want folks to understand why renaming admin.php and moving config.php out of root are barely worth the effort.

Posted: Tue Sep 05, 2006 7:24 am

montego, thanks again.

It clears up for me a lot. My thought to do this was in the first hand to keep config.php out of seen for scriptskiddy. I think like you, it is not 100% safe but it will make it a little difficult for scriptskiddy to have direct access to this file (I think).

Can we say that the safest way is to crypt this file by say, Zend?

Posted: Tue Sep 05, 2006 8:09 pm

Quote:

make it a little difficult for scriptskiddy to have direct access to this file (I think).

Well, even if it is where it is at normally, if they can get as far as being able to read the contents of it, they already know enough to go find it. JMO.

Quote:

Can we say that the safest way is to crypt this file by say, Zend?

Problem with this is that the decryption key has to be kept somewhere to un-encrypt it... see where I am going with that? Wink

Bottom line: they have to exploit another hole in the site somewhere to get this level of access, and if they were already smart enough, or lucky enough, to get that far, the door has been opened wide enough to get into the room...

Posted: Wed Sep 06, 2006 5:35 pm

Montego, I completely agree.

One thing about putting it above root, is that with a server script uploaded like c99shell.php, which is something Ive been using for various tests on my server, cannot access the root directory of an account, so placing it above the root, stops these forms of scripts from working, now the absolute best thing would be to check the url and ownership of the script that calls on it, Something Im working on to add to config.php. If the owner is not the same as the owner of the config.php file, THEN nothing will happen but this is kinda tricky to manage and Im working on it.

So this would be the best solution so if hacker gets the ability to upload something, which is ussually set to user and group nobody, and config.php is set to user and group of clientA then config.php would die. This would prevent php scripts from calling it. But simply put, this shows how important the server your on is. Server security should be as high of a priority as nuke security to the user if not higher.

I will continue my efforts.

Posted: Wed Sep 06, 2006 7:47 pm

Here you go,
functions secureinclude(){
$path= $_SERVER['DOCUMENT_ROOT'];

$oofcm= fileowner($_SERVER['SCRIPT_FILENAME']);
$path1=$_SERVER['SCRIPT_FILENAME'];
if (eregi('public_html',$path)){

$path=str_replace( 'public_html','',$path);
}
if (eregi('htdocs',$path)){

$path=str_replace( 'htdocs','',$path);
}
$path3=($path.'config.php');

$owner= fileowner($path.'config.php');
if ($owner!=$oofcm){
die("DUDE NOT COOL");
}
}

That will stop anyone from including your config.php in there scripts and outputting the information, Id put this in config.php and then call secureinclude(); from anywhere in config.php.

Now to stop get_contents

I swear when Im done, Imma lock config.php DOWN!!! But this is not guaranteed as there are other ways to get the information but Ill do my best. Mind you that this has not stopped nuke in anway because all files should be set to the proper owners, things uploaded via php should always be set to owner nobody. FTP access can override this so always remember NOT to give ftp access out and anonymous should not be allowed.

Posted: Thu Sep 07, 2006 6:22 am

darklord, I am not following your approach. If there is an exploit with the nuke installation / add-on which can do an include or get_contents or _____, then how does this stop it? How does this allow nuke to use it?

I can be a bit dense this early in the morning...

Posted: Thu Sep 07, 2006 2:47 pm

Its ok, basically, When a hacker uploads a script via input through your site, like avatars or submit download or anything that allows upload, its uid is set to nobody by default. Now this script in config.php, just basically checks the owner of the script including it. So if I use script.php to include config.php and echo its contents, config.php will check the uid of script.php and config.php, If config.php is set to userid bob and script.php was set to userid nobody, config.php will say hey you cant access me because, your not the same uid.

Thats for includes, I just got home so Im investigating the ability to kill the file_get_contents and such.

Any advice on whether or not this is a good way to go about it would be appreciated, Flaws and sudjestions welcome.

Posted: Thu Sep 07, 2006 2:51 pm

Also, that code specifies config.php above public access.

Posted: Fri Sep 08, 2006 6:31 am

Oh, ok, I see it now. Thanks!

By the way, are you certain that the uid is set to nobody when PHP is running under PHPSuExec? I don't think so, but I am not 100% certain. So, this may only work on installations that are not using this.

So, where does this code go and how does it get executed? I will guess that it goes in config.php and that you will also make a call to the secureinclude() function somewhere in there as well.

I don't see how you will be able to stop reading the file contents directly... so, am definitely interested to see if you figure that one out!

Good stuff!

Posted: Sat Sep 09, 2006 11:15 am

Im not sure about suexec but from my understanding of it, ALL uploaded scripts or anything uploaded through php at all will automatically be set to uid of nobody. Your right that this does not stop reading the contents but this is just one step in the right directions, I have not been able to date find a way to stop that but I will continue my efforts as I believe this is of the highest priority to secure the config.php. One step in the right direction though.

Posted: Sat Sep 09, 2006 2:37 pm

Why not get rid of the variables in config altogether ans set them as constants hidden in the main lang file and just leave a 'trap' in config.php for those that go looking for it.

Posted: Sat Sep 09, 2006 3:20 pm

Well, Not a bad idea but what if a hacker uploads a script set to uid nobody and in that script echo Constant for db or get_defined_constants() then you just left yourself in the whole again, or simply read the mainfile for the name of the constant. Not to put your idea down but The main issue is that db and other things are still left in the code somewhere. Now what would really be awesome if the username and pass where dynamic and continually changing by the second and nuke could use something to tell what the new password is or was but that still leaves the problem of not letting it viewable by anyone. See mainly, even though the uid of the script is set to user, when someone who isnt logged into the system runs it( Thats everyone pretty much) its run as nobody and their for it cannot be told to only allow reading from user in chmod, Im working on a couple of other things thought that just might change that, Im really close to locking the fopen wrapper and a few other wrappers.

Posted: Sat Sep 09, 2006 5:32 pm

I was under the impression that even if you manage to read the constant, it is worthless as you cannot inject the connection variables needed - once a constant is set it cannot be changed?

Of course you could use the values to create new vars and us it that way but we are talking about extreme breaches here.

What would be nice is a way to 'scan' the files in the server looking for variables used in the most common hacking scripts - it wnat stop the infected site getting hacked but it might prevent them traversing to other sites on the server.

Hmm.........

Posted: Sat Sep 09, 2006 5:55 pm

darklord wrote:

Im not sure about suexec but from my understanding of it, ALL uploaded scripts or anything uploaded through php at all will automatically be set to uid of nobody.

Well, actually, that is one of the points of using phpsuexec is that each account can run under its own user. Therefore, it will not have "nobody" as its uid.

But, I will wait and see what you come up with... like I said, bottom line is that your site is only as weak as its weakest link and that "link" may end up being someone else's site on the same server (if phpsuexec is not being used).