Password MisManagers: Hunting for Authentication Bypasses in Enterprise Password Managers

Password MisManagers: Hunting for Authentication Bypasses in Enterprise Password Managers

Speakers: Aidan, Offensive Security Practitioner, Division 5

Conference: BSides Canberra

YouTube: https://www.youtube.com/watch?v=nViIsWR7_eg

Overview

In this compelling talk at BSides Canberra, Aidan, an Offensive Security Practitioner at Division 5, delves into the critical security vulnerabilities he uncovered in three popular self-hosted enterprise password managers: Click Studios Passwordstate, Team Password Manager, and Delinea Secret Server. Titled "Password MisManagers," the presentation highlights how these seemingly secure solutions, often deployed as the crown jewels of an organization's internal network, can be compromised through sophisticated yet often simple authentication bypasses and other critical flaws. Aidan's research underscores the inherent risks in these systems, particularly when they are dual-homed on internal and external networks, making them prime targets for threat actors seeking to escalate privileges and gain full control over an enterprise's digital assets.

The talk provides a deep technical dive into the methodologies used to identify and exploit these vulnerabilities, including the challenging process of deobfuscating commercial code packers like Agile.NET and SourceGuardian. Aidan demonstrates how, once the underlying code is made auditable, high-impact bugs — such as XML signature wrapping and padding oracles — can quickly emerge. The findings presented are not merely theoretical; they are based on real-world internal security assessments where Aidan observed these products in use, emphasizing the practical relevance and severe implications for defenders. The research serves as a stark reminder that even products designed for security can harbor critical flaws, requiring constant scrutiny and robust defensive strategies.

Aidan’s motivation for this research stems from his extensive experience in internal penetration testing, where compromising Active Directory often leads to the next logical step: targeting the organization's password manager. These systems, often doubling as Privileged Access Management (PAM) solutions, store keys to the kingdom—credentials for backups, cloud environments, virtualization infrastructure, finance systems, and other identity stores. A successful compromise of a password manager can lead to Remote Code Execution (RCE) on critical servers and the exfiltration of all sensitive secrets, making them an irresistible target for ransomware operators and other advanced threat actors.

Background

▶ Watch: Introduction: Why attack enterprise password managers? (0:00)

Aidan's journey into auditing enterprise password managers began with a common scenario in internal security assessments: achieving Domain Administrator (DA) privileges within an organization's Active Directory (AD) environment. From this vantage point, the most efficient path to further compromise is often to locate and exploit the central repository of secrets – the password manager. These systems are invaluable targets because they centralize access to credentials for virtually all critical infrastructure, including cloud platforms, virtualization, networking, and financial systems. Furthermore, many enterprise password managers also function as Privileged Access Management (PAM) solutions, offering functionalities like script execution or remote access, which can be leveraged for RCE on multiple servers if the PAM system itself is compromised.

While some organizations opt for client-side solutions like KeePass or cloud-based SaaS offerings such as LastPass or 1Password, Aidan's focus was on self-hosted password managers. These solutions, running on servers controlled by the organization (either on-premises or in a private cloud), present a unique attack surface. The typical attack chain, post-DA compromise, involves gaining local administrator access on the domain-joined password manager server. From there, an attacker can read application configuration files to extract database connection strings and secrets, dump the database, and then decrypt the stored data. This final decryption step often relies on prior research into the specific product's cryptographic implementation, as the server must be able to decrypt the data, implying an attacker can, in theory, replicate this process.

