Big Security worries with Sugar!

[mycrmspacegunnar]

Hello,

Working with Sugar for quite some time I have noticed a number of big and small security items and issues which worry me a lot.

Maybe someone of the Sugar team can comment on them and hopefully most of my worries are unbased.


1) PASSWORD PROBLEM
What does someone prevent from just guessing a users password?

When someone uses Sugar for a email campaign then he usually sends out thousands emails that all include the internet URL of our used Sugar installation.
So after one email campaign thousands of people know the URL of this Sugar installation. What prevents a competitor from just trying to guess the password of your users?

As far I a saw Sugar does not much to protect itself against this.
- There is no password policy like minimum password length that can be enforced.
- Users are not forced to change their password
So the admin does not know the user have updated their passwords at all or still have "pass" or "changeme" as password.
- I haven't seen a method that prevents someone from guessing huge numbers of password.

Writing a little script that tries to login and that guesses passwords is a no brainer.
Most kids will write something like this in a few minutes.
Yes, Sugar logs failed password attemts but once someone is it - its a plain simple to remove this logs and erase all traces.

Its clear to us that writing a small script that guesses password is very easy to do.
Once you got access with an admin account (as many people will leave their admin user called "admin" so this is propably no big deal), you can install a small module that patches the system with a backdoor and that will remove all your traces.

And if someone does this on the Sugar system of a competitor then he will see all the quotes and communiations with customer. I'm sure many will find this information very interesting and usefull....

I think it would be better if Sugar would povide the following:

- Per default easy seperation of internal and external Sugar
For Sugar systems that are installed on the internet I want to be able to protect them with something like a client side SSL sertificate or password and still be able to run an email campaing.
I want to be able to run an email campaing without publishing the URL of my company Suger system and login page to the world.

-Some sort of password strength enforcement
We all know that users are lazy.
Without some enforcement most password will be just the first name of the user or of his wife. Such simple password provide us no protection at all! Guessing and breaking into so simple password is only a matter of minutes.

- Some sort of login disabling and email warning on break in attemts.
We need some security measument that disables the login after a certain number of failed attempts. With the current system I can write a SOAP client that tries hundreds of password per second. When I run this over the weekend I'm nearly certain to get in someones Sugar install. And once I'm in, I have no problem to remove all my the traces and logs.

- Remove everything that help attackers
Per default Sugar writes its logfile in the main webserver folder.
On a default Sugar installation the whole world can download this logfile.
Amoungs other information this logfile will contain the login names of people using this Sugar installation.

2) Document Security
As far as I can see the current security system of Sugar is fully based on obscurity.
All the documents are fully accessable to the webserver.
As soon as the id of an Sugar document is knows its fully accesable to anyone.
Basicly everybody worldwide can read the documents in Sugar when the id is known.
Neither password nor login are needed for this.

Isn't this a big conseptional weakness?
You could easely fix this if Sugar would not store its documents in the root webserver folder but if Sugar would store the files in a parallel folder which is not directly accesable with a browser. This way you could allways controll that on access the rights and permissions to see the document are all fullfilled.


3) PHP file security
The "index.php" is the entry page for mostly all user accesses.
Depending on the access numberous other PHP source files will be loaded and executed by this file.
All hunderds of different PHP files are placed in the webserver folder they are all directly accessable with a webbrowser.
Direkt loading and of these files is or course a big security risk as by directly accessing the files, people can easely go around the login and password routines and create havoc. Each of the files tries to protect itself against direct loading by checking some status variables.

But how secure is this?
There are hundreds of files..
If this check is forgotten in just one you can have big security issue.
A file of thrid party module could accidently forgets to protect each file against this.
So certainly don't check all available Sugar modules to prevent such a case, do you?

And what if if a user accidently runs his webserver in a backward
compatible mode that allows direct setting of variables from the browser.
Will this protection then work at all?
Isn't having include files laying the main webfolder the number one amateur error, which broke the neck of so many home grown php programs?

Wouldn't it be much more simple to move all PHP source files and include files out of the folder which is directly accesable for the webbrowser?


4) Constant write access to all the source files needed
Per default Sugars PHP files will be fully writeable by the webserver.
And Sugar requires that all the PHP source files are writeable to be able to install a patch. I have to admit that this requirement scares me a lot.
That the files are writeable is no risk as long as all the PHP files are error free.
But I saw "hickups" in Sugar file upload routines creating "C:" directories and "c:documents" folders inside the main Sugar folder. I don't know how one of our users was able to produce this hickups and if they were created SOAP or normal Sugar uploads as was not able to reproduce them myself. But I think having all the Source files writeable is a big conceptional weakness.
Couldn't any bug in a upload routine this way easely be exploited to take over the System?


I'm really concerned by all this thoughts.
I hope that I'm somewhat wrong with my thoughts and if not I hope that you look at the items.


