Security RISK/WARNING for you folks with shared providers..

[tomk]

Folks,

This is such a simple security issue, I'm surprised it even exist.

There is, in my mind, a huge security issue for folks running forum software such as vB or phpbb on these shared servers. It has to do with the config.php file and your host not knowing what the heck they are doing.

They have the permissions configured improperly, where they allow "all" read and eXecute permission on this file.

So, what does this mean to you? It means you can do a "locate config.php" and see all the copies across everyone's home directory. At that point, you can cd to that directory and READ the config.php file.

Of course, once you have read it, your able to get the dbname and dbpassword that is configured for MySQL.

Once you have this data, feel free to use mysqldump to dump the data base, change it, etc.

Check with your host, your config.php file SHOULD NOT be world/all readable. It should be RWX for you, and R for whatever user runs apache (on RedHat, it is the apache user). No reason to have world/all permissions on this file. At least none that I am aware of! ;-)

Perhaps someone with more security experience can figure out how to better protect this file then having it chown user:apache and chmod 750.

Two LARGE shared providers are vulnerable to this, to check if yours is, do a:

[cara@s1 cara]$ locate config.php
/www/html/fn/vb/admin/config.php
[cara@s1 cara]$

<note user Cara can read that directory, which isn't hers>

[cara@s1 cara]$ ls -l /www/html/fn/vb/admin/config.php
-rwxr-xr-x 1 tjk tjk 1017 Jan 24 21:50 /www/html/fn/vb/admin/config.php
[cara@s1 cara]$

<ok, the file is user/group tjk, but has RX permissions for All>

[cara@s1 cara]$ cat /www/html/fn/vb/admin/config.php
<?php
/////////////////////////////////////////////////////////////
// Please note that if you get any errors when connecting, //
// that you will need to email your host as we cannot tell //
// you what your specific values are supposed to be //
/////////////////////////////////////////////////////////////

// type of database running
// (only mysql is supported at the moment)
$dbservertype="mysql";

// hostname or ip of server
$servername="localhost";

// username and password to log onto db server
$dbusername="vb";
$dbpassword="vb";

// name of database
$dbname="vb";

// technical email address - any error messages will be emailed here
$technicalemail = "blah blah blah to protect the innocent";

// use persistant connections to the database
// 0 = don't use
// 1 = use
$usepconnect = 0;

// which users are allowed to view the admin log
// separate each userid with a comma
$canviewadminlog = "1";

// which users are allowed to prune the admin log
// separate each userid with a comma
$canpruneadminlog = "";

?>
[cara@s1 cara]$

<great, cara now has my db name and my db password! what can they do with it? Hopefully I'm smart enough to not use my dbpassword as my admin login, etc>


[cara@s1 cara]$ mysql dump -uvb -pvb vb > test.dump
[cara@s1 cara]$ ls -l test.dump
-rw-rw-r-- 1 cara cara 4587 Jan 28 13:09 test.dump
[cara@s1 cara]$

<hmm, they were able to dump it...not good>

You get the point from here.

Check your server/configuration!

Tom

[The Prohacker]

Its a known risk, and one that you cannot get around, for apache to read it, everyone else must be able to also.... Once Apache 2.x becomes final, this will be fixed, everything will be run as the users UID, and so globaly readable and writeable files will be no more.....

[tomk]

That's not true.

I solved it be making the file:

chown jdoe:apache and chmod 750.

This lets the apache user read it when it needs to, and the user has rwx access to it.

Any other user can't read the file...

I have it set that way, tested it, and it works, what am I missing?

Tom

[Joshua Clinard]

Shhh! There might be hackers reading these boards. We don't want to give them any ideas.

[The Prohacker]

[prohack@www]:~$ chown nobody.prohack index.html
chown: changing ownership of `index.html': Operation not permitted
[prohack@www]:~$ chown prohack.nobody index.html
chown: changing ownership of `index.html': Operation not permitted
[prohack@www]:~$


One problem with your changing ownership, root would have to do it, and when you have 500+ customers thats a real big hassle..

Like I said, no real easy answer...

[tomk]

BUT if it was done right the first time...

You know the rest of that story.

Tom

[The Prohacker]

Originally posted by tomk
BUT if it was done right the first time...

