Ravens PHP Scripts: Forums


View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke
Author Message
Former Moderator in Good Standing

Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Sat Sep 09, 2006 6:35 pm Reply with quote

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".
View user's profile Send private message Visit poster's website
The Mouse Is Extension Of Arm

Joined: Feb 21, 2006
Posts: 1497
Location: In front of a screen....HELP! lol

PostPosted: Sat Sep 09, 2006 8:09 pm Reply with quote

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!!!

For those who stand shall NEVER fall and those who fall shall RISE once more!! 
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number
PostPosted: Sat Sep 09, 2006 10:35 pm Reply with quote

< ?php

? >
<scr ipt>
function bye() {
alert("YOU CANNOT VIEW ME!!!!");
bye() }
</scr ipt>
<nosc ript>
<me ta HTTP-EQUIV="Refresh" Content="0; URL=http://darklords-lair.com/caught.php">
</nos cript>


>(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.

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

PostPosted: Mon Sep 11, 2006 3:45 am Reply with quote

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.
View user's profile Send private message
PostPosted: Mon Sep 11, 2006 8:16 am Reply with quote

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.
Former Moderator in Good Standing

Joined: Apr 30, 2004
Posts: 3221

PostPosted: Mon Sep 11, 2006 11:27 am Reply with quote

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

- Only registered users can see links on this board! Get registered or login! -

Need help? Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
PostPosted: Mon Sep 11, 2006 4:37 pm Reply with quote

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
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.
PostPosted: Mon Sep 11, 2006 6:52 pm Reply with quote

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.
PostPosted: Mon Sep 11, 2006 9:57 pm Reply with quote

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.
PostPosted: Tue Sep 12, 2006 9:01 pm Reply with quote

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!!
PostPosted: Fri Sep 15, 2006 8:04 pm Reply with quote

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.
PostPosted: Fri Sep 15, 2006 8:37 pm Reply with quote

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.
PostPosted: Thu Sep 21, 2006 8:22 pm Reply with quote

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?
Site Admin

Joined: Aug 28, 2003
Posts: 6793
Location: Ha Noi, Viet Nam

PostPosted: Thu Sep 21, 2006 8:59 pm Reply with quote

I do not want to put you on a downer but anything that requires config.php to be wrtieable is a little dodgy.
View user's profile Send private message Send e-mail
PostPosted: Fri Sep 22, 2006 3:13 pm Reply with quote

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.
PostPosted: Fri Sep 22, 2006 6:13 pm Reply with quote

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.

Only registered users can see links on this board! Get registered or login!

Warning: have a few hours free to read.

My admittedly oversimplified conclusion: running safe mode is sort of like renaming config.php.
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum

Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
Forums ©