Many thanks in advance

Gunnar

[andydreisch]

Hi mycrmspacegunnar, thanks for the insightful comments. I'll ask the Sugar security team to address your points. We'll be sure to come up with a gameplan for closing any gaps that should arise from your analysis.

We encourage others to comment as well and perhaps we can roll multiple such changes into baseline Sugar.

Andy

[longreach]

Personally, I think concerns 1 and especially 2 are fairly valid. Number three is I think over-stated - Sugar has historically worked hard on this front, and the status quo is not bad - although of course anything can be improved. And number 4 is surely just a bad admin, if they leave permissions wide open between updates.

[mycrmspacegunnar]

And number 4 is surely just a bad admin, if they leave permissions wide open between updates.

Maybe you can help me to understand how you would close the permissions.
As far as I see, to be able to use Sugar you need to leave tons of files wide open.

Sugar uses a concept of selfmodifying PHP code.
Changes of many Sugar settings, changes to labels, or changes to the layout
are all stored in PHP or template files. To be able to normally use Sugar
you need to leave tons of files unprotected, don't you?


Cheers
Gunnar

[longreach]

Well - an upgrade requires the web server user be able to write to pretty much the entire install dir. So - you turn that on for the upgrade, and then back off.

Using the Studio is not something you should be doing every day - it is more typically used as the system is being implemented - at which point the system typically has little or no client data. Again - turn off write access to the customization files areas when you are done.

And last issue is admin settings (System Settings, for example) that write to the installation dir - often config.php. Again - admin is in charge - so close off write access when done.

These three use cases are not 'normal use' to me - they are admin use, not user use, and they are more at implementation or upgrade time than normal usage periods.

[kbrill]

Maybe you can help me to understand how you would close the permissions.
As far as I see, to be able to use Sugar you need to leave tons of files wide open.

Sugar uses a concept of selfmodifying PHP code.
Changes of many Sugar settings, changes to labels, or changes to the layout
are all stored in PHP or template files. To be able to normally use Sugar
you need to leave tons of files unprotected, don't you?


Cheers
Gunnar

I apologize in advance if this gets preachy, it is NOT my intention to trivialize your concerns, but some of you assertions simply are not true and others are easily overcome. I welcome all discussions about security as in the end we all learn something. That being said....

the only files Sugar writes to on a daily basis is suagrcrm.log and the cache dir. when doing an upgrade or loading a module you need to open it all up. but afterwards only the log and cache need to be open.

Given time ANY system is vulnerable to attack. There are things SugarCRM could do better (better user passwords and only 3 tries) but I can think of about a 1000 things I have seen that are far worse. If you have your ownerships and permissions set up properly, have a good password on your MySQL database and root accounts, have your .htaccess file set up SugarCRM is as secure and hacker-proof as any Pentagon computer so far.

If you are worried about people from the outside world getting into your system set up a .htaccess file on it so you control the main password and make is strong and change it monthly. That way even if they have your address they are never getting in. If set up properly only the outside worlds needs to be asked the password, the inside world can bypass it.

If you are worried about the log file (unless you leave your log file settings set at 'debug' or something I can't say it would be an interesting to read even if someone would get it, it's among the worst log files I've seen for diagnosis but that's another discussion. The 'fatal' setting never logs usernames) then move it off the HTTP map somewhere. It's completely configurable from the log4php.properties file.

Per default Sugars PHP files will be fully writable by the web-server.
And Sugar requires that all the PHP source files are writable to be able to install a patch. I have to admit that this requirement scares me a lot.

Any program you install on a PHP based web-server will have to be writable until YOU manually change it's permissions, and Sugar DOES NOT require all of it's files to be writable. See above. And of course the files and directories have to be made writable to install a patch, now I would like to see the module loader automatically change the permissions it needs to accomplish it's task but it wouldn't work on my system anyway as I disable the PHP commands that allow you to run external scripts and change permissions as part of my security set up.

Basically everybody worldwide can read the documents in Sugar when the id is known.

Again, only if you allow world wide people in your system. Again it's your machine, it's up to you to secure it properly. I don't like the current document management system in sugar, but even if the files were moved off to an outside directory, by definition they have to be accessible to users. So if someone knows the ID and the name of the file no matter where the file is located they could hack into the document access script and get the file if they are skilled enough and you allow them access to the right files. Also a well written .htaccess file would prevent direct access to the documents directory.

Writing a little script that tries to login and that guesses passwords is a no brainer.
Most kids will write something like this in a few minutes.
Yes, Sugar logs failed password attempts but once someone is it - its a plain simple to remove this logs and erase all traces.

Its clear to us that writing a small script that guesses password is very easy to do.
Once you got access with an admin account (as many people will leave their admin user called "admin" so this is probably no big deal), you can install a small module that patches the system with a backdoor and that will remove all your traces.

