Security Feature Bypass In Zitadel – Race Condition

Jack Moran discovered a security feature bypass via a race condition within the Zitadel “password lockout policy” feature.

Published on 13th November 2023

Introduction

In his own time, Jack Moran, with the aid of Ethan McKee-Harris, discovered a security feature bypass of the Zitadel “password lockout policy” feature. This feature was found to be susceptible to a race condition which, when exploited, could allow for many brute-force login attempts to be processed successfully before triggering the password lockout policy. This issue has been classified as a 7.3 (High) and recorded with the following identifier: CVE-2023-47111.

Throughout the disclosure process, Zitadel have been proactive in their engagement with ZX Security, resulting in a patched version of the platform being released in under a week. This was due to clear and responsive communication, allowing for quick triaging and remediation of the vulnerability.

What is Zitadel?

Zitadel is a unified identity infrastructure built as an open-source project that helps engineers focus their time on business features. Zitadel supports B2B, B2C and M2M settings while it provides crucial turnkey features like a hosted login, passwordless and multifactor authentication, authorization, single sign-on, OpenID Connect, SAML, extensibility with code (actions), APIs for everything and much more.

Vulnerability Discovery

After Ethan Mckee-Harris discovered CVE-2023-46238 (which you can read about here) during his testing of a Zitadel deployment, Jack Moran undertook additional research of the Zitadel platform in preparation for his talk at CHCon 2023.

This research revealed that the Zitadel platform provides a “password lockout policy” feature, that can be configured to lock out users in the event that too many failed authentication attempts are made. However, this feature appeared to be subject to a race condition similar to one Jack previously discovered in Microsoft’s ASP.NET SignInManager (read more here). By sending requests concurrently to the sign-in function located at /ui/login/password it resulted in a large number of these requests being processed before the configured password lockout policy being triggered.

Testing revealed that the race condition could be exploited without any need for a last-byte-sync attack or single-packet attack, and could be exploited just by sending crafted requests concurrently and as fast as possible, making this race condition trivial to exploit. Off-the-shelf tools such as Burp Suite’s intruder, and Turbo Intruder could also be used to execute this attack.

A proof of concept (PoC) was developed to exploit this issue in addition to using the aforementioned tooling in order to initially isolate it.