Vulnerability Discovery
CVE-2023-33170 Attribution
Microsoft Security Response Center (MSRC) acknowledged this vulnerability, as documented in their official records.
What Happened?
The issue was traced back to ASP.NET’s SignInManager, a function that manages user login using asynchronous operations. In scenarios where multiple threads access or alter a shared resource such as a database, race conditions can occur. These conditions arise when two or more processes simultaneously modify data, leading to inconsistent outcomes.
In this case, database logs revealed errors such as DbUpdateConcurrencyException, which indicated that updates expected to affect one row were in fact affecting none. This suggests that another concurrent process had already modified or deleted the data.
This pattern revealed that multiple login attempts were being processed in parallel. Because of this, the database could not enforce lockout policies consistently. The race condition enabled brute-force login attempts to continue without triggering the account lockout threshold as expected.
Proof of Concept
Security researcher Jack Moran developed a proof-of-concept (PoC) that confirmed the vulnerability. The test environment simulated thousands of concurrent login requests, mixing incorrect credentials with one valid login. Due to the race condition, the system failed to enforce proper lockouts.
The PoC classified login outcomes into three categories:
- Fail: Invalid login attempt returned a standard error response.
- Lockout: Reached the configured lockout policy, redirecting the user to a lockout page.
- Success: A valid login succeeded and redirected to the homepage.
This simulation showed that successful logins could still occur despite reaching the lockout threshold, confirming that the system was vulnerable to race-condition-based brute-force attacks.
Testing Environment Setup
To ensure the issue was not specific to a particular project, Ethan McKee-Harris created a fresh test environment using Microsoft’s official instructions for building a web app with user authentication.
Steps taken included:
- Creating a new web application with individual account authentication.
- Installing the necessary identity scaffolding and database packages.
- Enabling the lockoutOnFailure option in the login method.
- Configuring the app to enforce account lockout policies.
These steps validated that the vulnerability was reproducible in a standard environment and not tied to a unique setup.