Aidan's initial deep dive was prompted by an encounter with Passwordstate during an assessment. Previous research by Northwave and ModZero had detailed its decryption process, but Aidan found their tools no longer worked due to vendor changes. Passwordstate, being a .NET application, should have been amenable to reverse engineering, but it was protected by Agile.NET, a commercial obfuscator. This tool renames symbols, encrypts strings, messes with control flow graphs, and hides active code, significantly complicating analysis. To overcome this, Aidan leveraged an Italian CERT write-up on deobfuscating Agile.NET-protected malware. He made modifications to an open-source decompiler, de4dot, specifically targeting method decryption, string decryption, and proxy delegate fixes to restore readability. This process transformed "garbage bytes" back into legible source code, enabling him to identify the changes in Passwordstate's decryption process, update existing tools, and successfully retrieve plaintext passwords. Interestingly, he later discovered that the Set P 0 ransomware group had already "forcefully open-sourced" the new decryption process and some deobfuscated code.

Having successfully deobfuscated Passwordstate and gained auditable source code, Aidan decided to look for other vulnerabilities, particularly pre-authentication bugs with high impact like RCE, file read/write, or authentication bypasses. This proactive approach, driven by the necessity of his penetration testing work and the unexpected ease of deobfuscation, laid the groundwork for the subsequent discovery of critical flaws across multiple password manager products.

Key Findings

▶ Watch: Passwordstate Emergency Access Authentication Bypass (CVE-2022-3113) (8:40)

Aidan's research yielded significant findings across three enterprise password managers, demonstrating that even security-focused products can harbor critical vulnerabilities, often hidden by obfuscation or overlooked design flaws.

1. Passwordstate - Emergency Access Authentication Bypass (CVE-2022-XXXX, severity dispute): This vulnerability allowed an unauthenticated attacker with network access to a Passwordstate instance to gain administrative privileges and dump all stored credentials, potentially leading to RCE. The flaw exploited a logical error in the application's authentication check combined with a path info parsing quirk in .NET. Despite the vendor (Click Studios) rating it as a 10/10 internally, MITRE initially assigned a low severity score of 3.1, highlighting a disconnect in vulnerability assessment. Click Studios' rapid and responsible disclosure handling was highly commended.

1. Team Password Manager - Password Reset Authentication Bypass (CVE-XXXX-XXXX): Found in a PHP-based product protected by SourceGuardian obfuscation, this bug allowed an attacker to reset any user's password without prior authentication or knowledge of the old password. The vulnerability stemmed from an insecure password reset flow that bypassed initial stages, combined with a critical function that unconditionally returned true for an integrity check. Attackers could enumerate user IDs and emails, making the exploit highly effective. The vendor addressed this quickly and responsibly.

1. Delinea Secret Server - SAML Authentication Bypass (XML Signature Wrapping): This flaw in Secret Server's SAML functionality permitted an attacker to authenticate as any user, including an administrator, by manipulating the SAML response. It leveraged an XML Signature Wrapping technique, where an injected unsigned assertion for a target username was processed before legitimate signed assertions, due to the application's ordered parsing logic. This attack only required a valid SAML response from any user and worked even if assertions were signed, as long as the overall SAML response itself was not signed (a common default configuration).

1. Delinea Secret Server - Padding Oracle Vulnerability: A "bonus bug" found in Secret Server's virtual keyboard image generation feature. This allowed an attacker to perform arbitrary encryption and decryption using the application's master encryption key. While directly forging high-impact authentication cookies proved challenging, Aidan demonstrated its utility in decrypting database backups, potentially escalating privileges from a low-privilege user with access to old backups.

Collectively, these findings underscore that obfuscation, while a deterrent, is not a security panacea. In both Passwordstate and Team Password Manager, once the obfuscation was defeated, the critical vulnerabilities "fell out within less than a day of code review," suggesting that the obfuscation itself might have prevented earlier discovery by other researchers. The research emphasizes the need for thorough security auditing, even for products designed to secure sensitive data, and highlights the potential for simple logical flaws to have devastating consequences.

Technical Deep Dive

▶ Watch: Defeating SourceGuardian and Team Password Manager Auth Bypass (20:40)

Aidan’s talk offered a detailed look into the mechanics of each vulnerability, providing insights into both the attack vectors and the underlying code flaws.

