Introduction
During an engagement, Roy Sugiyama found an authentication bypass vulnerability that could be used to take over any Passwordstate user account with just the knowledge of the victim’s username. This issue has been rated as high severity by the Click Studios team and is assigned CVE-2024-39337.
Click Studios were responsive and helpful throughout the disclosure process, promptly triaging and fixing the vulnerabilities that were identified.
What is Passwordstate?
Passwordstate is a on-premises web-based application for Enterprise Password Management. It is used by organisations to manage and share credentials within their teams. It allows for integration with a local Active Directory environment, and supports adding Multi-Factor Authentication (MFA) on top of these logins.
Vulnerability Discovery
Passwordstate provides two primary authentication options:
- Active Directory integrated authentication; and
- Local Account Login authentication.
An authentication bypass vulnerability was found in both options, as described below.
Active Directory integrated login
Using just a victim’s Active Directory username, an attacker could bypass authentication and take over the victim’s Passwordstate account. This provides full access to any credentials that the user was provisioned access to, as well as any administrative functionality that the user is allowed to access.
In order to achieve this, the account must have been created and added to the Passwordstate application. The Active Directory integrated login feature must be enabled, the attacker must have the victim’s Active Directory username, and one of the following login pages must be accessible:
/logins/loginadan.aspx/logins/loginad.aspx
To execute this attack, first navigate to the /logins/loginadan.aspx page. Then, attempt to log in using the victim’s Active Directory username along with an incorrect password:
Ignoring the failed login, navigate directly to /logins/creategoogletfsecretkey.aspx. This page allows for MFA to be configured and should only be accessible once a user has successfully logged in. However, due to a misconfiguration within the application, a partial user session is set up. The attacker can then configure MFA for the victim’s account:
After the attacker completes the MFA setup, the application automatically authenticates the attacker despite the fact that a correct password was never provided. The attacker then has full control over the victim’s account.
It was found that this attack would work regardless of whether the victim user has set up MFA or not. In addition to the Google Authenticator MFA setup, other authentication setup endpoints such as one-time password (/logins/otp.aspx) and ScramblePad authentication (/logins/scramble.aspx) setup pages could also be used for a bypass in a similar manner.
Note that this attack could also be used as an MFA bypass - after an attacker logs in with stolen credentials, they can navigate to the /logins/creategoogletfsecretkey.aspx page to set up a new MFA and bypass the protection.
Proof of concept video
Active Directory integrated login (SAML option)
In our client’s environment, it was found that they had SAML authentication enabled for the Active Directory integrated login option. As mentioned previously, for the attack to be successful, an attacker must first access the login page which can be accessed at /logins/loginadan.aspx or /logins/loginad.aspx endpoint. If SAML authentication was enabled, it was found that navigating to either of these endpoints led to a redirect to the SSO login page, preventing the attacker from using the login form, as shown in the following screenshot:
This restriction can be bypassed by visiting the /emergency/ endpoint first. Subsequently, navigating to the /logins/loginad.aspx endpoint then allowed the user to access the login page. From here it was possible to carry out the account takeover attack as described previously.
Local Account Login
Further research revealed that the Local Account Login option was also vulnerable to a similar attack vector. This attack was achievable as long as the attacker had obtained the victim’s local account login name and one of the following login pages was accessible:
/logins/loginadan.aspx/logins/loginad.aspx
To execute this attack, an attacker would first navigate to the /logins/loginadan.aspx page. Then, the attacker would attempt to log in using the victim’s Local Login username along with an arbitrary password, as shown in the screenshot below:
Following this deliberate failed attempt, the attacker can navigate to the /logins/resetpassword.aspx page, where a password reset page for the victim user would be loaded, as shown in the screenshot below:
After the attacker completes the password reset, the application redirects the attacker to the login page. The attacker can now successfully log into the victim’s account using the newly-set password.
Proof of concept video
How To Fix
Update to the latest version of Passwordstate.
These issues have been patched in the following version:
- Build 9858
Vulnerability Disclosure Timeline
- 04/03/2024 - Vulnerability reported to Click Studios via Bastion’s client. They confirmed that the vulnerabilities are being addressed in the next release, 9858.
- 07/03/2024 - Build 9858 Released.
- 24/06/2024 - CVE-2024-39337 assigned.
- 25/06/2024 - Blog published.