OK, a few things here. A few things here are not exactly true.

1. SuagrCRM has NO default admin password when installed. Just the way it should be. If you install SugarCRM on a production system and choose a crappy password then you deserve to be hacked. Of course I would like to see SugarCRM NOT force you to use 'admin' as the name of the admin account, that is an easily fixed security issue and I have submitted it as bug #11412.
2. My boss could not write this script, my wife could not, my accountant, mom or dad could not and I imagine this is out of reach for more than 80-90% of the people in the world.

But I digress, given a script and given that it someday might be successful in logging you in (I have had only one system in 20 years where someone tried a brute force attack and actually got in. It's a VERY amateur hack and is used but is not very common anymore. Especially against a website, there are easier ways to get past apache or even Linux and certainly Windows 2003) even if logged in as a user to SugarCRM you have no way of deleting or altering the log file. Even if logged into the system as the admin user (if someone guesses your admin password on a production system then you need to retire as an administrator). Again, with a good .htaccess file and proper permissions and an up to date system (all patches applied) this is a something that should NEVER be a problem. Again you can also just move the log file to the logs directory anyway. I would like to see Sugar disable an IP that misses the password more than 3 times and send an email to the admin. But in the final analysis that would not make the system any more secure.

And what if if a user accidentally runs his webserver in a backward
compatible mode that allows direct setting of variables from the browser.
Will this protection then work at all?

Yes it will as the protection is based on a defined constant and not a variable. Again I can't stress enough that even perfectly written software can't help if the administrator doesn't do his/her job.

Isn't having include files laying the main webfolder the number one amateur error, which broke the neck of so many home grown php programs?

You can find people on both sides of this. Is a system with the files outside of the webserver directory more secure than one with the files in the server directory? In my opinion, no. If someone hacks into your system then no matter where your files are they are vulnerable. I don't know why where they reside makes any difference. They still have to be accessible to the webserver anyway. Any increase in security would only be seen on a system that was not properly secured in the first place.

A final word. Your system is only as secure as it's weakest point. And SugarCRM, as it stands, is not the weakest point. I don't have my main website secured properly right now. My permissions are all screwed up and I don't have a .htaccess file in place because I have been too busy and I don't care if I get hacked. Why? Because I have no data on the system that anyone else would want and I have daily, off-site backups of both the data and the files. So hack away and I'll still be back up in an hour or so. This SHOULD NEVER be the case on an actual production system. Security should be your job #1.

[kbrill]

Well - an upgrade requires the web server user be able to write to pretty much the entire install dir. So - you turn that on for the upgrade, and then back off.

All good points, I forgot about Studio stuff, and you are right, the admin still has control over the permissions on his/her system and a simple script could set/reset the permissions so that Studio would work securly.

[andydreisch]

I created bug 11413 for this: I would like to see Sugar disable an IP that misses the password more than 3 times and send an email to the admin.

Andy

[mycrmspacegunnar]

If you are worried about people from the outside world getting into your system set up a .htaccess file on it so you control the main password and make is strong and change it monthly. That way even if they have your address they are never getting in. If set up properly only the outside worlds needs to be asked the password, the inside world can bypass it.

You are quoting my first proposal with adding a server password aren't you?
Personally I would find securing a Sugar install with a client side SSL certificater much more elegant than a password via htpasswd.

To be honest I see no easy way of enabling such a htpasswd protection for Sugar.
Maybe you can be so kind to give a working example?

If you are worried about the log file (unless you leave your log file settings set at 'debug' or something I can't say it would be an interesting to read even if someone would get it, it's among the worst log files I've seen for diagnosis but that's another discussion. The 'fatal' setting never logs usernames) then move it off the HTTP map somewhere. It's completely configurable from the log4php.properties file.

The point is not that its not changeable, but that per default the logfile will contain the names of all users that mistype their login and that per default this logfile is world readable.
I think Sugar should be default not put the logfile in a world readable place.

Any program you install on a PHP based web-server will have to be writable until YOU manually change it's permissions, and Sugar DOES NOT require all of it's files to be writable. See above. And of course the files and directories have to be made writable to install a patch, now I would like to see the module loader automatically change the permissions it needs to accomplish it's task but it wouldn't work on my system anyway as I disable the PHP commands that allow you to run external scripts and change permissions as part of my security set up.

Its nice to know that your system is secure.
My point is not that Sugar CAN be secured by an expert.

The point is,
a) that people trying Sugar out will run it out of the box.
b) If you want to secure Sugar down then you can not install a module,
you can not use the Studio to change a form, or to update a dropdown, you can not even change a label. If you set Sugar to a normal file securety then everybody that wants to add a field to a dropdown needs to call the server admin first to unlock the filesystem ... This is not very productive.

