CVE-2024-21632: 
Ruby vulnerability analysis and mitigation

The vulnerability (CVE-2024-21632) affects omniauth-microsoft_graph versions prior to 2.0.0. The implementation did not validate the legitimacy of the email attribute of the user nor did it give/document an option to do so, making it susceptible to nOAuth misconfiguration in cases when the email is used as a trusted user identifier. This could lead to account takeover. The vulnerability was discovered and disclosed in January 2024 (GitHub Advisory).

The vulnerability stems from using the email claim as a user identifier without proper validation. In Microsoft Azure AD, the email claim is both mutable and unverified, allowing attackers to change the Email attribute under 'Contact Information' in their Azure AD account to control the 'email' claim in the returned identity JWT. According to the OAuth specification, the user should be uniquely identified by the 'sub' (subject) claim rather than the email claim. The vulnerability has a CVSS v3.1 base score of 8.6 (High) with vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L (GitHub Advisory, Descope Blog).

The vulnerability could lead to full account takeover. An attacker can create their own Azure AD tenant and use 'Log in with Microsoft' with a vulnerable app and a specially crafted 'victim' user. If the app merges user accounts without validation based on the email claim, the attacker gains complete control over the victim's account, even if the victim doesn't have a Microsoft account (Descope Blog).

The vulnerability has been fixed in version 2.0.0 of omniauth-microsoft_graph. For remediation, developers should use the 'sub' (Subject) claim as the unique identifier for users instead of the email claim. Microsoft has introduced two new claims to help prevent nOAuth: 'xms_edov' to indicate whether an email claim contains a domain-verified email address, and 'RemoveUnverifiedEmailClaim' to redact email claims when the domain is unverified. If merging user accounts is necessary, the email address provided by Microsoft should be validated with a magic link or similar secure means (GitHub Advisory, Descope Blog).

The vulnerability was discovered by the Descope security team, who worked with Microsoft to address the issue. Microsoft has since refactored their documentation to provide stronger guidance and dedicated sections on claim verification. Several large applications were found vulnerable, including a design app with millions of monthly users, a publicly traded customer experience company, and a leading multi-cloud consulting provider (Descope Blog).