Skip to main content

Microsoft Windows RDP can bypass the Windows lock screen

Vulnerability Note
Original Release Date: 2019-06-04 | Last Revised: 2019-06-19

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.

Comments

Post a Comment

Popular posts from this blog

Site-to-site IPsec VPN with two FortiGates

In this example, you will allow transparent communication between two networks that are located behind different FortiGates at different offices using route-based IPsec VPN. The VPN will be created on both FortiGates by using the VPN Wizard's   Site to Site - FortiGate   template. In this example, one office will be referred to as HQ and the other will be referred to as Branch. 1. Configuring the HQ IPsec VPN On the HQ FortiGate, go to  VPN > IPsec Wizard . Select the  Site to Site  template, and select  FortiGate . In the  Authentication  step, set  IP Address  to the IP of the Branch FortiGate (in the example,  172.20.120.135 ). After you enter the gateway, an available interface will be assigned as the  Outgoing Interface . If you wish to use a different interface, select it from the drop-down menu. Set a secure  Pre-shared Key . In the  Policy & Routing  step, set the  Loca...
Post a Comment
Read more

Be fraud aware - What are phishing, smishing and vishing.

  You may have heard the terms phishing, smishing or vishing before, but what exactly do they mean? At their core, all three terms are a type of financial fraud which tricks unsuspecting victims into giving out sensitive personal information, handing over money or installing malware onto their device. The only difference between each term is the channel via which you can be targeted; phishing refers to scam emails, smishing refers to scam text or WhatsApp messages and vishing takes place over the phone. Phishing The most common phishing method encourages victims to visit a malicious website through a fake email message, which appears to be sent from a legitimate company or source (e.g. from a bank, HMRC, a delivery company or the NHS). For example, you might receive an email which appears to be from an organisation who you’re familiar with, asking you to click on a link. At this point you will be taken to a webpage on which you’re asked to submit sensitive data, such as passwords, ...
Post a Comment
Read more

Cisco Releases Security Updates for Cisco ASA 5506-X, 5508-X, 5516-X and Firepower// Cisco Bug IDs: CSCvp36425

A vulnerability in the cryptographic driver for Cisco Adaptive Security Appliance Software (ASA) and Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the device to reboot unexpectedly. The vulnerability is due to incomplete input validation of a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) ingress packet header. An attacker could exploit this vulnerability by sending a crafted TLS/SSL packet to an interface on the targeted device. An exploit could allow the attacker to cause the device to reload, which will result in a denial of service (DoS) condition. Note:  Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed and transparent firewall mode and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. A valid SSL or TLS session is required to exploit this vulnerability. Cisco has...
Post a Comment
Read more