I don't like the current document management system in sugar, but even if the files were moved off to an outside directory, by definition they have to be accessible to users. So if someone knows the ID and the name of the file no matter where the file is located they could hack into the document access script and get the file if they are skilled enough and you allow them access to the right files.

But this is the point.
If the documents would be stored outside the webserver then someone would actually need to break into and crack Sugars security system to get access.
Right now the files are open, you know the name you have access - there is no user name or password required to access them.

Also a well written .htaccess file would prevent direct access to the documents directory.

True but Sugar comes without it.
Of course an htaccess is better as nothing but NOT placing the files into the main folder would be even better and more compatible with other webservers too.

OK, a few things here. A few things here are not exactly true.

1. SuagrCRM has NO default admin password when installed. Just the way it should be. If you install SugarCRM on a production system and choose a crappy password then you deserve to be hacked. Of course I would like to see SugarCRM NOT force you to use 'admin' as the name of the admin account, that is an easily fixed security issue and I have submitted it as bug #11412
2. My boss could not write this script, my wife could not, my accountant, mom or dad could not and I imagine this is out of reach for more than 80-90% of the people in the world.

You misquoted me.
I've never said that Sugar has a default admin password.


I said that to hack into an account you need to guess the user name and the password.
As the default name of the admin account is "admin" and most people keep that name guessing the user name is no problem. An additional help for hackers it the sugarlogfile as it contains the user names and is readable per default so all what is missing is guessing the password.

But I digress, given a script and given that it someday might be successful in logging you in (I have had only one system in 20 years where someone tried a brute force attack and actually got in. It's a VERY amateur hack and is used but is not very common anymore. Especially against a website, there are easier ways to get past apache or even Linux and certainly Windows 2003) even if logged in as a user to SugarCRM you have no way of deleting or altering the log file. Even if logged into the system as the admin user (if someone guesses your admin password on a production system then you need to retire as an administrator). Again, with a good .htaccess file and proper permissions and an up to date system (all patches applied) this is a something that should NEVER be a problem. Again you can also just move the log file to the logs directory anyway. I would like to see Sugar disable an IP that misses the password more than 3 times and send an email to the admin. But in the final analysis that would not make the system any more secure.

Come on, you say yourself that it would be good to enforce strong password, to move the logfiles away and to secure Sugar with an extra webserver password.



Why do you say that this will not make the system any more secure?

Yes it will as the protection is based on a defined constant and not a variable. Again I can't stress enough that even perfectly written software can't help if the administrator doesn't do his/her job.
You can find people on both sides of this. Is a system with the files outside of the webserver directory more secure than one with the files in the server directory? In my opinion, no. If someone hacks into your system then no matter where your files are they are vulnerable.

You can not denie that:


Files or documents that are in the main webserver directory like in Sugar
are open to access form outside - they enable hacking.


But files that are not in the main folder can NOT be accessed and not be used as doors to come into the sytem.


How many hundred files are in Sugar?
With the current setup every single one of them needs to be 100% secured.

It would be no problem to move mostly all of them outside the direct access of webbrowser. Then mostly only one file would need to be secured.

I don't know why where they reside makes any difference. They still have to be accessible to the webserver anyway. Any increase in security would only be seen on a system that was not properly secured in the first place.

Please see above, it makes a big difference.

How much easier is it to 100% secure one page instead of securing hundreds of them?

And don't forget all the modules. With the current sentup just one not 100% secured files installed by a module can exploit a whole Sugar install.

A final word. Your system is only as secure as it's weakest point. And SugarCRM, as it stands, is not the weakest point.

I don't want to argue with you about this.
But I think is that there is plenty of room for improvement.

I don't have my main website secured properly right now. My permissions are all screwed up and I don't have a .htaccess file in place because I have been too busy and I don't care if I get hacked. Why? Because I have no data on the system that anyone else would want and I have daily, off-site backups of both the data and the files. So hack away and I'll still be back up in an hour or so. This SHOULD NEVER be the case on an actual production system. Security should be your job #1.

I fully agree with you.

Sugar is a system used by companies.
Everybody will fully agree with you that its critical to secure their information.





Please be so kind and give your htaccess example for password securing a Sugar side.


Cheers
Gunnar

[longreach]

Yes - I think you make mostly very valid points.

One I cannot quite agree with ...

"If you want to secure Sugar down then you can not install a module, you can not use the Studio to change a form, or to update a dropdown, you can not even change a label. If you set Sugar to a normal file securety then everybody that wants to add a field to a dropdown needs to call the server admin first to unlock the filesystem ... This is not very productive."

Actually - only SugarCRM admins can do these things anyway. And personally, I feel that if the admin is changing even labels and dropdowns on a regular basis, the working environment will not be a very productive one. Users like familiarity - keep changing things and they do not have it. Get it right and leave it alone for long periods - say 4-6 months at a time.