Passwordstate: Emergency Access Authentication Bypass

The vulnerability (CVE-2022-XXXX) in Passwordstate's emergency access feature exploited a combination of session management quirks and .NET path parsing. The emergency access page (e.g., /EmergencyAccess.aspx) is designed as a "break glass" account, not requiring a licensed user. When an unauthenticated user visits this page, Passwordstate establishes a partial session: authenticated is set to an empty string, and userID is set to Passwordstate/EmergencyAccess.

The core issue lies in the application's primary authentication function, which is called by individual pages rather than a global handler. This function checks the authenticated session property. If this property is an empty string, .NET attempts to convert it to a boolean, resulting in an exception and an error. The function also contains an if condition designed to prevent unauthenticated users from accessing protected pages: if (!unauthenticatedPage || authenticatedSession). If this condition is true, the user is redirected to a logout page.

The bypass hinges on tricking the application into believing the requested page is an "unauthenticated page," specifically by including /help/ in the URL path. While direct path traversal (/help/../admin/default.aspx) is prevented by IIS URL normalization, appending /help/ to a legitimate path (e.g., /admin/SystemSettings.aspx/help/) works due to path info. This .NET feature allows additional data after the requested file in the URL. Critically, while Request.FilePath correctly identifies /admin/SystemSettings.aspx, other properties like Request.Path and Request.RawUrl include the /help/ segment. Passwordstate's unauthenticatedPage check used Request.Path to look for /help/, making it return true.

By visiting /EmergencyAccess.aspx first to establish the partial session, and then navigating to a protected page like /admin/SystemSettings.aspx/help/, the if condition becomes if (false || authenticatedSession) because /help/ is detected. Since false || anything evaluates to false, the redirect to the logout page is skipped, and the .NET boolean conversion error is avoided. The application then processes the request with the Passwordstate/EmergencyAccess user ID, effectively bypassing authentication. This allowed Aidan to reach the page that prints the emergency access credentials, which could then be used to log in as a full administrator, leading to full compromise and RCE capabilities through Passwordstate's features.

Team Password Manager: Password Reset Authentication Bypass

Team Password Manager, written in PHP and protected by SourceGuardian obfuscation, presented a different challenge. Aidan briefly outlined his deobfuscation methodology: patching the SourceGuardian loader, hooking PHP's Zend engine to dump precompiled opcodes, deobfuscating these opcodes, extracting class/method signatures, and finally using an LLM to reconstruct readable PHP code.

The vulnerability (CVE-XXXX-XXXX) lay within the password reset flow. A standard reset involves submitting an email (Stage 0), receiving a link with a userID, an internal password reset token (a random SHA1 secret), and a reset hash (an integrity check), and then completing the reset on a Stage 2 page.

The flaw allowed an attacker to bypass Stage 0 and Stage 1 and jump directly to Stage 2. The Stage 2 route, auth/reset_password_step2, takes userID and an optional stageTwoToken (defaulting to an empty string). If an attacker visits /index.php/auth/reset_password_step2/1 (for userID=1) without providing stageTwoToken, it defaults to an empty string. The application then attempts to retrieve a stageTwoSecret from the session. Since no prior interaction occurred, the session is empty, and stageTwoSecret is null. A loose equality check (null == "") in PHP evaluates to true, allowing the attacker to proceed.

A subsequent function checkResetHash is called to verify the integrity hash. Crucially, after initializing a return value and correctly calculating the hash, this function unconditionally returns true at its very end, effectively nullifying the integrity check. With these two flaws, an attacker only needed the userID and the target user's email address. User IDs are sequential integers, easily enumerable. An email oracle exists on the password reset endpoint, where different error messages distinguish between non-existent emails and emails that don't match the provided user ID, allowing attackers to efficiently discover valid email-to-ID mappings. Additionally, an unauthenticated endpoint existed that could enable the password reset functionality if the admin's username, email, and user ID were known, providing another path if password reset was initially disabled.

