Is it possible to make WHMCS even more secure?

[Mortfiles]

After some conversation with Matt, who has patiently answered my many questions regarding the security of WHMCS and after reading the thread by Alfahmad regarding his security breach I am wondering if there are ways to make WHMCS more secure?

 

 

My first thought was regarding the admin login and since I deal with IPB now and then making designs for that forum software I was wondering if their approach for making the admin login a little more secure could work for WHMCS as well. In IPB there are a few options you can use if you like. One is to rename the admin folder to make it more difficult to locate and in addition to that you can set a secondary login using a .htaccess file, which should then use a different login than the standard admin login.

 

 

This way even if a troublemaker get their hands on the admin password in some way the secondary login would prevent him/her from using it unless they get their hands on both passwords.

 

 

I am not sure if a stronghold cookie feature has any impact on WHMCS, but on IPB it is used to prevent cookie theft if that could be used on WHMCS somehow.

 

 

The problem with direct access to the servers setup is something that would be a big problem if the login security is breached so I would like to see a way to reduce the possible security threat in some way, perhaps with a similar system like having a .htaccess file for completely different login, but perhaps that would make things annoying to work with? A security check that look at the IP of who is trying to access the servers might be a better solution where the admin have to login (I know...lots of security checks) when a new IP is trying to access this feature (naturally with a different password than the regular admin password). Not sure if this is just making things annoying and not really preventing anyone from abusing the server access system, so if you have other ideas, please don't be shy.

 

 

The idea of admin(s) being able to see the clients passwords in cleartext is a conscern for me even if its more a questions of integrity rather that security. It is likely that the clients are using their passwords on other areas of the web as well and unless you inform them that the admin(s) are able to see what passwords they are using it is a real integrity issue that I am sure the clients will get upset about unless informed. From a security point of view its only if someone has managed to gain access to WHMCS it is really an issue, but is it really a good idea to have it in cleartext anyway and is it really needed? As far as I can tell there is really no reason to see a clients password as they can manage it on their own through the recovery area and even in **** format the admin can reset it if needed?

 

On the topic of clients I would like to see a system where password strength are indicated when dealing with passwords to ensure that their passwords are more difficult to guess by troublemakers. This makes passwords a whole lot stronger and more difficult to crack should anyone get their hands on the WHMCS database than "Lisa" or "dog", which in the end protect the clients from security issues.

 

 

These are just my thoughts on the matter and I am no security expert by far, so if you have suggestions or opinions, please speak up. This is not a thread for bashing WHMCS security, so pelase keep your crtisism positive and helpful.

[rapidfire]

Hey Mortfiles...

 

I actually just came over here to the forums to see if it is safe to do what you have just described. I was going to change the name of the admin folder to something else and also htaccess it... But wanted to check first!

 

Let me know if you come up with anything!

[bear]

after reading the thread by Alfahmad regarding his security breach I am wondering if there are ways to make WHMCS more secure?

For the record, his email was hacked, not WHMCS. They then used that to request the password from WHMCS to log in. Nothing could have stopped that except better security for his email.

 

Carry on.

Oh, and look in the Wiki: http://wiki.whmcs.com/Furthur_Security_Steps

[Mortfiles]

rapidfire: I'll do what I can Adding a .htaccess file should be ok, but changing the admin name might not be so easy as there could be calls to that particular folder in the script. We'll have to check with WHMCS staff to make sure its safe to make that change.

 

Bear: I read that and while getting the admin password could not be prevented, but if the admin area had been changed to say...irfgh it would have made it more difficult to find and having a .htaccess file as a second layer protection it would have denied access to the admin login making the admin password useless.

 

edit: Bear pointed to the answer to the admin change question:

 

Change your WHMCS Admin Folder name

Malicious users who visit your site and recognise a WHMCS install will know that they can try logging into your admin area via the admin folder. To protect against this, you can rename the admin folder name to any name you like. You cannot move the folder - only rename it. You can then tell WHMCS what the name of that folder is for the links in admin notification emails by adding the following line to your configuration.php file:

 

$customadminpath = "myadminname";

[mylove4life]

Thanks for that info Bear, that is good to know...

 

For the record, his email was hacked, not WHMCS. They then used that to request the password from WHMCS to log in. Nothing could have stopped that except better security for his email.

 

Carry on.

Oh, and look in the Wiki: http://wiki.whmcs.com/Furthur_Security_Steps

[Mortfiles]

