YaBBSE security level is very high!

[NumberOne]

Hi,

We've recently upgraded from gold sp1 to SE. We were confident that SP1 was pretty secure, meaning safe against hack attempts. With SE I'm not so sure. This is mostly because I don't know if it's easy to find out what the used MySQL db user and password is. This user has total control of the db, and a hacker with this user can easily erase your db. I've setup a site with MySQL db for pricelist, and the user is placed in an includefile so it's harder to obtain. And we use a readonly user for the public part of the site. Can anyone tell me how hard it is to obtain an YaBBSE sqluser and password? Or the general idea of SE security? Tips on protecting against hacks?

[Jeff Lewis]

Well...I haven't heard of a single hacked SE yet.  I remember when having those pop up in YaBB Gold - those days were awful when something would pop up  Scrambling about to fix it

But it's pretty tough, the db information is in a file that is included as well for SE.

As far as I'm concerned, it's very secure.

[Mach8]

The only ways someone could possibly penetrate your system are:

1) If you had a login script for a database manager and they found a way to brute force it... would take them a while though and most likely you'd cut them off after 3 login attempts.

2) You had a weak username/password combo which they could guess easily.

3) The database was running on a system they had PHYSICAL access to and could change the database from there (either through files or through an admin interface)

4) You give someone admin access, they login to the admin center, get the database details, connect with phpMyAdmin and do what they can (whatever the account rights give them the ability to do).

However YaBB SE itself is relatively secure - the error log informs you if someone tries to access somewhere they can't, and the fix that many forums also made stops a cookie exploit from grabbing usernames and passwords. So you've got nothing to worry about.

[Jeff Lewis]

And that cookie exploit was never a vulnerability of SE...we had protection in before other systems had that hole.

[pablo]

This issue concerns me. I believe that YaBB is not very secure for two reasons.

1) Settings.php sits in the same folder as Index.php, which means it is accessible by http.

eg. http://www.myforum.com/community/Settings.php

If PHP happens to crash (which I believe some hackers are capable of), then PHP code becomes viewable, just like it's an HTML page. More often than not, that means the code is there for all to see without even needing a View Source.

Since Settings.php contains the db username and password, it's vulnerable.

I'm new to this game and don't know how to create a mod, but I've done my own modification that solves this.
I can provide details if it's of use, but the basic idea is that Settings.php is tucked away in a different part of the site structure that is accessible by FTP but not HTTP.

2) The administrator can view the database username and password. This appears on the screen in a non-secure (SSL) way. I'm not keen on this as it does make the whole database vulnerable.

A mini solution would be to have the database details on a separate page than the main forum settings, so at least I know which link not to click on in the Admin page.

Not sure how you'd make a truly more secure solution unless you simply make this non-editable through the interface. (I'd be happy with this solution too.)

Muchos gracias for a great system.

Cheers,
Paul.

[joshxpcable11]

