BMCWeb: rate-limit authentication failures

[James Feist]

On 2/4/2020 2:41 PM, Joseph Reynolds wrote:
> I would like to enhance BMCWeb to rate-limit password-based 
> authentication attempts (footnote1) to address [CWE-307][].  [Broken 
> Authentication][] is an OWASP top 10 item.  The goal is to protect 
> against CWE-307 without causing denial of service.  Specifically, when 
> excessive authentication attempts are happening, legitimate users should 
> be able to access the BMC (specifically an admin can login), and 
> degraded BMC performance is acceptable.
> 
> The main idea for the design is to allow authentication at full speed, 
> and rate-limit only when needed.   This is consistent with the approach 
> OWASP outlines.
> 
> Perhaps the design can be as simple as recording the 10 most recent 
> authentication failures (steady_clock time only, having them time out 
> after a minute) to define "excessive", and using the timestamp of the 
> most recent failure to determine when the next attempt will be allowed. 
> When authentication is requested but not allowed, return HTTP status 
> code 429 (Too Many Requests) with HTTP response header "Retry-After: 
> 3".  ==> This will slow down attackers (for example, to 30 tries per 
> minute, even when multiple connections are used) and allow legitimate 
> users to compete for authentication attempts.
> 
> However, I think even this apparently simple design might be tricky to 
> get right.  Is there an open source solution we can use?  What do you 
> think?  Let me know if this is important to you.  I would like to hear 
> ideas how to proceed.

I know we plan to look into this in the near future.

> 
> - Joseph
> 
> <snip/>TL;DR (too long; don't read):
> 
> A counterpart to this design is to delay any failed authentication 
> attempt for a few seconds.  This is intended to slow down malfunctioning 
> network agents that repeatedly fail to authenticate to the BMC.  This 
> won't slow down attackers who can use multiple connections to the BMC.
> 
> I looked at using Linux-PAM.  For example, [OpenBMC uses pam_tally2][] 

Did you look into Pam_abl? Haven't looked much into it, but reading a 
couple articles it looks promising. Using lockouts based on host instead 
of account seems like it would be a good approach.

> but does not configure account lockouts.  I don't want to pursue using 
> the pam_tally2 lockout mechanism because that can lead to denial of 
> service.  I believe rate-limiting is a better approach.
> 
> I only want to protect access via BMCWeb.  The protection techniques may 
> also apply to network IPMI and SSH, but the direction is to disable 
> these accesses, so I am less interested.  Access via the BMC's serial 
> console would not be protected.  Access via the BMC's host should have 
> similar protections, but I am not investigating that now.
> 
> CWE-307 is a problem only because OpenBMC offers password-based 
> authentication without requiring multi-factor authentication (MFA). 
> Disabling password-based auth remains a popular use case, and OpenBMC 
> has no MFA capabilities.  So I need CWE-307 protection as a stop-gap 
> solution.
> 
> References and footnotes:
> [CWE-307]: https://cwe.mitre.org/data/definitions/307.html
> [OpenBMC uses pam_tally2]: 
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth 
> 
> (footnote1): BMCWeb's password-based authentication includes Basic Auth, 
> login via /login, and creating a Redfish session.  It does not include 
> authentication via mTLS or using an X-Auth-Token or a cookie from an 
> established session.
> [Broken Authentication]: 
> https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication 
>