Change your WHMCS Admin Folder name

Malicious users who visit your site and recognise a WHMCS install will know that they can try logging into your admin area via the admin folder. To protect against this, you can rename the admin folder name to any name you like. You cannot move the folder - only rename it. You can then tell WHMCS what the name of that folder is for the links in admin notification emails by adding the following line to your configuration.php file:

 

$customadminpath = "myadminname";

 

Does this mean that it only effect the links in the admin notification emails...because if it does that would be great as I want to remove those from emails anyway as I know where my admin area is and don't need links to it

[danami]

Some Suggestions:

 

1. Server passwords should be encrypted using the same technique as the CC cards (The admin can decrypt them and view them with a secret key).

2. Option for the "lost password" feature to be disabled for root admins.

3. All client and admin login forms should get brute force protection (temp locked out after X failed attempts)

4. Http only cookie support

5. Third party security audit of all WHMCS code.

[Mortfiles]

Good suggestions danami.

[ask21900]

Some Suggestions:

 

1. Server passwords should be encrypted using the same technique as the CC cards (The admin can decrypt them and view them with a secret key).

2. Option for the "lost password" feature to be disabled for root admins.

3. All client and admin login forms should get brute force protection (temp locked out after X failed attempts)

4. Http only cookie support

5. Third party security audit of all WHMCS code.

 

 

1. Great Idea

 

2. I'm going to take this a step further and say it should be disabled for all admins. Root admins should never forget their password (and definitely not all of them at once). If any admin looses their password, they should contact a root admin to reset it for them. IMHO anyway

 

3. They already do IIRC. I think there is an option in the config to deny for x min after failed attempts.

 

4. Ok

 

5. I would say that the 1000s of WHMCS users pretty much qualify as a 3rd party audit, after all, we're doing it right now.

[bear]

I would say that the 1000s of WHMCS users pretty much qualify as a 3rd party audit, after all, we're doing it right now.

 

Not exactly. By audit, I'm sure they mean to look over the code with an eye for exploits. Sometimes when coding, little things can go overlooked or forgotten that might be used as an attack vector. Having someone audit the actual code can sometimes bring that to light.

 

I don't know of any professional service that offers this, however, and I'd be very leery of providing the raw code to a third party anyway, if I'd written something as valuable as WHMCS.

Know someone that does this service professionally? I'd love to know who.

[danami]

I don't know of any professional service that offers this, however, and I'd be very leery of providing the raw code to a third party anyway, if I'd written something as valuable as WHMCS.

Know someone that does this service professionally? I'd love to know who.

 

What I suggest is at least:

 

1. Download some php security auditing tools like Spike PHP Security Audit:

http://developer.spikesource.com/projects/phpsecaudit

 

