A new zero-day vulnerability has been disclosed that could allow attackers to hijack existing Remote Desktop Services sessions in order to gain access to a computer.
The flaw can be exploited to bypbad the lock screen of a Windows machine, even when two-factor authentication (2FA) mechanisms such as Duo Security MFA are used. Other login banners an organization may set up are also bypbaded.
It should not happen this way
The issue is now tracked as CVE-2019-9510 and is described as an authentication bypbad using an alternate path or channel.
An advisory today from the CERT Coordination Center at the Carnegie Mellon University Software Engineering Institute (SEI), warns that session locking can behave in an unexpected way on the last Windows systems where remote desktop sessions use NLA.
Even if a user specifically locks a Windows machine during an RDP session, if the session is temporarily disconnected, automatic reconnection restores the session to an unlocked state, "regardless of how the remote system was left." This affects Windows 10 starting version 1803 and Server 2019 or newer.
Will Dormann, vulnerability badyst at CERT / CC, describes the following attack scenario:
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
An attacker could then interrupt the network connection of the RDP client, which will cause it to automatically reconnect and bypbad the Windows screen lock. This could then allow a local attacker to gain access to the unlocked computer at the end of the Remote Desktop session.
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.
Dormann told BleepingComputer that "it's not really likely to be exploited much in the wild, but it's definitely an unexpected behavior."
CVE-2019-9510 was discovered by Joe Tammariello of Carnegie Mellon University SEI. It received a severity score of 4.6 out of 10.
Microsoft was notified of the issue on April 19 and replied by saying that the "behavior does not meet the Microsoft Security Servicing Criteria for Windows." Below is the full statement:
After investigating this scenario, we have determined that this behavior does not meet the Microsoft Security Servicing Criteria for Windows. What you are observing is Windows Server 2019 honoring Network Level Authentication (NLA). Network Level Authentication requires user creds to allow connection to proceed in the earliest phase of connection. Those same creds are used logging the user into a session (or reconnecting). As long as it is connected, the client will cache the credentials used for connecting and reuse them when it needs to auto-reconnect (so it can bypbad NLA).
BlueKeep mitigation is still good
When details about BlueKeep (CVE-2019-0708) were published, Microsoft said that turning on NLA would act as a mitigating factor against 'wormable' malware that would exploit the vulnerability.
The temporary solution relies on the fact that NLA requires authentication before triggering the vulnerability, so the attacker would need valid credentials to access the vulnerable system.
Even if CVE-2019-9510 changes NLA's behavior, this effect is not seen on systems impacted by BlueKeep (Windows 7 and Server 2008). NLA is still a reliable security feature. What this vulnerability shows is anomaly and administrators should be aware of this outcome on newer versions of Windows.
BlueKeep is a serious vulnerability that can lead to remote code execution on Windows operating system. It affects the Remote Desktop Services and this makes it attractive for deploying wormable malware.
Proof-of-concept code has been developed by security researchers and cybercriminals should not be behind, there are about one million systems vulnerable to BlueKeep, and scanning the web for them continues to intensify.
Statistics collected from a RDP honeypot controlled by security researcher Daniel Gallagher show upward trend in scans for computers vulnerable to BlueKeep.