Recently, CERT researchers published a vulnerability note (VU#576688 - Microsoft Windows RDP can bypass the Windows lock screen). In this blog post, we provide a little more insight into how the vulnerability was discovered and what it may mean to people who use Microsoft Windows RDP.

The following steps reproduce VU#576688:

1. Use a Microsoft Windows RDP client to connect to Windows Server 2019 or Windows 10 build 1803 or newer.
2. Manually lock the remote Windows session.
3. Disconnect the network on the RDP client system.
4. Reconnect the network.

After performing these four steps, you will notice that the remote session connected via RDP is restored to an unlocked state and doesn't require user credentials or multi-factor authentication.

The Software Engineering Institute (SEI) uses Cisco Duo for two-factor authentication. At some point, an SEI user reported a fraudulent Duo push to their mobile phone using the following dialog:

The push came in after work hours while the user was at home and when they were not using any SEI machines. They did not manually create any authentication attempts that should have resulted in a Duo push to their phone, so the push was an immediate red flag to the user. Because the user selected the "It seems fraudulent" option, the SEI IT Help Desk was alerted.

After further investigation, it was determined that the authentication attempt was generated from an internal SEI VPN IP address. This meant that if an attacker was trying to authenticate as our user, they were somehow already on our network. When speaking with the user, they indicated that they left their laptop connected to the SEI VPN in their office when they left for the day. They also mentioned that they left an RDP session active from their SEI-VPN-connected Mac laptop to their Windows 10 Desktop machine, which was also in their office. At that point, we had enough information to attempt to recreate the event.

To recreate the user's original scenario, we connected a Mac laptop to the SEI VPN and initiated an RDP session to a Windows 10 Desktop machine. The remote desktop session was locked, but the RDP connection remained active. At this point, we considered what could possibly initiate a Duo push in this scenario. The first thing that came to mind was a temporary network disruption. In this case, when the network connection was restored, the VPN client automatically reconnected. The Remote Desktop session also automatically reconnected, and a Duo push was automatically generated. We successfully recreated the exact scenario that the user experienced.

To perform due diligence, we repeated the same reproduction steps with a Windows 10 RDP client rather than a Mac RDP client. We performed the same steps of locking the remote session, temporarily disconnecting the network, and allowing the RDP client to reconnect; however, by using a Windows RDP client, the session was restored to an unlocked state. That is, not only were the user's credentials not required to unlock the remote RDP session, but also the Duo two-factor solution did not come into play.

After recognizing this behavior as odd, we discussed the situation and agreed that this behavior was unexpected. After further investigation, we determined that this reconnect behavior was introduced with Windows 10 1803 and subsequently Windows Server 2019. Prior Windows versions behaved as expected: an RDP session was restored to the state that it was left in. With older Windows versions, a locked remote RDP session that reconnected would leave the user at a Windows lock screen, requiring the configured authentication to be performed to unlock the remote session.

After 45 days, we indicated to Microsoft that we would soon publish vulnerability note VU#576688. Their response was along the lines that the behavior we experienced does not cross any security boundary, and that valid, cached credentials are being used by the RDP client to unlock the remote session.

We agree that the vulnerability is not critical. The attack scenario of a user leaving their RDP client system unlocked, but only locking the remote RDP session, is indeed a bit contrived. But the new Windows behavior does violate our expectations of how RDP should work. If a user explicitly locks their remote RDP session, something like a network anomaly should not result in that remote session being unlocked without requiring them to enter their credentials.

In coordinating VU#576688, some two-factor authentication vendors were concerned about being listed as vulnerable. After all, if the software vendor did nothing wrong in creating a two-factor authentication solution for Windows, is it fair to list them as Affected only because of a change that Microsoft made to Windows? In short: Yes.

Software does not live in a vacuum. Software that runs on Microsoft Windows may be affected by changes that Microsoft decides to make to Windows. In this case, a change to Microsoft Windows changed the behavior of several two-factor authentication solutions. If a product claims to enforce two-factor requirements to unlock a user session in Windows, anything that negates that claim does, indeed, affect their product. This is one of the reasons why CERT/CC vulnerability notes use the term Affected. It is not an indicator of blame in any way, but rather it is an indicator of whether customers of the listed vendor might care about the vulnerability in question.

Quite often, vulnerability discovery does not require super-human skills. In its simplest case, vulnerabilities can be discovered by using three simple steps:

1. Use systems.
2. Notice anomalies.
3. Investigate anomalies.

These were the only steps we used to discover the Windows RDP vulnerability VU#576688. In the end, this vulnerability is not overly critical. But it does violate our expectations about how lock screens work in Windows.