2. Download the trial version of Zend Studio 5.5.1 (not the eclispe version) and with a file loaded in the IDE .. right click and choose analyze code (it will go through the file looking for security holes / logic errors / . I can guarantee that it will catch a lot of coding errors:

http://www.zend.com/products/studio/downloads

[AVeal]

I don't think an audit is so much needed with Closed-sourced work; It would be different for Open Source (Such as IPB which has audits).

 

I like ideas's 1, 2, 3.

 

Could somebody explain point 4?

[bear]

Download the trial version of Zend Studio 5.5.1 (not the eclispe version) and with a file loaded in the IDE .. right click and choose analyze code (it will go through the file looking for security holes / logic errors / . I can guarantee that it will catch a lot of coding errors

 

Hmm...I have a slightly older Zend version (too pricey for me to keep renewing) and never had it tell me about a security issue when I used analyze. I can't imagine my coding is good enough not to contain some security issues, so I'd have to assume that Zend isn't checking mine for security. It tells me about the use of globals, assignment operators and things of that nature, but not once security. Hmm...

[uberhost]

Since a substantive php code audit will likely cost more than £5000 I seriously doubt that it is an option for Matt. Definitely change your admin folder name and admin user name for basic security.

[danami]

I don't think an audit is so much needed with Closed-sourced work; It would be different for Open Source (Such as IPB which has audits).

 

I like ideas's 1, 2, 3.

 

Could somebody explain point 4?

 

Http Only cookies is a new extension to the cookie standard . Currently not all browsers support it but they should soon. The idea is that cookies marked as httpOnly cannot be accessed from JavaScript (therefore you can't steal a users cookie using javascript). IPB uses httponly cookies in conjunction with their "stonghold" cookie (which is basically just a separate cookie that is set which is based on the first 2 octets of your IP) -- if a your IP doesn't doesn't match the first two octets then the page request is denied). They only use the first two octets as some ISP's use rotating proxies (like AOL) .. so the first two octects should match even though the IP has changed).

 

I do agree that a third party security audit might seem a little expensive .. at the very least having different eyes looking at your code is still generally a good idea.

[mikie]

Change your WHMCS Admin Folder name

Malicious users who visit your site and recognise a WHMCS install will know that they can try logging into your admin area via the admin folder. To protect against this, you can rename the admin folder name to any name you like. You cannot move the folder - only rename it. You can then tell WHMCS what the name of that folder is for the links in admin notification emails by adding the following line to your configuration.php file:

 

$customadminpath = "myadminname";

 

Wouldnt it be simplier just to password protect the admin folder? What the point in going to all that trouble to rename it?

[HostOrca]

Wouldnt it be simplier just to password protect the admin folder? What the point in going to all that trouble to rename it?

 

Makes it more difficult for anyone to guess what the folder is called

[shoggy24]

Is there any chance that renaming the admin folder will be a problem when upgrading is done?

[dsaunier]

Is there any chance that renaming the admin folder will be a problem when upgrading is done?

 

No that name is only a constant added in the config file, so at worst you'll only have to specify it again after you've upgraded.

[pacwebhosting]

Hi,

 

Also don't forget to update your cron job with the new folder name otherwise your daily cron job will not run.

 

Paul

[Brett]

One thing I noticed last night while looking through my database is that my eNom username and password are in plain text. I think that this should be encrypted as well.

[Nick]

One thing I noticed last night while looking through my database is that my eNom username and password are in plain text. I think that this should be encrypted as well.

 

Matt is currently developing me a module for this, as I've suffered because of this before - it'll be part of WHMCS' next release too.

[mikie]

Matt is currently developing me a module for this, as I've suffered because of this before - it'll be part of WHMCS' next release too.

 

Suffered? How?

[zigzam]

I don't think an audit is so much needed with Closed-sourced work; It would be different for Open Source (Such as IPB which has audits).

 

It is important both ways.

[brianoz]

It is important both ways.

An audit is much less important for closed source for the simple reason that the code can't be read and checked for security problems. I don't think you can get any more cut and dried than that. Nobody would say that a security audit would have no value, but I just can't see that it should be a high priority for them with what I know of the product at this stage.

 

This is especially true for WHMCS which has a track record of proving itself to be pretty good in the security arena at this point. If it had a bad track record, then there would be reason to jump up and down. I have a lot of confidence in Matt as a developer, he's intelligent, has good perspective and is capable of making the necessary judgment calls and getting them right. Based on all of this, I think a security audit would be a waste just now (and VERY expensive as has been said above) so I'd be against it for now and think the resources would be better spent elsewhere.

 

Some other random security thoughts:

 

If Matt has written a code injection check into his SQL function calls, as I assume he has, and checked his globals carefully, that's a pretty good start for now.

 

As far as I know user passwords aren't stored in cleartext so that helps deter a little.

 

What the community seems to be finding at this stage, from what I've heard, is that most of the problems people are having are around server security rather than problems within WHMCS. After all WHMCS can't be any more secure than the server it is run on. I think that the greatest benefit would be found through improving server security at this stage. For instance, most people run PHP as a CGI which leaves the server pretty wide open to attack and subsequent database theft. There's an active kernel exploit out too which I bet many server admins don't know about (local user root privilege escalation through "vmsplice" (sp?)).

 

Another point that occurs to me is, if there is a wide spread exploit that emerges in the future they will find our WHMCS sites through using Google to search for signature code. Obviously if we can minimize the signature footprint that may help a little. Perhaps it might be worth researching around this. This is one way wordpress installs are found for attack and spamming, for instance, so it's a real concern.

 

If there ever is an exploit in the wild, WHMCS will no doubt email us pretty quickly and I'd hope they'd also take the opportunity to inform us of mod_security pattern(s) that could be used to immediately block attacks. This would allow us to protect ourselves immediately rather than waiting for an upgrade (although another immediate fix is to provide us with the file that fixed the vulnerability and I'm sure they'd do that too). We already use mod_security patterns that block most SQL code injection attacks and this takes us right back to getting the server secure in the first place. Coupled with a tool like CSF, which blocks attackers at firewall level, you can get to pretty good protection.