Your sites largest security risk

mydatery posted 30th of September 2009 in Community Voice. 10 comments.

Okay, I really hate it when I have to get serious, but this is a serious issue that needs a solution to it, thinking a security patch needs to be done on this one.  I was talking with another member who got some index.php files dropped on their server and this when we realized how large the risk is.

 

Each of us has a file on our sites (I'm not saying the name of the file as crackers do come in here from time to time and this is a large issue) that contains in it the most sensitive information our sites have.  It's basically the key to everything that sits on our servers and is a free pass to anyone who obtains it and knows how to access servers once they have it.

 

I"m specifically talking about the username & password that sits in a file on all dolphin installs and only runs 644 permissions.  With this file, anyone who is able to open it and knows what they are looking at will get, unencrypted the passwords to our DB's & FTP's with almost nothing we can do about it.  Think about this for a moment.

 

If a hacker manages to find their way into the server via anonymous FTP, crossing from site to site in a shared server and so on, then they can open up the file that every single page calls, access the DB, change tables, steal data, export your entire site, upload new files via FTP, change server configurations and so many more fun little things. 

 

Now, Boonex has taken the time with Dolphin to encrypt all user passwords for the members and even into the Admin Panel, but there is NO encryption of the password sitting right there in the files not very far from the root directory and the file is screaming out with it's name what it is.  Just begging a cracker to open it.  (**Note:  Crackers are the ones that destroy things, drop malicious code, break into servers and so on.  Hackers are individuals of high intelligence who when presented with a problem will play with the code and look for a solution.  Let's not beat on the hackers with this post)

 

Now, we can drop a blank index.html file into every directory to reduce risks, phpBB3 does that with their base install.

 

We can lock down FTP on the server from all IP's except our own.  But when you travel like myself and others, that is not always a viable solution as we don't always know what our IP will be from day to day.

 

Mrpowless posted some type of solution for the .htaccess files, but I can't find it right now.

 

In the end though, we're looking for the guys who know servers, dolphin & sql DB's to hop in here and possibly show a way that this can be resolved.  I know we have to have the password there, but is there a way to encrypt that pw for when someone is looking at the file and still enable the sites to run?

 

Let's here the ideas on this one... And Boonex, this should be at the top of the lists for D7 as I'm pretty sure it has the same issue.

 
Comments
·Oldest
·Top
Please login to post a comment.
houstonlively
Unencrypted mysql connect info in files with 644 permissions is quite common... probably because it's the only place to put it. As long as nobody has ftp access to your site, it's not really a risk.

If you have decent virus/anti malware on your computer to detects RATs, and don't store your ftp login info in your ftp program, you're pretty safe.

Most of the iframe injections on servers are not done with the intent of hacking the server. It is usually the hackers intent that the iframe be see more inserted, and the site continue to operate normally, so that visitors to the page will have a RAT planted on their computer.... so that computer will become part of a bot net..... which hackers can sell for big $$$. The worst case scenario for having these RAT distribution hidden iframes on your site, would be to have Google index your site while they are present.... I can't think of a worse fate for a site, than to be blacklisted by Google.

With that said, I don't think it's Boonex's responsibility to keep other peoples servers and personal computers secure. It's not Boonex's responsibility to prevent uninformed web site owners from becoming their own worst enemy. That's up to the web site owner. Where Boonex's responsibility lies, is ensuring that the script itself is not vulnerable to things like XSS and SQL injection attacks.... not to form some sort of witless protection program.

If someone has ftp access to your site, unencrypted passwords in files are the least of your worries. Just let me upload a few php files to your shared server, and I'll have shell access. From there, I could take down every site on the server.
cbassthefish
Ah beat me to it. Only by 7 minutes though :o)
cbassthefish
I think I know what you are on about. I do not think it is a problem as long as permissions are correct. 644 seem correct to me as it only gives the owner access. Also as long as people prevent the ftp hack by having a good firewall installed and anti-virus/anti-malware program. Lastly not giving out your ftp account details is also good.
To be honest I do not see a password being stored in a file as a big problem. I have done a fair few Oracle database installs where there was no other option than see more to put the password in a file for validation. Oracle are pretty big on security and so if it is not a problem for them then is should not necessarily be a problem here. People just need to take the appropriate 'precautions'.
Although I understand your concerns Mydatery, as when I first had to do a database install, where I had place an unencrypted Oracle database admin password into a file, I stressed about it, but then it was explained to me. All said, this is a good blog post to inform and stress to people the importance of security and permissions.

Paul
mydatery
I'm not talking about an issue with 644 perms. What I'm talking about is that the pw sits there in the file unencrypted in the event that someone hops into the server, just as you mentioned there Houston. This is especially of concern in the case of shared servers.

Only a 0000 perm will ensure a file can be read by noone, of course that means your site will only throw error pages too!
DosDawg
mydatery, there are many scripts that have this same type of file. phpnuke, postnuke, e107,jamroom,and basically any other web application that has a cfg file. i think you could be correct, but the probability is unlikely. houston is correct the Iframe injection is not necessarily intended to take down a site, as much as it is to make the site owners machine a node in their network. security hardening is the responsibility of the site owner and the hosting service provider. at any rate, it wasn't see more a bad idea to discuss this, and there are many other options that we could embellish upon that could and have granted access to vulnerable websites.