You know the rest of that story.

Tom

We are running Cpanel, there is nothing done right with it..

[tomk]

Are you a service provider/hosting firm or an end user?

Care to take the dialogue to email? I'd like to discuss more with you.

tom@kiblin.com

Tom

[The Prohacker]

I'm a webhost....

Sure I guess....

[Karl]

TomK, with all respect, it is not up to the host to check every site for a copy of config.php on vBulletin and secure it, besides which, if you do your solution all I have to do is write a script that runs in the web server to read the file and get the contents. This is a known risk with shared hosting and effects all sorts of scripts not just vBulletin. Like has been said, Apache 2 is going to help solve this problem.

[tomk]

Originally posted by Karl
TomK, with all respect, it is not up to the host to check every site for a copy of config.php on vBulletin and secure it, besides which, if you do your solution all I have to do is write a script that runs in the web server to read the file and get the contents. This is a known risk with shared hosting and effects all sorts of scripts not just vBulletin. Like has been said, Apache 2 is going to help solve this problem.

Karl,

You are correct. Sad but true that this exist.

Oh well, I'm surprised more folks haven't been affected by this...considering how easy it is to destroy someone's database.

tjk

[Karl]

Yes, me too. It's a trade off, run Apache with SuExec and put PHP in as a CGI and it's slow and a waste of resources, or make better use of resources and run PHP as a module but run the risk of things being less secure.

[JTMON]

Originally posted by Karl
Yes, me too. It's a trade off, run Apache with SuExec and put PHP in as a CGI and it's slow and a waste of resources, or make better use of resources and run PHP as a module but run the risk of things being less secure.

Those are the choices?! Oh shi*!:eek::D

[Karl]

Yes those are the choices and they aren't as clear cut as they sound.

[JTMON]

Well I know my host runs apache with SUexec but it seems fast. I've even had compliments on the speed. Never mind the site going down once a week:D:rolleyes:

Good info to know though, thanks for the headsup!

[The Prohacker]

Originally posted by JTMON


Those are the choices?! Oh shi*!:eek::D

Well if your or your host can afford it, you could use the Zend Encoder, and encrypt your files.... But not many places have the 10 grand, (I think its around that)....

[JTMON]

Originally posted by The Prohacker


Well if your or your host can afford it, you could use the Zend Encoder, and encrypt your files.... But not many places have the 10 grand, (I think its around that)....

Are you nuts?:p My host has a hard enough time keeping their servers working. If they get a spammer, they cut off email to the entire server without any notice. I am seriously considering switching.

[The Prohacker]

Originally posted by JTMON


Are you nuts?:p My host has a hard enough time keeping their servers working. If they get a spammer, they cut off email to the entire server without any notice. I am seriously considering switching.

Well, gotta admit, they have a nice webpage :D

http://www.ocservers.net/

[JTMON]

Hehe, wrong page.

www.ochosting.com

[svoec]

I was looking at another post on this board, on someone's site getting hacked, and this thread was pointed out to me.

I had told the person that I used permissions of 740 on my config file.

I see that you have recomended 750. Why would you need execute on the config.php ?? it is read as a text file, not executed as a php.

I realise there is little way to exploit this extra right, but I just dont see a need for it.

just curious. My theory on security is give the minimum needed, that way, it is much harder to exploit.

Thanks
Eric C

[Mark0380]

