Customers Failed Logins not Rate limited

[yggdrasil]

Is this just me or there is no brute force or banning, rate limit or whatever you want to call it for failed logins for customers accounts?

 

There is indeed a setting for admin accounts under security that lets you ban an IP for XX minutes once three failed logins are hit. But for customers?

 

 

What is the point of hashing customers passwords in the database if an attacker can try billions of queries against the live database until they find a collision?

 

 

I consider this a security problem, and while you could stop this with other tricks on the server side, this should be built into the application itself, so WHMCS.

[brian!]

there are products in Marketplace that you can buy to stop that from occurring... or you could submit a feature request.

[yggdrasil]

On 9/29/2017 at 9:45 AM, brian! said:

there are products in Marketplace that you can buy to stop that from occurring... or you could submit a feature request.

I disagree. This is bad security design and ask any security researcher or crypto expert and he will tell you the same. If you don't protect the online database from unlimited retries then it can be attacked just like if the attacker has the database on his own (offline) which means with enough computer power he can find a collision and crack simple passwords, even hashed. This should not even be an option to turn off. Having settings to specify number of retries, block time, etc, is ok but turning it off? Never. The brute force protection should be coded into the WHMCS core, otherwise why even hash passwords in the database? This is bad security design and your customer accounts are not protected unless you rate limit failed login attempts. Its quite trivial for people to get massive amount of computer power now with cloud services and in the past if I remember correctly WHMCS didn't even use hashing or it was a weak one. This is a basic security principle which protects almost every online system.

[twhiting9275]

I have to agree here. The products in the marketplace shouldn't be necessary.  This is 2017, not 2001. X  Failed logins should never be allowed, and the user should automatically be banned.

[brian!]

3 hours ago, twhiting9275 said:

I have to agree here. The products in the marketplace shouldn't be necessary.  This is 2017, not 2001. X  Failed logins should never be allowed, and the user should automatically be banned.

and I wouldn't disagree - there are lots of products in Marketplace that should be built in, and users certainly shouldn't need to buy additional security products to secure their installations from basic attacking techniques... but here we are in reality and not fantasyland.

if WHMCS aren't going to do it following feature requests (I haven't looked but assume there must be some), then they're not going to suddenly have an epiphany on this because of a forum post.

[yggdrasil]

22 hours ago, twhiting9275 said:

I have to agree here. The products in the marketplace shouldn't be necessary.  This is 2017, not 2001. X  Failed logins should never be allowed, and the user should automatically be banned.

You mean the IP/attacker right because if you actually ban the user account this means someone malicious could lock customers account on purpose by just trying multiple failed attempts. Account locking should only be enabled if the number of attempts is very high and comes from different IP's but this is even more complicated than what I suggested here. The most basic thing is to have a hold on time, not even banning IP's, or blocking the account. That would be too fancy for WHMCS to develop I guess...

A basic setting is something as simple as Windows has built in, or just every software/service you use that has a login. For example, after 5 failed logins, wait 30 seconds for a new attempt. Actually, even 1 second along will protect the hashed passwords because computers can try passwords by hundreds of thousands per second or more, depending on the computing power you have. Your server would crash first anyway but the point is still here. Even if you put a wait time for 1 second, this means you limit any system to 5 attempts per second, that alone means you would require the time of the universe to crack a password but without any time lock what so ever, hashing is extremely weakened to computing power. If someone steals your database, there is nothing you can do as they can attack it offline and this the reason to have a hard hashing scheme (hard means slow...) but there is no reason why if the database is online should allow automated systems. The main reason online databases are a bit more secure is exactly for this reason but WHMCS lacks this. I agree, this is 2017 and no login system should allow this.

[yggdrasil]

19 hours ago, brian! said:

and I wouldn't disagree - there are lots of products in Marketplace that should be built in, and users certainly shouldn't need to buy additional security products to secure their installations from basic attacking techniques... but here we are in reality and not fantasyland.

if WHMCS aren't going to do it following feature requests (I haven't looked but assume there must be some), then they're not going to suddenly have an epiphany on this because of a forum post.

I understand but this makes a bit uncomfortable. A good developer should always code with security in mind from day one. I'm not a developer, but WHMCS is a software company and so should have something better than amateur would code. I certainly would not make that mistake, and I'm not even good at coding. I can only assume it's because there is old code around that was still not updated so hence why this is not built in.

[twhiting9275]

On 10/3/2017 at 1:17 AM, yggdrasil said:

A good developer should always code with security in mind from day one

Nobody's ever accused WHMCS of being done by 'good developers', just saying. The team is getting better, but this is just one of those things that is inherent in WHMCS.

 

[Vander Host]

 Any updates on rate limit failed client logins?

We're being targeted by "security researchers" and this is one of their concerns.

Any suggestions for plugins from marketplace?

In my opinion it's a bit strange that admin logins are rate limited, but not client logins. Surely this programming code exists and can implemented for the client area?

 

Bug : no rate limit at form login

