Skip to content

Devise-Two-Factor vulnerable to brute force attacks

Moderate severity GitHub Reviewed Published Jan 11, 2024 in devise-two-factor/devise-two-factor • Updated Mar 20, 2024
Withdrawn This advisory was withdrawn on Mar 19, 2024

Package

bundler devise-two-factor (RubyGems)

Affected versions

>= 1.0.0, <= 5.0.0

Patched versions

None

Description

Advisory withdrawn

The backing CVE has been rejected

Devise-Two-Factor does not throttle or otherwise restrict login attempts at the server by default. When combined with the Time-based One Time Password algorithm's (TOTP) inherent entropy limitations, it's possible for an attacker to bypass the 2FA mechanism through brute-force attacks.

Impact

If a user's username and password have already been compromised an attacker would be able to try possible TOTP codes and see if they can hit a lucky collision to log in as that user. The user under attack would not necessarily know that their account has been compromised.

Patches

Devise-Two-Factor has not released any fixes for this vulnerability. This library is open-ended by design and cannot solve this for all applications natively. It's recommended that any application leveraging Devise-Two-Factor implement controls at the application level to mitigate this threat. A non-exhaustive list of possible mitigations can be found below.

Mitigations

  1. Use the lockable strategy from Devise to lock a user after a certain number of failed login attempts. See https://www.rubydoc.info/github/heartcombo/devise/main/Devise/Models/Lockable for more information.
  2. Configure a rate limit for your application, especially on the endpoints used to log in. One such library to accomplish this is rack-attack.
  3. When displaying authentication errors hide whether validating a username/password combination failed or a two-factor code failed behind a more generic error message.

Acknowledgements

Christian Reitter (Radically Open Security) and Chris MacNaughton (Centauri Solutions)

References

Published by the National Vulnerability Database Jan 11, 2024
Published to the GitHub Advisory Database Jan 12, 2024
Reviewed Jan 12, 2024
Withdrawn Mar 19, 2024
Last updated Mar 20, 2024

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

EPSS score

0.043%
(10th percentile)

Weaknesses

CVE ID

CVE-2024-0227

GHSA ID

GHSA-chcr-x7hc-8fp8

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.