During an on-site visit to a customer, I came across an installation of Imprivata Enterprise Access Management (EAM). The software allows authentication using a smart card and PIN, which is commonly used on computers shared by multiple users. My curiosity as a security professional of course led me to investigate this beyond the intended use. To my surprise, I discovered a specific keyboard combination that allowed for a complete bypass of the Imprivata login screen, granting direct access to the underlying Windows environment.

The discovery occurred during the configuration of a new workstation with the Imprivata software. Once the shared workstation was set up, a pre-configured Windows autologon account automatically signed in to the Windows environment. Immediately afterward, the Imprivata login interface appeared, prompting individual users to authenticate themselves. Imprivata refers to this configuration as “shared kiosk workstations”.

I observed that the Imprivata software is the only layer controlling user access to the already authenticated Windows environment running under the autologon account. This observation awakened my curiosity, prompting me to test some common keyboard shortcuts. After a few attempts, I actually found a shortcut to bypass the Imprivata login screen, granting direct access to the underlying Windows environment.

The issue was immediately discussed with the customer on-site and, in coordination with the customer, a responsible disclosure process was initiated to notify the vendor.

As a result, the vendor has released fixes for this vulnerability for all supported versions.

Security Advisory for CVE-2024-12310

A vulnerability in Imprivata EAM (formerly Imprivata OneSign) allows bypassing the login screen of the shared kiosk workstation and allows unauthorized access to the underlying Windows system through the already logged-in autologon account due to insufficient handling of keyboard shortcuts. The vulnerability was rated with a CVSS v4.0 score of 7 (High) and assigned CVE-2024-12310.

Technical Details

On shared kiosk workstations, a dedicated Windows account is automatically logged-in upon startup. Following this, a login screen from Imprivata EAM is displayed, where authorized users can authenticate using options like a smart card and PIN or a username and password. This login screen is what is preventing an attacker from directly accessing the underlying Windows system. However, an attacker can use a specific key combination to bypass the login screen and gain access without providing any form of authentication. After bypassing the login screen, the attacker gains direct access to the Windows environment with permissions of the dedicated Windows account that is used to automatically log in. This unauthorized access gives the attacker control over the workstation, enabling them to launch further attacks. For instance, they might execute attacks against the Active Directory, compromise internal network services, or exfiltrate sensitive local files, depending on the privileges assigned to the compromised user and system.

Successful exploitation of this vulnerability requires an attacker to have physical access to the target workstation. Additionally, a keyboard must be attached or an exposed USB port must be accessible. In addition, the following configuration is required for successful exploitation:

• The Imprivata agent must be configured as “Shared Kiosk Workstations (Type 2)”
• The setting Configuration - Computer Policy: > Customization > Login UI experience must be set to Classic windows login (Default value: Imprivata login)
• The setting Configuration - Computer Policy: > General > Authentication > "If SSO authentication fails, but Windows authentication succeeds, should the user be allowed to log in to the computer? must be set to Yes (Default value: Yes)
• The setting Configuration - Computer Policy > General > Authentication > "Allow Users to Exit and Disable Agent" must be set to No (Default value: Yes)

Proof-of-Concept

The release of a proof-of-concept is planned for Q4 2025 as requested by Imprivata to allow their customers enough time to patch relevant systems.

Affected versions

This vulnerability was found in Imprivata OneSign version 24.2. The vendor has indicated that all versions of Imprivata Enterprise Access Management from 5.3 and above are also impacted.

Fixed versions

According to the vendor, the following versions are not affected anymore by this vulnerability and are available through the Imprivata customer Portal or by contacting Imprivata’s support:

• Imprivata EAM 23.3 (Wolf) HF6
• Imprivata EAM 7.11 (Titan) HF11
• Imprivata EAM 24.3 (Zeus) HF1
• Imprivata EAM 23.2 (Vega) HF8
• Imprivata EAM 24.1 (Xena) HF4
• Imprivata EAM 24.2 (Yoda) HF3
• Imprivata EAM 7.12 (Umbara) HF9

The vulnerability is resolved entirely through an update to the agent, with no changes needed to the appliance. The fix was verified by Redguard and its customer in a diagnostic version of release 24.1. Other versions were not explicitly tested.

Suggested Mitigations and Countermeasures

It is recommended to upgrade Imprivata EAM to one of the fixed versions. Should this not be possible, the vendor states that one of the following settings can be applied, which should prevent exploitation of this vulnerability:

• Set Configuration - Computer Policy: -> Customization -> Login UI experience to Imprivata login
• Set Configuration - Computer Policy: -> General -> Authentication -> "If SSO authentication fails, but Windows authentication succeeds, should the user be allowed to log in to the computer? to No

The effectiveness of these settings has not been verified either.

Credits

• Patrik von Allmen, Redguard AG

Timeline

In the timeline below, the customer refers to the customer of Redguard where the vulnerability was identified and the vendor refers to the Imprivata team.

• 2024-11-13: The vulnerability was initially discovered and reported to the customer.
• 2024-11-13: Redguard reported the vulnerability to the vendor.
• 2024-11-13: The vendor requested additional information about the vulnerability.
• 2024-11-18: Redguard contacted BACS as CNA of Switzerland to request a CVE.
• 2024-11-19: Redguard contacted the vendor again due to no response.
• 2024-11-20: The vendor confirmed the existence of the vulnerability.
• 2024-12-04: Meeting between Redguard and the vendor regarding further details of the vulnerability and next steps.
• 2024-12-04: Redguard received a fix for testing with its customer.
• 2024-12-12: Vendor started releasing the first fixes for affected versions.
• 2025-01-28: The vendor informed their customers about the vulnerability.
• 2025-07-23: Public disclosure of this advisory.

Disclaimer

This document is not meant to be a complete list of security issues for any of the mentioned software and/or versions. It is possible, and indeed likely, that there are further security issues that are yet to be identified. The information in the advisory is believed to be accurate at the time of publishing, based on currently available information.

Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties regarding this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.