Impact
This occurs when an attacker is logging in using "Log in with Microsoft". The application checks if the user has an existing account based on the email address provided by the Identity Provider (Azure AD) and merges the two accounts. Usually, this ensures the user identity is unified and they retain control over their account. However, in the case of OAuth, as the email address is not trusted or verified, merging user accounts results in a full account takeover by an attacker.
This OAuth misconfiguration can be used to take over accounts, without any user interaction. All an attacker needs is the victim's email address and this would lead to a zero-click account takeover.
Steps to reproduce:
Modify email attributes under "Contact Information" in an Azure Active Directory to the victim's email address from the Attacker's Azure AD account: victim123@gmail.com is the victim's email in our case.
"Login with Microsoft" using the attacker's Azure AD account and you will see the victim's email address on screen (i.e victim123@gmail.com). This means that the "email" attribute is being accepted by the web app, leading to an account takeover.
Mitigation:
Recheck if the email ID is the same as the Azure account owners. Do NOT rely on the email attribute. The User Principal Name should be used instead, or use the "sub" (Subject) claim as the unique identifier for the user and not the "upc", "email", "preferred_username" and other claims for authentication or authorization.
Zero-click account takeover
Impact This occurs when an attacker is logging in using "Log in with Microsoft". The application checks if the user has an existing account based on the email address provided by the Identity Provider (Azure AD) and merges the two accounts. Usually, this ensures the user identity is unified and they retain control over their account. However, in the case of OAuth, as the email address is not trusted or verified, merging user accounts results in a full account takeover by an attacker.
This OAuth misconfiguration can be used to take over accounts, without any user interaction. All an attacker needs is the victim's email address and this would lead to a zero-click account takeover.
Steps to reproduce:
Modify email attributes under "Contact Information" in an Azure Active Directory to the victim's email address from the Attacker's Azure AD account: victim123@gmail.com is the victim's email in our case.
"Login with Microsoft" using the attacker's Azure AD account and you will see the victim's email address on screen (i.e victim123@gmail.com). This means that the "email" attribute is being accepted by the web app, leading to an account takeover.
Mitigation: Recheck if the email ID is the same as the Azure account owners. Do NOT rely on the email attribute. The User Principal Name should be used instead, or use the "sub" (Subject) claim as the unique identifier for the user and not the "upc", "email", "preferred_username" and other claims for authentication or authorization.