search menu icon-carat-right cmu-wordmark

CERT Coordination Center

Microsoft Windows RDP can bypass the Windows lock screen

Vulnerability Note VU#576688

Original Release Date: 2019-06-04 | Last Revised: 2019-06-17

Overview

Microsoft Windows RDP can allow an attacker to bypass the lock screen on remote sessions.

Description

In Windows a session can be locked, which presents the user with a screen that requires authentication to continue using the session. Session locking can happen over RDP in the same way that a local session can be locked.

CWE-288: Authentication Bypass Using an Alternate Path or Channel (CVE-2019-9510)

Starting with Windows 10 1803 (released in April 2018) and Windows Server 2019, the handling of RDP sessions has changed in a way that can cause unexpected behavior with respect to session locking. If a network anomaly triggers a temporary RDP disconnect, upon Automatic Reconnection the RDP session will be restored to an unlocked state, regardless of how the remote system was left. For example, consider the following steps:

  1. User connects to remote Windows 10 1803 or Server 2019 or newer system using RDP.
  2. User locks remote desktop session.
  3. User leaves the physical vicinity of the system being used as an RDP client

At this point, an attacker can interrupt the network connectivity of the RDP client system. The RDP client software will automatically reconnect to the remote system once internet connectivity is restored. But because of this vulnerability, the reconnected RDP session is restored to a logged-in desktop rather than the login screen. This means that the remote system unlocks without requiring any credentials to be manually entered. Two-factor authentication systems that integrate with the Windows login screen, such as Duo Security MFA, may also bypassed using this mechanism. We suspect that other MFA solutions that leverage the Windows login screen are similarly affected. Any login banners enforced by an organization will also be bypassed.

It is important to note that this vulnerability is with the Microsoft Windows lock screen's behavior when RDP is being used, and the vulnerability is present when no MFA solutions are installed. While MFA product vendors are affected by this vulnerability, the MFA software vendors are not necessarily at fault for relying on the Windows lock screen to behave as expected.

Note that this vulnerability was originally described as requiring Network Level Authentication (NLA). We have since confirmed that this behavior is present whether or not NLA is enabled. Also, some combinations of RDP clients and Windows versions prior to Windows 10 1803 and Server 2019 may also demonstrate automatic session unlocking upon RDP reconnect. In such cases, neither MFA integrated with the login screen nor login banner displaying is bypassed in our testing. Although these cases are a different issue than VU#576688, the workarounds listed in this vulnerability note should still be applied to prevent these similar symptoms.

Impact

By interrupting network connectivity of a system, an attacker with access to a system being used as a Windows RDP client can gain access to a connected remote system, regardless of whether or not the remote system was locked.

Solution

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds.

Disable RDP Automatic Reconnection on RDP servers

Microsoft RDP supports a feature called Automatic Reconnection, which "... allows a client to reconnect to an existing session (after a short-term network failure has occurred) without having to resend the user's credentials to the server." This Automatic Reconnection feature, used in conjunction with this vulnerability, can allow an attacker to reach a user's desktop session without needing to provide any credentials. The Automatic Reconnection feature can be disabled in Windows Group Policy by setting the following key to disabled:
Local Computer -> Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections -> Automatic reconnection



Protect access to RDP client systems

If you have a system that is being used as an RDP client, be sure to lock the local system as opposed to the remote system. Even if the local system has nothing of value on it, the live RDP session will only be protected by limiting access to the client system. Locking the remote system over RDP does not provide any protection.

Disconnect RDP sessions instead of locking them

Because locking a remote RDP session provides no effective protection, RDP sessions should be disconnected rather than locked. This invalidates the current session, which prevents an automatic RDP session reconnection without credentials.

Vendor Information

Note that vendors other than Microsoft listed as "Affected" are simply indicators that the vendors have products that are affected by this vulnerability in Microsoft Windows RDP. The vendors' actual products do not necessarily contain a vulnerability, but rather that the vendor has a product that may not provide the login protection as expected, as the result of this issue with Microsoft Windows.

576688
 
Affected   Unknown   Unaffected

Centrify

Notified:  June 05, 2019 Updated:  June 06, 2019

Statement Date:   June 06, 2019

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Duo Security

Notified:  April 22, 2019 Updated:  June 06, 2019

Status

  Affected

Vendor Statement

The Windows login/lock screens are secured by credential providers that collect credentials and perform other authentication-related activities, such as multi-factor authentication (MFA). Some are provided by Microsoft—the most common one being the password provider that usually collects the password as part of login. Other third-party providers, such as Duo, work similarly to the Microsoft providers, but add an additional element of MFA to the login.

