Investigate if CVE-2024-0227 is relevant

[ros-cr]

I'm a pentester from Radically Open Security.
We recently reported a 2FA bypass vulnerability in the devise-two-factor library, see the GHSA-chcr-x7hc-8fp8 advisory and my writeup.

Since Bullet Train uses the devise-two-factor library for 2FA authentication, we recommend looking into this as a potential security problem you could be affected by. Please note that we have not further analyzed your project code.

Relevant gem definition:

bullet_train/Gemfile

Line 140 in cd59fff

gem "devise-two-factor"

[jagthedrummer]

Thanks for the heads up, @ros-cr!

[KonnorRogers]

@ros-cr for next time, security advisories should generally be handled following the "Security" tab.

https://github.com/bullet-train-co/bullet_train/security

Opening public issues for possible security issues is generally not a good idea unless you've followed the appropriate steps of attempting to notify privately and have waited generally, 90 days for a response.

[ros-cr]

@KonnorRogers

We did follow coordinated security guidelines to report the 2FA bypass vulnerability to the devise-two-factor library, and suggested to the library vendor to include or notify some affected downstream projects in the coordinated disclosure. However, they decided against this, which is somewhat understandable given the relevant expected complications.

I think you can see how the burden of reliably assessing and confidentially reporting library vulnerability related impact to many potentially affected dependent projects quickly becomes unmanageable. Similarly, I think you'll agree that once a security issue in a code dependency of an open source project has been published, it makes a lot less sense to handle it at the same confidentiality level as the original disclosure.

#1285 is a post-disclosure courtesy for your project. We noticed your dependency on devise-two-factor (via) but did not have time for more specific analysis, so this is meant as a heads-up along the lines of what Dependabot would give if there was a patched version.

An additional note: for future issues, please provide an official email security contact option, instead of exclusively requiring the use of third party services like Twitter or Discord to reach the project confidentially.

[KonnorRogers]

@ros-cr makes sense that it's essentially like a dependabot notification 👍

[jagthedrummer]

Thanks again for the heads up on this @ros-cr. I just spent some time looking into it and testing it and I think we're not affected due to already having mitigation steps in place.

According to the docs for devise-two-factor one possible mitigation it to use the lockable strategy for Devise. https://github.com/devise-two-factor/devise-two-factor?tab=readme-ov-file#preventing-brute-force-attacks

We enable that feature by default here: https://github.com/bullet-train-co/bullet_train-core/blob/637829b74de8ab9ab83771d5235c9e18c316ac41/bullet_train/app/models/concerns/users/base.rb#L21

And the maximum_attempts value is configured here:

bullet_train/config/initializers/devise.rb

Lines 205 to 207 in a1cf710

	# Number of authentication tries before locking an account if lock_strategy
	# is failed attempts.
	config.maximum_attempts = 20

I just did some testing and I can confirm that after repeated attempts to sign in with a correct email & password but with an incorrect 2FA code that the account is indeed locked (and an email is sent to the user in question).

I don't think there's anything we need to do here, so I'm going to close this issue. If anybody thinks this evaluation is incorrect or has other concerns feel free to either reopen this issue, or create a new one, whichever seems best.

[ros-cr]

@jagthedrummer thanks for the heads up.

I agree that by using lockable, Bullet Train makes it a lot harder for attackers to bypass the TOTP 2FA on a given account. This matches with your experimental testing results. The probability is still non-negligible, but that's likely the best you can do in terms of hard rate limiting. maximum_attempts = 2 or maximum_attempts = 200 would probably both be worse settings 😉

When I looked into lockable back in 2023, I had the understanding that it also locks user accounts after login attempts with a given email address but incorrect password (+ incorrect 2FA), at least in some flows. For that reason, I saw it as a mitigations strategy which brought new problems, namely Denial-of-Service and spamming risks against existing users. In that scenario, an attacker would not actually try to get into the account, but try to annoy a given victim instead by triggering emails for the lockable unlock action and force them to use it. Have you checked if that scenario is possible with your software?

[jagthedrummer]

@ros-cr I haven't tested that specific scenario but your description matches my understanding and expectations of how that sequence of events would play out.

[ros-cr]

@jagthedrummer if the lockable behavior is as expected, personally I would see this as a problematic trade-off, which makes it easier to disrupt access for a given user, or at least annoy them. If built differently, the auth system wouldn't have to lock out users based on incorrect password attempts, and could instead just offer lockouts on incorrect TOTP attempts after correct passwords are provided. From what I'm aware, there is also nothing an impacted user can do to prevent recurring attacks in this scenario, as lockable and its configuration is a site-wide or application-wide global setting.

Given the design decisions of the relevant library authors, including the decision of the devise-two-factor maintainers to not introduce any brute force protection on their library layer, I'm not aware of any straightforward off-the-shelf solutions here that avoid the above mentioned risks introduced by lockable.

From the perspective of this ticket - "Investigate if CVE-2024-0227 is relevant" the issue is still resolved, so we can leave it at this, but I wanted to raise the not-immediately-obvious negative side effects of lockable.

If you do find an alternative solution, feel free to let me know so I can revisit my advisory recommendations on the general issue. 🙂