Regards,
DosDawg
ZopfWare
Just out of curiosity, how would you go about encrypting the password that is needed to get into the mysql DB? Would you store it in another mysql table, ie a clear password in a file that is used to access a mysql DB that has the encrypted master PW in it?

On most secure systems, or systems that process Credit Card data, they use a hash to store the Credit Card data. This hash requires one to KNOW the passphrase or PIN to actually decode the data that is stored. Although this is extremely see more secure, how would you use such a security measure with Dolphin?

Just trying to look at the logic of the situation. Dolphin must allow Apache or the user to be able to look at the file in the clear. This is what the file permissions ability of Linux (or Windows) is all about. Otherwise someone would have to always enter in a pass or pin when they got to the site.... does this make sense?
buckmcgoo
When I first got into web developement I thought it was CRAZY that those config files had the password in them. Then I saw it was like that in every CMS and script on the market. The directory that has "the file that shall not be named" should have a .htaccess file in it that has "deny from all".. this will prevent anyone outside the server from accessing it. Now if someone can find a file on the server that has a security flaw that allows it to display the content of another see more file you are in trouble. I believe that is how phpbb.com was hacked about 8 months ago, they were using a mailing list program that someone figured out would display the content of another file on the server. The person used it to view the database config file. I could be mistaken but that is what a brief article I read about the incident said.
ZopfWare
I agree with DosDawg... 644 permissions are ok if your server is properly configured. Even on a shared server this is sufficient even if another "shared" customer's site is compromised. I believe that this is what the open_base_dir restrictions are all about. Now (speaking to those who are running dedicated servers or are in the hosting business) if you have a MAJOR breach of security such as allowing your customers on a shared server to have non chrooted ssh access, then you are asking see more for trouble with more than just Dolphin scripts.

This is a good discussion topic because Dolphin WILL run with unsafe permissions if it is not installed correctly. (This is despite the installer check for permissions)

Many of the hacked sites I hae seen were either because someone had overly permissive settings on Dolphin, or primarily, because they had some other script that had wrong permissions. People tend, when they are given the opportunity, to install all sorts of things on their websites that they want to try out, and then forget about them. Thereby, giving a hacker the time and opportunity to break into their site.
gameutopia
If you are referring to the header file it's well known that your database connect info is stored there. You can't see the contents of the file by entering it in your browser. You will just see a blank page. Anyone can find your database name which incidentally is usually your cpanel and ftp login by simply viewing: http://www.yoursite.com/periodic/periodic.file in a web browser. This is only one example of many. One still wouldn't know the dbuser or dbpass. It will tell you the mailto: cron email see more though if one wanted to spam someones email box this could be annoying. Most sites you can actually view the contents of someones .htaccess file too if you want. All you do is punch in yoursite.com/.htaccess and you can see the contents in your browser. Not that you will get much out of it either. You can add to root .htaccess so nobody can view them in a browser:
<Files .htaccess>
deny from all
</Files>

<Files periodic.file>
deny from all
</Files>

Another thing is even if guests aren't allowed to view movies for example, all you have to do is punch in yoursite.com/ray/modules/movie/files if directory browsing is allowed one can watch or download them all with a simple click. If directory browsing is disabled or or index.php/index.html is present then all one has to do is yoursite.com/ray/modules/movie/files/1.mpg(or 1.flv) and just keep on a going 2.mpg, 3.mpg, etc. And no need to join the site. Same with music, mp3, photo gallery, profile photos, etc. Anyone that knows dolphin directory structure can figure this out. A simple free dolphin download by anyone not familiar with it and they know where to look. Not a security thing, but more of an inconvenience. You can do the same with almost any site or script out there if you know what script it runs unless there are .htaccess or other modifications in place. Then again there is software that can do it for you or tell you exact locations too.

If you don't want people browsing your folders or directories that don't have an index.php or index.html you don't need to drop one in each and every folder or directory. You might be there a while doing that. You can if you want, but you'll probably miss a few. You can just add to your main .htaccess in the root to cover your entire site:
Options -Indexes Some say they have had issues with this in the root, I never had any problems with it there. You could put it in sub-dirs .haccess instead if you have issues and still save yourself a lot of time.

If you put it in the main root .htaccess it takes care of all folders or directories under it. If you opt to put it in /media/.htaccess for example it wouldn't affect the root, only /media and every folder under or below /media such as /media/images etc.

If you put it in root .htaccess but you don't want /media to be covered by this then in /media/.htaccess you would put Options +Indexes.

Sort of faster than adding a index.php or index.html to every folder or directory. Cpanel hosting also has this option to turn off index browsing in cpanel you can use "Index Manager". Basically it just adds Options -Indexes to .htaccess for you, and you can choose root or specific directories. Helpful for people that are not sure how to manually do this. For me it's faster to manually add it by ftp, and sometimes cpanel messes up, so I think it works better manually.

Just a couple of examples. If you really think about it there are many more. And a lot of other things you could do if you want to take the time, and are concerned about security or people viewing files and folders that you would rather not. If you have vps or dedicated there are additional things one can tighten up for security that shared hosting folks don't have access to. You hope that your shared host has taken extra steps concerning server wide security on your behalf.

Anyway sorry to ramble on...Laters!
Riggy
It's my understanding that my sites biggest security risk is sharing my ftp password with Caltrade. Any truth to that?
 
 
Below is the legacy version of the Boonex site, maintained for Dolphin.Pro 7.x support.
The new Dolphin solution is powered by UNA Community Management System.
PET:0.071937084197998