A question about config.php

Posted: Sat Sep 09, 2006 6:35 pm

It is likely that I don't fully understand this conversation so let me ask a question. If someone has the proper access to "read" config.php don't they also have access to do a lot of other nasty things. For instance, to upload a script (and we've seen some examples in other threads) that give them all types of information about the server. In other words shouldn't we be focusing on preventing those who shouldn't have web server admin privileges from getting it?

I also think that we should step back and look at eliminating things from config.php. Anything that's a preference really should be "chosen" on the admin screen for preferences (say turn wysiwyg on or off for instance) and stored in the config table. I don't know alternatives for the database name and password but maybe someone with more experience with server issues could come up with an alternative way to do that. These are not items that need to be changed frequently and even if it was a setting where you had to take the system down to "re-initialize" it might be preferable to the security exposure of storing it in a file that's potentially "hackable".

Posted: Sat Sep 09, 2006 8:09 pm

Youd be surprised at some of the bugs listed with PHPSuExec and Ive reviewed some and from what Ive seen, Excellent Idea but still has its flaws, with nuke it seems to be fine but with other php applications I have seen many bugs and very odd errors so I refuse to use it on my server and the same Goes for Safe mode. But dont let that fool you, Server Security is set with other options and some custom scripts from cpanel and other things in which I am working on. But besides that if a script is uploaded as users uid then the problem is that that script can affect the server in the manner that the user can, Thats SERIOUSLY dangerous from what I have read and experienced. I learned a lot by doing the same thing Raven recomends with php-nuke. Get a site and try to hack it, well I got a server and tried to hack it, with some help from some very appreciated and knowledgable friends and Ill use this newly Gained knowledge to stop the exploitation of a server if Possible. This work will benefit others, Im sure of it. And to answer your question, Nuke Security has some issues as the limitations of how php is run on the server, Basic fundamental. If a user opens your site in a web browser, The script is run as nobody, what does that mean? Basically it means you cant tell the scripts not to be open to nobody so that leaves it open, Ive found a workaround for the include function but the reason that works is because include executes the script, so a script can be told to run something and varify it. Other functions like fopen and such do not need to run the script being called, Nothing is run actually and therefore your ability to tell it to verify something is left upto telling apache itself to verify. Simply put, fopen and similar functions may not be possible but if it is possible to limit those at a SITE level, Ill find it, you can guarantee that!!!

Posted: Sat Sep 09, 2006 10:35 pm

Code:

< ?php


$Secure_config=1;


if($Secure_config!=1){


? >


<scr ipt>


function bye() {


alert("YOU CANNOT VIEW ME!!!!");


bye() }


bye()


</scr ipt>


<nosc ript>


<me ta HTTP-EQUIV="Refresh" Content="0; URL=http://darklords-lair.com/caught.php">


</nos cript>





<?php


}

>(I had to use this to allow for the full code, otherwise it banned me.Not apart of the code, dont forget to take the spaces out of it.)
I have used this to work around something. My first thought, ok I am trying to stop the contents from being read, hmm, Now that took me on some seemingly nice leads but not exactly stoping it, So I thought to myself what would the hacker need to do to read the contents, ohh echo it out on his browser. In config.php, I use that script I just posted to force a redirect to a page that automatically blocks them from viewing anything on the site. Now combined with my secure include and putting it above root, I would like your opinions on security of this. Thanx.

Seems a bit redundant to name $Secure_config before the if huh, well I wanted to make it so that a hacker couldnt see how the script was defining how to show it, BTW I recomend renaming that variable. Im afraid I already see issues with this but its the best I could come up with the time and Perhaps others can assist on this.

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

darklord, Thank you!

For a time ago a hacker uploaded a file to a friends site using one of the cataloges which has 777 permission. Then he could hack not only that site but many other sites on the same server by this script.

I found this script and have a copy of it, I thought it could help you or other admins here to see how they manage to hacking a server or site. If it can be any help for you to make your script better, please send me your email by pm to me so I can send this script to you. It is a shell script.

Posted: Mon Sep 11, 2006 8:16 am

There are quite a number of these scripts floating around "in the wild". And the problem I referenced a couple of posts back is highlighted by them. If a hacker has the ability to upload something to your site then they can compromise not just your site but anything on the server with one of these scripts. I'm not sure if the ability to "read" your config.php is exactly identical with the ability to upload a script but I would be very concerned about looking into any incident where a hacker can get in far enough to read a php program on my site because it might imply that they can upload such a script. Finding a way to keep them from reading config.php would be a contribution but eliminating their access entirely would be more important, I think.

Posted: Mon Sep 11, 2006 11:27 am

Generally the shell script would give them access, but usually they leave no trace of how the hack was done.

Posted: Mon Sep 11, 2006 4:37 pm

Just a little clarification, I made this in an effort to fwart the attackers attempt to read anything with critical information on the server. In my learning I have found it possible to secure the server side without sacrificing all functions. Heres the deal, When a hacker uploads a shell script, ussually makes an effort to read above the root, This is possible to stop, to a point. In order to secure those files above a clients access, the server manager must set their files to certain rights and permissions so noone else can read them, not even the client. So a shell script can be stopped from affecting the server but in order to keep the functionality of the server, they leave the account to be secured by the account owner so therefore a shell script will be VERY effective against a single site and have absolutley no affect on the server itself. So my scripts I wrote are here to help secure the sites on the server and have very little benefit to the server itself. So to read this as a sure thing on security is not a good Idea but this will help.

Fkelly, as for

Quote:

If a hacker has the ability to upload something to your site then they can compromise not just your site but anything on the server with one of these scripts

Not true.

The server must be setup with good security and if thats the case then the script will have little to no affect on the server. I am not the most knowledgeable person on server security but I have spent these past view weeks away from forum help in order to read and study this as to secure my own server. This is the results from my studies but not an expert on the subject.

Posted: Mon Sep 11, 2006 6:52 pm

Darklord: thanks, this is very important research you are doing especially for those of us who don't know much about the server realm of things. Please continue to keep us updated with what you find.

I based my questions on a situation a few months back when I put one of those nefarious scripts on one of Raven's servers (in a subdomain I had) and he told me in no uncertain terms to get it off. I'll leave the exclamation points off. He runs as secure a server as I'm sure you'll find and he was concerned so I extrapolated that some of these scripts at least could do damage outside the subdomain where they were loaded.

To really be effective at the end of the day the recommendations you are making have to be comprehensible to dummies like me and there has to be a pretty clear set of instructions that folks can follow. I know it may take a while to get there, but just keep that in mind as you look into this.

Posted: Mon Sep 11, 2006 9:57 pm

If you set up PHP to run in safe mode, it will deny access to any files outside the folders you set in open_basedir setting. That will help tremendously so that the entire server itself is not compromised.

Posted: Tue Sep 12, 2006 9:01 pm

I can see why Raven and other hosts are like that, I am also. You have to remember evaders the amount of functionality you lose. Safe mode is VERY effective but limits the user in so many ways that I personally refuse to run it. I have a moto, If it doesnt work then I make it so that my clients can still have the functionality at the best limit I can offer without sacrificing server security. For example a lot of hosts disable phpinfo function, I myself do that as well because it reveals the username and pass of the account (pass is hashed though). This can hurt the client and the server depending on the users right. So I created a page in cpanel that is named phpinfo and at a click of a button, It shows php-info so they can get a quick view of server configuration to find out usefull information. But fkelly because of th fact that a host like Raven tries to keep functionality on a server is (IMO) the reason certain things are not allowed. Basically The host makes a choice and makes sure the clients are aware not to put things that can reveal bad information that can comprimize the servers integrity. Just remember Hosts do their best with what they are given and Im learning but Raven knows!!

Posted: Fri Sep 15, 2006 8:04 pm

Actually I was wrong about phpsuexec, uploads are set to the username of the account, working on how to Prepare for that.

Actually Thinking of taking Guardians sudjestion, not so litteral but to rethink the whole config.php Idea completly but that would more or less require a nice change in how php-nuke connects to the database.

Posted: Fri Sep 15, 2006 8:37 pm

I've had no problem really running in safe mode. As most servers do run in PHP safe mode, it is a good idea to check and make sure scripts you've created do run on such a setup. Mostly it is correcting things such as bad inclusions, etc.

Posted: Thu Sep 21, 2006 8:22 pm

Thought about another approach I could take, which is to change the password continuously, I got that part working, Even make it write the proper data to config.php. Problem Im having now is [cache-config.php] No CACHE_TYPE has been set!.

Curious what this means, Is it possibly an addon that Im not aware of.

Ohh btw, It generates the password using a function that uses numbers and letters in combination, So set the password once, then anytime someone visits the site, changes the password, So the site can do what it must, but apparently nuke is designed to reuse the connection continually, Ummm, not bad idea but makes this even harder. lol. My thinking is that unless the hacker can include the config.php in EVERY page he loads, then hed get no access and if you try to access the database AFTER the pass has changed and you did not reload the connection, then it will stop you, But I honestly thought nuke reloaded the connection on every page visit considering nuke always includes mainfile. So I think hed have an impossible task if I use my secure include function AND I use the change the password function. So all this said, any ideas on how I could resolve my error?

Posted: Thu Sep 21, 2006 8:59 pm

I do not want to put you on a downer but anything that requires config.php to be wrtieable is a little dodgy.

Posted: Fri Sep 22, 2006 3:13 pm

Well, config.php being writeable doesnt worry me so much, Its if mainfile or whatever file uses the information is compremised.

See all That this will do is make it so that the config.php needs to be reloaded at every point. And that makes their job all that much harder.

Posted: Fri Sep 22, 2006 6:13 pm

You all might find this thread over at the Gallery web page very interesting. I stumbled across it while researching some Gallery problems but it has some basic information, and considerable discussion, pertinent to this thread.

http://gallery.menalto.com/node/3017

Warning: have a few hours free to read.

My admittedly oversimplified conclusion: running safe mode is sort of like renaming config.php.