[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.
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: |
| 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:
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. |