Description
in login page : https://.../clientarea.php
there is no rate limit for brute force attack on password which allow attacker to do as much he can from requests for guessing the user password.

How to reproduce
1.go to https://.../clientarea.php
2.put any user or password and intercept request with burp suite
3.send the request to intruder and click add in the password form
4.now put list of password can use thousand of password to brute force
5.will notice in all request has the same status there is no rate limit in this form

Solution
add rate limit in this form
********************************************************************************************************

 

[WHMCS John]

Hi there,

We're monitoring demand for this feature here: https://requests.whmcs.com/idea/banning-clients-for-failed-login-attempts-similar-to-the-admin

At present the support for such a feature is muted, so please do add your vote and comment as it's really helpful to help us understand our user's priorities.

[Vander Host]

Hi @WHMCS John

Thanks so much for the reply. I just voted. 

> help us understand our user's priorities.

Of course user priorities is a great way to drive your product forward. But don't you think security priorities should be top of mind too? Would you really want your users to tell you your product lacks fundamental security on the  login screen before implementing such change?

The problem with this hack is any VIP client's system could get brute forced guessed, giving the  hacker a change to further exploit another system. By the time the host figures out something is wrong, huge damage could have occurred. The host might not even ever know how the system was compromised.

What I'd also like to highlight here is some "security researcher" warned us about this problem. So in fact, most likely the weakness is already out in the wild. And now this "security researcher" is asking us for a bribe to make the problem "go away".

My opinion is forget user priorities and bump this up a level to security priorities.

thanks,

 

Eugene - user since 2007.

 

[bear]

21 minutes ago, Vander Host said:

Thanks so much for the reply. I just voted.

I know you're hopeful that will have some result, but like pretty much any other feature request, it will sit there and not happen. Thing to note about that request?
"Amir Zano shared this idea 5 years ago", so no action in all that time.

If it doesn't generate additional income for WHMCS, it's generally very, very back burner.

[Vander Host]

45 minutes ago, bear said:

shared this idea 5 years ago

Yep. Crowd sourcing feature requests are only useful up to a certain point. I'm not sure how WHMCS handles security notifications, but my community at Github likes a personal email to the owner of the solution.

[WHMCS John]

Hi there,

We welcome and reward responsible disclosures from reward security researchers for finding and reporting security vulnerabilities to us.

If you are being contacted by security researches regarding WHMCS, I'd consider directing them to https://www.whmcs.com/security-bounty-program/

[malfunction]

8 hours ago, WHMCS John said:

Hi there,

We're monitoring demand for this feature here: https://requests.whmcs.com/idea/banning-clients-for-failed-login-attempts-similar-to-the-admin

At present the support for such a feature is muted, so please do add your vote and comment as it's really helpful to help us understand our user's priorities.

There's just so much wrong with this official WHMCS response that I don't even know where to begin 😡

[brianoz]

Brute-forcing (retrying usernames and passwords) is a well known strategy for breaking into sites, and given that WHMCS deals with money and could be used to steal money, this should be a TOP priority.   The thing to do here is to get in as the curve starts, rather than adding it late.

Some ideas on how to do parts of this, from someone experienced as a developer and sysadmin:

1. Return a 403 page when they get the password wrong.  Intelligent firewalls such as CSF allow one to set a "403 limit" after which IP addresses generating a lot of 403s get blocked.  This makes it harder for large numbers of retries.
2. Implement (optional) Recaptcha, particularly invisible recaptcha, which only asserts itself when it looks like there's a chance you might be one of the bad guys (asserts meaning, shows a picture puzzle that you have to solve).  This makes it much harder for the bad guys to keep on retrying passwords, as they have to solve the captcha in some way.  (not impossible, but very hard).
3. Continue to encourage people to protect their admin accounts with Basic Auth security (.htaccess/.htpasswd) - maybe even mandate that.  CSF can also pick up Basic security fails and block IPs causing those if they occur a lot.  This is nice because they don't even get near the login page, and IMO is one possible, reasonable solution to the user request above.  I was doing this with WHMCS admin users in 2010 and it's also been listed in WHMCS security recommendations - Basic Auth can be added on the whole admin panel, which gives a whole new level of protection.  In the case of the requestor above, this should satisfy their need for blocking.
4. Implement some form of counting and blocking on  admin login fails  (isn't this done for client logins? I'm rusty and can't remember?).  This isn't completely trivial, and I can understand WHMCS not being too excited re spending development time implementing this.  Off the top of my head, you'd need to implement counting (requires a table) as well as an admin locks table (with usernames/ids, expiry times, and some sense of why they were locked).  You'd also need a way of resetting the locks from another admin account or from shell.

[twhiting9275]

On 5/26/2022 at 6:24 AM, bear said:

If it doesn't generate additional income for WHMCS, it's generally very, very back burner.

Welcome to corporate life. This is very, very true, unfortunately.

Surprised there hasn't actually been an addon built to deal with this already 🤔

If only I wasn't in the middle of about a zillion other projects at the moment.  Good things on the way, Berry good things!!

Edited June 5, 2022 by twhiting9275