Delinea Secret Server: SAML Authentication Bypass (XML Signature Wrapping)

Unlike the previous two, Delinea Secret Server was not obfuscated, offering a clearer path for code review. The SAML authentication bypass exploited a classic XML Signature Wrapping vulnerability. In a typical SAML login, the user is redirected to an Identity Provider (IdP), authenticates, and then the IdP sends a SAML response back to Secret Server (the Service Provider, SP) via the user's browser. Secret Server then processes this response, maps the SAML user to an internal account, and logs the user in.

The vulnerability lies in Secret Server's consume response step. The application decodes the XML SAML response and separates assertions into "signed" and "unsigned" buckets. The critical flaw is in how it combines these assertions and retrieves the username. The code iterates through the unsigned assertions first, adds them to a list, then iterates through the signed assertions (verifying their signatures), and finally encrypted assertions. When extracting the username, Secret Server simply takes the first assertion in this combined list that contains the username attribute.

An attacker can leverage this by initiating a legitimate SAML flow and authenticating as any user via the IdP. Before the SAML response reaches Secret Server, the attacker intercepts it in their browser. They then inject an unsigned assertion containing the username of a target administrator (e.g., <Assertion><Subject><NameID>admin</NameID></Subject>...</Assertion>) into the SAML response. Because the application processes unsigned assertions first and returns the first matching username, the injected unsigned assertion is used, and the attacker is logged in as the specified administrator.

Limitations for this attack include the requirement for a valid SAML response (meaning the attacker must be able to authenticate to the IdP as some user). Also, the overall SAML response itself must not be signed, as injecting an assertion would invalidate that signature. However, many IdPs like Microsoft Entra (Azure AD) and ADFS, by default, sign individual assertions but not the entire SAML response, making this attack feasible in common deployments.

Delinea Secret Server: Padding Oracle Vulnerability

The "bonus bug" was a padding oracle in Secret Server's virtual keyboard. The login screen displays a virtual keyboard where each character is an image generated dynamically via a URL like /CharacterImage.aspx?data=<hex_data>. This <hex_data> contains a cipher type, MAC type, IV, MAC, and ciphertext. Aidan observed that the application supported AES in CBC mode with PKCS7 padding and also allowed an empty MAC (no MAC).

These are the classic ingredients for a padding oracle attack: attacker-controlled IV and ciphertext, AES CBC mode, PKCS7 padding, and the absence of a Message Authentication Code (MAC). The oracle manifests as a distinguishable response: if the padding is valid after decryption, an image (even if garbled) is returned; if invalid, an error (e.g., 500 or 302 redirect) occurs.

A padding oracle allows an attacker to encrypt or decrypt arbitrary data with the key used by the oracle. In this case, the oracle used Secret Server's master encryption key. This meant an attacker with access to a database backup could decrypt its contents, potentially recovering all stored passwords. Aidan provided a real-world example where he found an old Secret Server database backup on a low-privilege network share, enabling him to decrypt its secrets and escalate privileges. While the padding oracle could also be used to forge cookies (e.g., a two-factor grace cookie to bypass MFA, or a passwordless login cookie), the direct impact for forging authentication was limited in Secret Server's specific implementation. Nevertheless, its ability to decrypt the master key and thus the database contents makes it a critical vulnerability.

Demo / Proof of Concept

▶ Watch: Bonus Bug: Secret Server Padding Oracle Vulnerability (37:40)

Aidan did not perform live demonstrations during the talk but clearly outlined the steps required to reproduce each vulnerability, making the proof-of-concept (POC) highly actionable for researchers and red teamers.

For the Passwordstate Emergency Access Authentication Bypass, the POC is remarkably simple, requiring only two HTTP GET requests:

