SSO Gone Wrong: Insights from a Real Breach

In one of my past projects, we experienced a critical security breach when a white-hat security researcher reported a vulnerability that allowed unauthorized access to one of our root system admin accounts. This superuser account was designed to facilitate support operations, granting access to other accounts for internal use only. While the situation could have been catastrophic, we were fortunate for two key reasons:

1. The Researcher’s Intentions Were Ethical: The security researcher acted with goodwill and a bounty incentive. They demonstrated that they could log in without exploiting the access to harm or compromise client data. Notably, the researcher did not realize that the compromised superuser account could access other user accounts, limiting potential damage.

2. Limited Exposure to the Vulnerability: The vulnerability, known as "nOAuth," was rooted in Microsoft Azure Active Directory’s Single Sign-On (SSO) feature. This feature had been deployed in our application only 2-3 days prior to the breach. Once notified, we acted quickly, disabling the Microsoft Azure AD SSO login feature to close the vulnerability until a proper fix could be implemented.

---

Understanding the "nOAuth" Vulnerability

The "nOAuth" vulnerability was a critical flaw in Microsoft Azure Active Directory (Azure AD) applications utilizing the "Log in with Microsoft" feature. This security gap allowed attackers to impersonate users by modifying the email attribute in their Azure AD profile to match the target victim’s email. If an application relied solely on the email claim for user identification, it could inadvertently grant unauthorized access to attackers.

Attack Flow:

1. Preparation: With administrative privileges in their Azure AD account, the attacker altered their "Email" attribute to mimic the target victim’s email address.
2. Exploitation: Using the "Log in with Microsoft" feature on a vulnerable application, the attacker could successfully log in. The application identified users based solely on the email claim without additional verification.

Why It Happened:

The vulnerability exploited a design flaw in applications that depended on mutable and unverified claims, such as the email attribute, for user identification or authorization.

We aimed to give existing users the option to log in with different authentication methods to the same account. For example, a user signing up with a Google account could access their account using another method, provided the same email address was used. However, prioritizing the user email address received in the OAuth2 callback to identify user identity exposed our application to this vulnerability.

---

Mitigation

Immediate Actions Taken:

Once the vulnerability was reported, we acted according to a pre-determined protocol designed to handle severe security risks:

• Disabled the Microsoft Azure AD SSO feature, effectively eliminating the risk.
• Informed all client-facing representatives and company executives about the incident.
• Held an all-hands meeting with the development team to decide on a course of action.
• Analyzed login data to gauge the severity and scope of the incident.
• Sent targeted notifications to users affected by the Microsoft SSO feature, offering guidance and points of contact for support.

---

Lessons Learned

To prevent similar vulnerabilities, applications must implement robust security practices and use Immutable Identifiers Instead of relying on mutable claims like the email attribute, use immutable identifiers such as the sub and iss ID Token claims to uniquely identify users and their identity providers.

Example Code:

// Extracting immutable 'sub' claim for user identification  
const jwt = require('jsonwebtoken');

function verifyToken(token) {  
   const decoded = jwt.decode(token, { complete: true });  
   const userId = decoded.payload.sub; // Immutable user identifier

   if (!userId) {  
       throw new Error('Invalid token: Missing subject claim');  
   }

   return userId;  
}

---

Product Options

When a user logs in with different methods, there are several ways a product can address associated security and usability challenges:

1. Restrict Cross-Provider Logins: Require users to be uniquely identified by an immutable identifier, such as the oid, ensuring email addresses do not overlap or lead to account hijacking.

2. Separate Accounts per Provider: Create distinct accounts for each authentication provider. This ties accounts to their unique identifiers (oid) rather than emails, avoiding issues with email duplication.

3. Account Merging Based on Email: Automatically merge user accounts across SSO providers if they share the same email address. However, relying solely on email for identification is insufficient; additional verification methods are necessary during the merge process to mitigate risks.

Key Security Enhancements:

• User Notifications: Notify users whenever a new login method or additional SSO provider is linked to their account. Real-time alerts enable prompt responses to unauthorized changes.

• Multi-Factor Authentication (MFA): Require multiple verification steps, such as email confirmations, SMS codes, or app-based authenticators. MFA is particularly crucial when merging accounts or adding new authentication methods.

• Monitoring and Auditing: Continuously monitor login flows to detect anomalies. Regularly audit authentication logs to ensure adherence to security protocols and identify potential vulnerabilities. These logs are invaluable for analyzing the impact of security incidents and improving future response strategies.

---

Conclusion

The "nOAuth" vulnerability underscored the importance of robust security measures and proactive responses to emerging threats. Team education and pre-established security protocols played a pivotal role in our ability to respond effectively. Combining multiple measures—such as immutable identifiers, enhanced user verification, and continuous monitoring—proved essential in mitigating risks. Additionally, it is critical to approach third-party information and integrations with a grain of salt, as these can introduce unforeseen vulnerabilities. By maintaining vigilance, investing in ongoing education, and adapting to the evolving threat landscape, organizations can secure their systems and safeguard user data effectively.