AM allows invalid emails during MFA enrol which prevents future logins and presents an attack vector.

[farmborough]

Describe the bug

The AM MFA enrol form for the email factor only provides on input and no secondary confirmation input. This means that it is very easy to input an incorrect email address, the consequence of which is that the user will be presented with the MFA code challenge form every time they subsequently attempt to login. There is also no check on the email value against a user's registered address, which means that a hacker who has acquired a user's username and password can easily bypass the MFA check by simply providing an email that they can access

To Reproduce

Steps to reproduce the behaviour:

1. Create an SMTP resource in a domain
2. Create an email factor in same domain
3. Configure an application to use the email MFA factor (can be optional, just set the skip time to a low value like ten seconds, for convenience).
4. Using cloud app, attempt to login as a user for that application. You should be presented with the MFA email enrol screen.
5. Enter an email that is different to the user's registered address.
6. From now on, every time the user attempts to login, they will be presented with a new challenge page (behind the scenes, AM is sending a fresh code to the previously entered email address).

Expected behaviour

AM shouldn't allow a user to enrol using an unregistered email address.

Current behaviour

Any email address can be entered, even one that the user cannot access. Login is subsequently impossible without an admin removing the factor from the user's profile.

Useful information

• Environment: 3.19.6

[MichaelOeste]

I do not think that only one input for the email address is a problem. I do not think that it is a problem to be able to enter an email address different to the email address saved at the user account.
I think the only problem is that the factor is enrolled just after entering the email address and submitting the form but not after solving the challenge. By solving the challenge users prove that they are able to receive emails at the entered addresses so that should be the moment the factor is enrolled.
Enrolling the factor before the challenge is solved can make it impossible for users to login again.
I also cannot identify the attack vector as once the factor is rolled out an attacker is not able to receive the MFA codes or to enter an email address to receive codes .

[exalate-issue-sync]

This issue has been fixed in versions 3.21.7, 3.20.12, 4.0.2, 4.1.0