[SUP-81] Vulnerability to denial of service attack Created: 06/Sep/22  Updated: 27/Oct/22

Status: Open
Project: Support
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P3
Reporter: Molly Driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: security, security-reviewed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint:
Development Team: Core: Platform
RCA Group: TBD

 Description   

Overview: A library raised the following issue after having several users rendered inactive due to invalid credential attempts. Please note that identifying information has been anonymized for this ticket submission:

A system which has a publicly accessible log-in page and permanently locks an account after failed authentication attempts is vulnerable to a denial-of-service attack, which is aggravated if that system doesn't have source-based rate-limiting. To estimate our vulnerability, I created and set passwords for 10,000 test accounts in [a] test FOLIO instance.[2] Then I hastily put together and executed a command to lock those accounts:[3] It locked all 10,000 in less than twenty minutes.

 

  1. Our production FOLIO instance has [tens of thousands of] active accounts.

 

  1. To approximate the abilities of a mischievous freshman, I gave

     myself ten minutes to come up with this: I used my browser's

     debugger to capture the form submission at the log-in page as a

     Curl command and saved that as a script with the username

     parameterized such that:

 

       ./fail-login [username]

 

     would make one failed attempt to log in to my account. I then

     executed:

 

       cat users users users users users |

           xargs parallel-moreutils -j 100 \

               "./fail-login.sh" –

 

     Our hypothetical freshman wouldn't have trouble getting a nearly

     complete list of real usernames to use, since anyone on [the university's]

     network can retrieve a list of campus usernames from [the university's]

     directory server or several other sources.

 



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 06/Sep/22 ]

Jakub Skoczen Which dev team do you think this should be assigned to?

Comment by Ann-Marie Breaux (Inactive) [ 07/Sep/22 ]

Craig McNally What do you think in terms of Dev Team and priority? Thank you!

Comment by Ann-Marie Breaux (Inactive) [ 13/Oct/22 ]

Hi Jakub Skoczen and Craig McNally This bug has been sitting for a month - not assigned to a dev team or a particular project. Should it maybe be mod-users? As long as it's not assigned to a dev team, it's likely not being tracked or reviewed by a PO.

Comment by Craig McNally [ 13/Oct/22 ]

Thanks for bringing this to our attention Ann-Marie Breaux.  I'm going to add the 'security' tag so it's on the security team's radar.

Comment by Julian Ladisch [ 20/Oct/22 ]

Institutions that use SAML Single-Sign-On are not affected. Please put only affected institutions into the "Affected institutions" field.

Comment by Axel Dörrer [ 20/Oct/22 ]

The security group has reviewed this and this is the usaual way of logins to prevent brute force attacks. Usually usernames are not broadly known.

A way could be to limit access at sysops level to prevent one IP to flood the login with requests. We might provide some more input soon.

Comment by Julian Ladisch [ 21/Oct/22 ]

Relevant OWASP information:

Comment by Julian Ladisch [ 21/Oct/22 ]

The POST /authn/login is the back-end API involved:
https://s3.amazonaws.com/foliodocs/api/mod-login/r/login.html
https://github.com/folio-org/mod-login#module-properties-to-set-up-at-mod-configuration

Comment by Ann-Marie Breaux (Inactive) [ 21/Oct/22 ]

Is any team taking ownership of this Jira, at least for their backlog? If not, I can put "Other dev" on it, and it can just disappear into the Jira void.

Comment by Molly Driscoll [ 21/Oct/22 ]

Thank you for the additional information Julian Ladisch . The reason that I added ALL to the affected institutions is because even those using SAML SSO still have a username and password authentication option present on their login screens. So, if a username is known (or guessed) this could still be used as a method for malicious lockout. In fact, it was an institution with SSO login configured that initially reported the issue. As I understand, even if this was not present on the login UI, this type of attack could still be initiated directly to mod-login. I will certainly read through the resources that you posted and reach out with any further questions! Have a nice weekend!

Comment by Craig McNally [ 25/Oct/22 ]

Ann-Marie Breaux The security team will discuss this week and take some (TBD) action....  e.g. find/assign an appropriate team, close as "won't do", etc. 

Comment by Craig McNally [ 27/Oct/22 ]

The security team discussed this and have a few ideas that may be worth exploring:

  1. Send a notification to the user upon lockout, with a link that unlock the account.
    1. This will likely have dependency implications... mod-login depending on mod-email, etc.
  2. Only lock the user out for a configurable amount of time, then automatically unlock their account.
    1. This defeats the possibility of brute force attacks.

NOTE:  While stripes call mod-users-bl's login endpoint, the fix needs to happen in mod-login since the attacker can hit the mod-login APIs directly.

Generated at Thu Feb 08 22:22:45 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.