With changes introduced in v1803 of Windows 10 and Server 2019, Microsoft has decided to use the credentials cached on the client machine to both re-authenticate the connection and unlock the previously-locked desktop, upon reconnecting Remote Desktop Protocol (RDP) sessions. In doing so, Microsoft has hindered credential providers from being able to prompt when a machine is unlocked in this context. By forcing the use of cached credentials, Microsoft has broken functionality used by credential providers to add resilience to this workflow.

To be clear, this is not a vulnerability or defect in Duo's service, but rather, it is a defect in how Microsoft has decided to unlock reconnected RDP sessions that have cached, valid authentication credentials without prompting the user.

We are unaware of Microsoft providing any effective workarounds for this unexpected change, but will continue to evaluate options to provide an integration as was previously achieved. We hope that Microsoft will provide appropriate configuration to allow those that want the previous functionality to be restored to be able to do so.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Microsoft

Notified:  April 19, 2019 Updated:  June 11, 2019

Statement Date:   May 29, 2019

Status

  Affected

Vendor Statement

    After investigating this scenario,  Microsoft has determined that this scenario
    is using valid, cached credentials. It does not compromise security boundaries
    or bypass security features.  Therefore it does not meet the Microsoft Security
    Servicing Criteria for Windows.  The RDP behavior change observed in VU#576688
    was introduced in Windows Server 2019. The change allows the connection to
    proceed in the earliest phase of connection. As long as it is connected, the
    client will cache the credentials used for connecting and reuse them when it
    needs to auto-reconnect.


    As a best practice, Microsoft recommends that users always lock the client RDP
    and all computers when unattended.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Okta Inc.

Notified:  June 05, 2019 Updated:  June 07, 2019

Statement Date:   June 06, 2019

Status

  Affected

Vendor Statement

This is not a vulnerability or defect in Okta’s service or multi-factor
authentication (MFA) integration to Windows Server. Rather, this is an issue in
how Microsoft unlocks reconnected Remote Desktop Protocol (RDP) sessions
without calling the credential provider.

The Okta MFA Credential Provider does not currently support Windows 10 or
Windows Server 2019. However, any organization that has chosen to use the Okta
MFA Credential Provider for Windows 10 or Windows Server 2019 may be vulnerable
to this Microsoft issue, and users may not be prompted for authentication or
MFA upon re-establishing an RDP session.

As of June 6, we are unaware of any official Microsoft fix, and advise our
customers to reach out to Microsoft for next steps.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Authy

Notified:  June 05, 2019 Updated:  June 06, 2019

Statement Date:   June 05, 2019

Status

  Not Affected

Vendor Statement

We do not provide windows login integration at any level.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Gemalto AV

Notified:  June 05, 2019 Updated:  June 17, 2019

Statement Date:   June 17, 2019

Status

  Not Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Silverfort

Notified:  June 05, 2019 Updated:  June 17, 2019

Statement Date:   June 05, 2019

Status

  Not Affected

Vendor Statement

Due to the way our products operates, we are not affected by this vulnerability. We use a unique technology which allows us to enforce MFA on top of the authentication protocol itself (e.g. Kerberos, NTLM, LDAP) without  relying on Windows login screen.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

TUNIX Digital Security

Updated:  June 11, 2019

Status

  Not Affected

Vendor Statement

TUNIX/Authenticationservice interacts at a level that is not affected.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

AuthLite

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Idaptive

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

ManageEngine

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Ping Identity

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

RSA Security, Inc.

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

SecureAuth

Notified:  June 05, 2019 Updated:  June 06, 2019

Statement Date:   June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Symantec

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vasco

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Watchguard Technologies, Inc.

Notified:  June 05, 2019 Updated:  June 05, 2019

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

View all 17 vendors View less vendors


CVSS Metrics

Group Score Vector
Base 4.6 AV:L/AC:L/Au:N/C:P/I:P/A:P
Temporal 4.1 E:POC/RL:U/RC:C
Environmental 4.2 CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

Acknowledgements

Thanks to Joe Tammariello of the SEI for reporting this vulnerability.

This document was written by Will Dormann.

Other Information

CVE IDs: CVE-2019-9510
Date Public: 2019-02-19
Date First Published: 2019-06-04
Date Last Updated: 2019-06-17 13:48 UTC
Document Revision: 134

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.