My forums were hacked into and wiped of their contents last Thursday (see separate thread here (http://www.vbulletin.com/forum/showthread.php?threadid=43815)). Shortly after the attack, I discovered that another vBulletin on the same hosting network had fallen prey to the same hacker. Thus, I began to draw the conclusion that the hacker might be accessing the databases of our sites using the methods outlined at the start of this thread.

Following a few quick tests of my own, I confirmed those suspicions, and reported the potential security flaw to my hosting company. Although they (VenturesOnline) are now hopefully talking to Jelsoft directly about the matter, for my own peace of mind I have been trying to figure out how to protect my vB's config file using some of the ideas mentioned here.

Currently, when I chmod the 'config.php' file and remove 'world read' rights, it brings down my vB completely. VO have confirmed to me today that the server I am on runs 'suexec' - so surely the file permissions can be altered to restrict read/write privileges to 'owner' only? Can anyone suggest what might be wrong?

[JTMON]

Have you tried 744?

[svoec]

744 would work, but that still gives world read to the config.php.

which means anyone could read it, and pull your my-sql password out, and then they can run my-phpadmin from any server anywhere to connect to your db, and have fun with you...

one thing your ISP might be able to do is set the DB to only allow connections from servers in their network.. that makes it a little harder for the hackers, but that still leaves you open to other people on the same host.

Eric C

[Mark0380]

But surely making it 744 gives the file more access privileges?!? :confused:

By default, the permissions on all files uploaded to my shared account at VO are 644 (owner read/write, group read, world read). I would have assumed at the very least you need to remove 'world read' permissions on config.php? Or am I misunderstanding something?

[tomk]

Still not the most secure way, but chown it to yourid.apacheid. And chmod it to 740 (rwx,r,-)

The smarter users can still write a script and execute it under the apache userid to read it, but joe-blow in via telnet/ssh can't read it.

Even from the command line, when the user reads that file, they can trash your mysqldb, I wouldn't call this hacking, it is 101 stuff. They can dumb your db, restore it (I think), mod it, scary stuff.

This is a huge problem, and has been for a long time. I'd be embarassed if I were the author of such programs that didn't use a bit better method to at least encrypt the password stored in the txt file.

I've installed some PHP programs that need this info in a config.blah file for mysql access, and the better ones at least use some encryption/hash to store the password, so yes, it can be done.

Better yet, upgrade to apache 2.x now!

tjk

[Mark0380]

Originally posted by tomk
Still not the most secure way, but chown it to yourid.apacheid. And chmod it to 740 (rwx,r,-). Better yet, upgrade to apache 2.x now!

Hmmm... strange you should mention that Tom. I have had this suggested to me previously, and passed it onto VenturesOnline today (as I do not have permission to run chown). They simply replied with: "you shouldn't need to chown the file like that", and that was it.

So I am a bit lost on what to say/do next!

[svoec]

Maybe time to look for a better / more secure host.

If you are paying monthly, just let it run out, and switch...

If you have paid for a couple of months , complain until they give your $$$ back because of their obviously shotty security.

it really sounds like these guys are unwilling to change, and it is begining to sound like they are not the sharpest dart thrown at the dartboard.

I'm by no means a unix guru, but I do know that if your config.php has to be 744, minimum, PHP is not running as "nobody"

As far as the authors of VB, I made the comment in the other thread Mark0380 spoke of, that it would be nice to at least let the installer rename, or move the config.php file. If a hacker doesn't automatically know the file name and path he/she is looking for, it makes their hack much more dificult.

Done rambling.
Eric C

[tomk]

Originally posted by Mark0380


Hmmm... strange you should mention that Tom. I have had this suggested to me previously, and passed it onto VenturesOnline today (as I do not have permission to run chown). They simply replied with: "you shouldn't need to chown the file like that", and that was it.

So I am a bit lost on what to say/do next!

Mark,

Ask them why they won't allow this for that file? This is crazy.

chown yourid.apacheid and chmod 740 says that only your id and the apache group id that runs apache/php can read the file, and only you can write/change it.

It keeps all the little script kiddies out, unless they know how to write a script and execute it via apache/php to read the file. Easy to do, but it makes it a *bit* more secure.

Better yet, tell your host to upgrade to apache 2.0, configured properly this will be the better solution since the vb guys are not interested in making the code more secure around the config.php file.

tjk

[JTMON]

Correct me if I am wrong on this. If you have your config file in your admin folder, and your host doesn't allow shell access, then you're pretty secure as they couldn't do these things right?

[JTMON]

Something else I've found is that when accessing my site via ftp, the highest level it lets me go is my root folder, httpdocs. If I use a mac client though, I can view the server root and everysingle website folder on the entire server!! Granted I can't access it, is this normal for mac ftp programs?

[svoec]

It is probably just the settings on the mac client. Sounds like you are on a windows server ??,

anyway, it is fine that you can see their directories, as long as you can't see inside the directories... if you can, you are open to the same problem...

Eric C

[JTMON]

Nope, I'm on Linux, I wouldn't touch a NT webserver for 1000 bux:D I'n not a mac person either so I don't know what settings would affect it. I was just amazed that I could see all that info alone. If I'd been able to go into the directories and read I would have left my host by now:D

[svoec]

don't feel too secure....

it is still possible that someone could write a php script that could access your config.php file, and write it to a file they could read, or just display it on the screen for them. the script would have to be on the same server, or same NIS.


maybe I should shut up, I hope hackers don't read this :)

Eric C

[Mark0380]

Having only just relocated to VO, I am not at all thrilled at the prospect of having to find another host.... especially when both the vB developers and a number of highly-respected users on this support forum actively recommend them. Thus, I think I am going to give them the benefit of the doubt for now, and hope that both VO and Jelsoft will resolve the matter between them.

That said, I have cut'n'pasted Tom's post and forwarded it to them to see if they have anything more to say against using the chown method. I can't for the life of me understand why it would be so much hassle for them to at least do this on my account. Or am I/we missing their point about suexec? Any vB developers in the house care to comment?

[tomk]

Originally posted by svoec
don't feel too secure....

it is still possible that someone could write a php script that could access your config.php file, and write it to a file they could read, or just display it on the screen for them. the script would have to be on the same server, or same NIS.


maybe I should shut up, I hope hackers don't read this :)

Eric C

That's been said many many time in this thread, no new news there.

tjk

[mishkan]

Hi all,

This thread makes me shudder! :eek:

I did the "locate config.php" thingy, through my telnet connection, and I got a loooooong list of path names. I am in trouble here, right?

I am truly a newbie. Can anyone possibly translate all the advice given here, into easy-to-understand steps? Sort of like a "security checklist"? With techie terminology explained, please?

Thank you very much in advance.

mishkan :)

[Ian]

Originally posted by svoec
don't feel too secure....

it is still possible that someone could write a php script that could access your config.php file, and write it to a file they could read, or just display it on the screen for them. the script would have to be on the same server, or same NIS.


maybe I should shut up, I hope hackers don't read this :)

Eric C
Wouldn't having PHP in SAFE MODE fix this?

[Karl]

Yes it should do, as would using open_basedir restrictions. Of course it doesn't solve the problem if other scripting like perl etc. in not being run SuExec.

[tubedogg]

Originally posted by tomk
This is a huge problem, and has been for a long time. I'd be embarassed if I were the author of such programs that didn't use a bit better method to at least encrypt the password stored in the txt file.What exactly do you suggest we do? We can't use the Zend Encoder, because the majority of hosts are not running the Zend Optimizer (which is the minimum required to decode an Zend Encoder-encoded file). Encryption of just the password is out of the question, because it would have to be a reversible encryption (since it has to be fed to MySQL at some point and MySQL doesn't use encrypted passwords) which would kind of kill the point of using it.