1. Establish Partial Session: An attacker first navigates to the emergency access page (e.g., /EmergencyAccess.aspx) in their browser. This establishes the partial session with the Passwordstate/EmergencyAccess user ID and an empty authenticated session property.
2. Bypass Authentication and Retrieve Credentials: Next, the attacker navigates to a protected administrative endpoint with the /help/ path info appended, such as /admin/SystemSettings.aspx/help/. This request leverages the partial session and the path info trick to bypass the authentication check. The page then loads, printing the emergency access credentials (username, password, and 2FA secret). With these details, the attacker can then log in as a full administrator. Aidan noted that this entire process could be performed directly in a web browser without the need for a terminal, Burp Suite, or developer tools, highlighting its ease of exploitation.

The Team Password Manager Password Reset Authentication Bypass also has a straightforward POC:

1. Navigate Directly to Stage 2: The attacker navigates directly to the second stage of the password reset URL for a target user ID, for example, /index.php/auth/reset_password_step2/1 for user ID 1.
2. Submit New Password: On this page, the attacker enters the target user's email address (which can be enumerated via an oracle) and a new desired password into the form. Submitting this form successfully resets the target user's password. The attacker can then use the new password to log in as the compromised user.

For the Delinea Secret Server SAML Authentication Bypass (XML Signature Wrapping), the POC involves:

1. Initiate SAML Flow and Authenticate: The attacker initiates a SAML login flow to Secret Server and authenticates successfully at the Identity Provider (IdP) using any valid user account.
2. Intercept SAML Response: As the IdP sends the SAML response back to Secret Server, the attacker intercepts this HTTP POST request (e.g., using a proxy like Burp Suite).
3. Inject Unsigned Assertion: Within the intercepted SAML response XML, the attacker injects an additional, unsigned <Assertion> block that specifies the NameID of an administrative user they wish to impersonate.
4. Forward Modified Response: The modified SAML response is then forwarded to Secret Server. Due to the parsing logic, Secret Server processes the injected unsigned assertion first, logging the attacker in as the targeted administrator.

Finally, the Delinea Secret Server Padding Oracle POC would involve:

1. Craft Ciphertext and IV: An attacker constructs specific ciphertext and IV values based on the padding oracle attack methodology.
2. Send Request to Character Image Endpoint: These crafted values are sent as part of the data parameter to the /CharacterImage.aspx endpoint.
3. Observe Response: The attacker observes the HTTP response. A successful decryption (valid padding) results in an image being returned, while a failed decryption (invalid padding) yields an error response (e.g., HTTP 500 or a redirect to an error page). This differential response allows the attacker to perform byte-by-byte decryption or encryption with the master key.

These detailed descriptions of the POCs underscore the practical exploitability of the discovered vulnerabilities, reinforcing the critical need for defenders to address them promptly.

Defensive Implications

▶ Watch: Key Takeaways for Defenders and Attackers (43:40)

Aidan's research, while highlighting severe vulnerabilities, is not intended to discourage the use of password managers. He explicitly states that password managers are essential tools for securely generating, storing, and sharing credentials. Instead, the findings should serve as a call to action for defenders to adopt a more proactive and layered security posture, especially concerning critical infrastructure like enterprise password managers.

Here are the key defensive implications:

• Assume Vulnerabilities Exist: In an era where advanced tools, including Large Language Models (LLMs), are making vulnerability discovery increasingly accessible, defenders must operate under the assumption that exploitable bugs could exist in any software, even those designed for security. This mindset shifts the focus from preventing all bugs to building resilience against their eventual exploitation.

• Implement Layered Network Access Controls: Network access to password manager instances should be severely restricted. Implementing an application proxy that enforces strong multi-factor authentication (MFA) before allowing access to the password manager itself adds a critical layer of defense. This prevents direct access to potentially vulnerable endpoints from untrusted networks.