Everyone remember too rip out install.php after installing, my friend tryed leaving it there, and  I created an admin account (but I didn't hack him) just too surprize him

[Sava]

This issue concerns me. I believe that YaBB is not very secure for two reasons.

I'm new to this game and don't know how to create a mod, but I've done my own modification that solves this.
I can provide details if it's of use, but the basic idea is that Settings.php is tucked away in a different part of the site structure that is accessible by FTP but not HTTP.

 can you share that idea ? coz Im really interested in it, i was hacked once w/ YaBB Gold, and one with SE, so I do need something for security

 
 

[pablo]

By default, Settings.php sits in the same (public) folder as index.php. Let's say that this folder is /web/yabbse, where /web corresponds to the http root.

Therefore, http://www.mysite.com/yabbse is the URL for the board.

To make Settings.php inaccessible by http, it needs to be in a different path, say /code/yabbse. There is now no way to type in a web address that can access it. But, your PHP programs can still access it. To avoid putting the path explicitly, use a relative path. For example, a reference from index.php to Settings.php would now be ../../code/yabbse/Settings.php.

So here are the steps to make the change throughout YaBBSE... [line numbers refer to version 1.3.1]

1. Place Settings.php in an alternative path that is not http accessible. Let's use the above example. Make sure the CHMOD is set to allow public writing of the file and the Settings_bak.php file that will also be created in that folder.

2. Add a line to Settings.php, say after the definition for $boarddir [line 69]:

Code Select Expand

$settingsdir = "../../code/yabbse";(You could also use the absolute path /code/yabbse if you want since this code is itself hidden away. If you were to do step 5 below, though, it's strictly best to stay relative.)

3. In Admin.php (Sources folder), in function ModifySettings() [line 832]:
change from:

Code Select Expand

if (!@copy("Settings.php","Settings_bak.php"))change to:

Code Select Expand

global $settingsdir;
if (!@copy("$settingsdir/Settings.php", "$settingsdir/Settings_bak.php"))
4. In Admin.php, in function ModifySettings2() near the top [line 1203], add:

Code Select Expand

global $settingsdir;
5. Note to the venerable YaBB SE developers, in case they decide to incorporate this idea at some point...
There should probably be a default definition for $settingsdir in Admin.php around line 1246.
For now, skip this step as it's unnecessary (and probably confusing).

6. In Admin.php, line 1348, add the line:

Code Select Expand

\$settingsdir = "$settingsdir";
7. In Admin.php, line 1437,
change from:

Code Select Expand

$fh = fopen ("$boarddir/Settings.php",'w');change to:

Code Select Expand

$fh = fopen ("$settingsdir/Settings.php",'w');
8. Finally, in index.php, line 38,
change from:

Code Select Expand

include_once ("Settings.php");change to:

Code Select Expand

include_once ("../../code/yabbse/Settings.php");(This one must be a relative path.)

That's it.
Pretty simple and I have not had any ill effects, so I think I've got all bases covered. Please let me know, anyone, if you think there's something wrong with this, and why.

Hope this is useful.
Best,
Paul.

[mediman]

If PHP happens to crash (which I believe some hackers are capable of), then PHP code becomes viewable, just like it's an HTML page. More often than not, that means the code is there for all to see without even needing a View Source.

if a hacker crash php then he also crash the server and all you will see is a error 500!

only if the php parser will not parse the php code, then the code will be readable by everyone! but this can´t be done by a crash!

and, last but not least, you can use a php-wrapper to run your php files secure!

a simple way to avoid that anyone can read your passwords is to copy the settings.php outside your public_html tree!

medi

[pablo]

Hi medi. Nice to see you folks are watching.

if a hacker crash php then he also crash the server and all you will see is a error 500!

only if the php parser will not parse the php code, then the code will be readable by everyone! but this can´t be done by a crash!

I stand corrected, but you still agree that it is possible for php code to sometimes get exposed. (In fact I read somewhere about this possibility - I think it was a PHP book. Whether it's strictly a crash or perhaps a fault at the ISP for not enabling the parser seems to miss the point.)

and, last but not least, you can use a php-wrapper to run your php files secure!

a simple way to avoid that anyone can read your passwords is to copy the settings.php outside your public_html tree!

Exactly! And that's exactly what my suggested mod does. Nothing more. Nothing less.

It puts Settings.php outside the public_html tree and let's the rest of the system (ie. index.php which reads and Admin.php which writes) know where it is.

Useful?

Cheers,
Paul.

[mediman]

great work! a friend works on a security wrapper for yabbse, but at the moment it´s to difficult to set up for people that not understand how php works! so he will make it a little bit more easy to set up!

medi

p.s. but you are on the right way!

[savavn]

pablo, but w/ users like me, who cannot have access to the part outside of public dir, what can we do then ?

 as i understand, ur way only can apply to those who have access outside of public_html dir eh? correct ?

[mediman]

you can use a wrapper or let it! the chance that anyone can read your php quelltext is not very high! most cracker use brute force attacks and attack your ftp account not Settings.php!

i know at the momemnt not 1 yabbse that was hacked by reading the passwords from settings.php!

medi

[pablo]

In answer to both of you...

nosmile:
Yes, you are right. To do the mod I've posted, you need access outside the public pages. In other words, if my FTP root is \, then my web root is \web. If you have a responsive ISP, you can ask them to point your domain name to a subfolder of your FTP space. Some will do this automatically. If you're on a free account, probably not.

mediman:
I agree that the chances may not be high, but I provide web design services to commercial customers and I make a point of making serverside code as safe as possible, especially where it places personal information at risk.

And perhaps the example of a hacker attacking the system was not a good one. It could simply be an error by the ISP who gets the basic server going but fails to enable the PHP side of things after a reboot. Or some other scenario by which the PHP pages are treated as HTML.
 
(We have a new Data Protection Act in the UK and I need to be able to prove that I have taken reasonable measures to safeguard personal information.)

Cheers,
Paul.

[Hypocrite]

The SSI.php needs to be changed also or else it will give you an error message.

Code Select Expand

include_once ($full_yabbse_path."../../code/yabbse/Settings.php");