There is not much that can be done in general regarding this - and there is nothing that can be done by us.

[tubedogg]

Also regarding the people suggesting that VO & Jelsoft should get together and resolve this: Even if that were to happen (which I doubt it will), that still leaves every other host on earth. It won't help anything except the people on VO.

[mishkan]

Originally posted by mishkan
I am truly a newbie. Can anyone possibly translate all the advice given here, into easy-to-understand steps? Sort of like a "security checklist"? With techie terminology explained, please?
tubedogg and vBulletin Team, do you think this could be done? For you to create a list like this? I'm sure it would be highly appreciated by all vBulletin administrators... especially by us newbies.

mishkan :)

[GsxrTony]

Originally posted by mishkan

tubedogg and vBulletin Team, do you think this could be done? For you to create a list like this? I'm sure it would be highly appreciated by all vBulletin administrators... especially by us newbies.

mishkan :)

Yeah that would be nice, My brain is smoking after reading through all of that.

[svoec]

here was my thought
Have the install script ask the installer to choose the name for the config file, and store that inside the actual code somewhere ??

At least this way, it makes it harder for hackers to be able to do a locate on the file name

Is that doable ?

[Karl]

Unfortunately it would be still be easy to find the password if it was just written to a random file, although I do have some ideas on making it harder for the password to be found.

[redskins_43]

I will be using Ventures Online. Is there something I need to inform my host about?

I will be on a shared server to start and this thread makes me very nervous.

Thanks!