• Isolate Self-Hosted Password Managers from Active Directory: A significant recommendation is to deploy self-hosted password managers on standalone servers, isolated from the domain-joined infrastructure. Aidan notes that Active Directory has a much larger attack surface than a typical password manager, and real-world threat actors often compromise AD first before pivoting to the password manager. By decoupling the password manager from the AD environment, a Domain Admin compromise does not automatically grant local admin access to the password manager server, significantly raising the bar for attackers.

• Consider Zero-Knowledge Based Implementations: For organizations seeking the highest level of protection against server compromise, zero-knowledge based password managers are highly recommended. In these architectures, secrets can only be decrypted using the end-user's private key, which is never stored on the server. This design ensures that even if an attacker compromises the server or its database, they cannot trivially dump all secrets because the necessary decryption key is held exclusively by the end-user.

• Do Not Rely on Obfuscation for Security: Aidan emphatically states that obfuscation is not a security measure. While it might temporarily deter some researchers, it is ultimately security through obscurity. With the increasing sophistication of deobfuscation tools and the assistance of LLMs, obfuscation buys minimal time (perhaps "a couple extra hours" at best) and provides a false sense of security. Instead of obfuscating, vendors should focus on robust code quality, secure design, and thorough auditing.

• Prioritize Timely Patching and Updates: Given the speed at which threat actors can move from a vulnerability description to a working exploit, keeping all software, especially critical applications like password managers, up-to-date with the latest patches is paramount. Rapid patching is a fundamental defense against known vulnerabilities and significantly reduces the window of opportunity for attackers.

By adopting these defensive strategies, organizations can significantly enhance the security posture of their password managers, transforming them from potential "mismanagers" into truly resilient bastions of enterprise secrets.

Key Takeaways

Aidan's talk provided several crucial insights for both defenders and offensive security practitioners:

• Password Managers are High-Value, High-Risk Targets: Enterprise password managers hold the "keys to the kingdom" for an organization's entire digital infrastructure. Despite their critical role, they often receive less scrutiny than other core systems, yet they can be "amazing targets" for threat actors and may not be as "bulletproof as you think."
• Obfuscation is Not a Security Boundary: Commercial code obfuscators like Agile.NET and SourceGuardian provide a false sense of security. While they increase the initial barrier to entry for researchers, they are ultimately defeatable. Once deobfuscated, simple, high-impact bugs can be quickly uncovered, indicating that obfuscation primarily hides vulnerabilities rather than preventing them.
• Vulnerability Discovery is Becoming More Accessible: The advent of advanced tools, including Large Language Models (LLMs), is making the process of finding zero-day vulnerabilities significantly more accessible. This democratizes exploit development, empowering both ethical hackers and threat actors, and necessitates a shift in defensive strategies.
• Layered Defense and Isolation are Critical: Defenders must assume that vulnerabilities exist in their software. Implementing layers of defense, such as strict network access controls with MFA and isolating self-hosted password managers from domain-joined infrastructure (especially Active Directory), is crucial to mitigate the impact of compromise.
• Zero-Knowledge Architectures Offer Superior Protection: For maximum security against server-side compromise, organizations should consider adopting zero-knowledge based password managers. These designs ensure that even if the server or database is breached, the actual secrets remain encrypted and inaccessible without the end-user's private key.
• Timely Patching is Non-Negotiable: The rapid pace at which vulnerabilities are discovered and exploits are developed means that keeping software up-to-date with the latest patches is more critical than ever. This proactive approach is essential to stay ahead of evolving threats and reduce the window of exposure.

About the Speaker(s)

Aidan, who also goes by "deluxe" in some circles, is an Offensive Security Practitioner at Division 5, based in Brisbane. With approximately five years of experience in the field, Aidan primarily focuses on penetration testing but has recently expanded his work into security research. He is a long-time attendee of BSides Canberra, marking his fifth year at the conference, and this talk was his first time speaking on stage. His practical experience in internal security assessments heavily influences his research, driving him to investigate tools and systems commonly found in enterprise environments.