2FA Secret recovery and refresh

Hi team

There have been a few issues related to 2FA, where the secret can be retrieved for the 2FA that is already configured. In a practical scenario, this means that the attacker can retrieve the QR code which was used by the victim to set up 2FA. There’s a few distinct cases to consider: a) Attacker can retrieve 2FA secret before login and bypass 2FA -> covered by P3 entry b) Attacker can retrieve 2FA secret after successful login -> i suggest a P4 entry. See reasons below c) 2FA secret is not refreshed after disable/enable of 2FA -> i suggest a P4 entry for the same reasons below.

I think cases b and c should be fixed for various reasons. If an attacker has hijacked a valid session, it means they can recover the 2FA secret and hold on to it without the victims’s notice. And this goes along with c, where if the victim notices this and tries to disable the attacker’s access to their 2FA, it is not possible if the secret is not refreshed after disable/enable or some other means. I recognise that the needed valid session is a high prerequisite, but considering these as won't fix seems to neglect low impact issues.

Let me know what you guys think.

[jquinard]

Other possible options that come to mind for 2FA Secret Cannot be Regenerated.

P4 - Insufficient Security Configurability->Weak 2FA Implementation->2FA Secret Cannot be Rotated P4 - Insufficient Security Configurability->Weak 2FA Implementation->2FA Secret persistent across configuration changes

[plr0man]

We had a chance to circle back to this topic and get some opinions from the broader team. While chaining vulnerabilities is a topic separate from the VRT severity rating baselines, the majority of the team agrees that the concept of 2FA alone requires a higher level of protections regardless of account takeover being a prerequisite. We decided to address issues described here as P4.

Thank you everyone for your feedback! Next step is to work on the actual classification.