bugcrowd / vulnerability-rating-taxonomy

Bugcrowd’s baseline priority ratings for common security vulnerabilities
https://bugcrowd.com/vrt
Apache License 2.0
438 stars 83 forks source link

2FA invalidation cases #289

Closed shpendk closed 4 years ago

shpendk commented 4 years ago

As discussed last week, we've seen some of the following issues being reported:

  1. Using sms, requesting multiple 2FA codes (without using them) results in the same code being sent
  2. Using sms, requesting multiple 2FA codes does not invalidate previously received code.

Imho we should P5 both of these variants. So long as rate limit is present on the 2FA verification endpoint, this shouldn't be an issue. Open to discussion.

plr0man commented 4 years ago

As far as number 1. goes this sounds like a P5. The real problem would be if the code was valid for too long or if you could issue thousands of varying valid codes and limit the bruteforce space. In that case we would be facing a bypass which would need to be demostrated and addressed by the existing P3 – Broken Authentication and Session Management > Second Factor Authentication (2FA) Bypass

With that said a potential entry for case 1. could look like: P5 – Insufficient Security Configurability > Weak 2FA Implementation > 2FA Code is Not Rotated After New Code is Requested

As far as case 2. goes that sounds like it has some potential, but given a short expiry time or other limitations this might not be exploitable. We'd be looking at a potential of P5-P4. Otherwise the existing P3 could apply given a bypass. P5 – Insufficient Security Configurability > Weak 2FA Implementation > 2FA Code is Not Invalidated After New Code is Requested

shpendk commented 4 years ago

After some discussion on our end, we have proposed to add the following entry:

P5 – Insufficient Security Configurability > Weak 2FA Implementation > 2FA Code is Not Invalidated After New Code is Requested
plr0man commented 4 years ago

Looking at the proposed entries after a few weeks, I see that they may look too similar and there's need for more clarity. Here are the entries that would be final unless there's any objections: P5 – Insufficient Security Configurability > Weak 2FA Implementation > 2FA Code is Not Updated After New Code is Requested P5 – Insufficient Security Configurability > Weak 2FA Implementation > Old 2FA Code is Not Invalidated After New Code is Generated

m-q-t commented 4 years ago

Hi team,

Regarding the issue's priority, I completely agree that P5 Informational is the appropriate priority as this could be considered best practice. As mentioned earlier by @plr0man, this would only present itself as an issue if the application is missing rate limiting when verifying the OTP.

Splitting up the proposed entry into two entries is something I am in favor of as well. I've seen both issues come up quite frequently and this being exploited in the wild is very unlikely to happen as the attacker would need access by other means to where the OTP is received in order to intercept it.

Best regards, Maxim