Researchers have found an unexpected behavior in a Windows feature designed to protect remote sessions that could allow attackers to take control of them.
The issue, discovered by Joe Tammariello at the CERT Coordination Center (CERT) at Carnegie Mellon’s Software Engineering Institute, is documented as CVE-2019-9510. It stems from Network Level Authentication (NLA), which is a feature that you can use to protect Windows installations that have the Remote Desktop Protocol (RDP) enabled. NLA stops anyone from remotely logging into the Windows computer by requiring them to authenticate first.
Starting with Windows 10 release 1903 in April 2019, and with Windows Server 2019, Microsoft changed the way NLA works. Now, the authentication mechanism caches the client’s login credentials on the RDP host so that it can quickly log the client in again if it loses connectivity. The change enables an attacker to circumvent a Windows lock screen, warns CERT/CC, which disclosed the issue, in an advisory.
Let’s say you remotely log in to a Windows box using RDP. Then, you lock that remote desktop to stop an attacker from accessing it from your machine while you leave the room.
The attacker could interrupt the network connection between the local machine and the remote Windows box and then reestablish it, by unplugging the network cable and plugging it in again (or disabling and re-enabling Wi-Fi).
That’s where the unexpected behavior kicks in, according to the advisory:
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.
The behavior also bypasses multi-factor authentication (MFA) systems that integrate with the Windows login screen, explains the advisory. Duo Security admits that its MFA products are affected, adding that the issue isn’t its fault:
By forcing the use of cached credentials, Microsoft has broken functionality used by credential providers to add resilience to this workflow.
However, rival MFA firm Silverfort says that it isn’t affected because it doesn’t rely on the Windows lock screen:
Due to the way our products [sic] 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.
Microsoft also responded to the issue, explaining that it’s a feature, not a bug. It told CERT:
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 bypass NLA).
Unconvinced, Tammariello’s colleague Will Dormann still thinks you should work around it:
Courtesy of our own Joe Tammariello,
— Will Dormann (@wdormann) June 4, 2019
When connected via RDP, modern Windows session locking does NOT require authentication to unlock. Microsoft doesn't plan to change this behavior, so do not use the "Lock" feature over RDP. Log out when done or away! https://t.co/HTAmN8vrkw pic.twitter.com/fevq4LvA3V
Given that Microsoft isn’t fixing this any time soon, you should use the local machine’s lock screen rather than relying on the remote box’s lock, says the CERT advisory. You can also disconnect RDP sessions when you go and visit the loo. Yes, it’s annoying, we know.
Responding to a user complaint, a Microsoft Technet moderator also said it was possible to disable automatic reconnection on the RDP host via group policy, and provided instructions.
If the phrase ‘Network Level Authentication’ rings a bell, it’s because Microsoft has recommended this as a protection measure against exploitation of CVE-2019-07-08, nicknamed BlueKeep, the serious exploit affecting pre-Windows 8 systems, which the NSA, amongst many others, is now begging people to patch.
This issue doesn’t mean that you shouldn’t use NLA to protect your pre-Windows 10 boxes. For one thing, this unexpected behavior only exists on Windows 10 and Windows Server 2019. BlueKeep doesn’t affect these editions of the Windows OS.
Phil
As someone who has used RDP maybe a million times in 20 years, I can say that I have remote locked a server never.
Move on, nothing to see here. Lock your local computer when you step away. Duh.
Meh
Agreed. This MS haters simply bashing a morning burger.
Anonymous
Agreed. Unless you include how the attacker accesses the unlocked session.
JEFF MO
In all fairness, while you haven’t remote locked a server and thus aren’t exposed to the problem, others may have. I, for one, have done that, under the theory that the server is the important one and it should be locked, rather than the one that I’m sitting at. Having a security feature disabled, even though the condition may not come up often, seems to me to be the wrong way to treat security. A hole, even if not exposed often, is still a hole.
Gman
Wait, in this example, wouldn’t the attacker have access to your unlocked physical PC?
Yo
Yeah if I leave my computer unlocked, I don’t have to reenter my credentials to reopen my remoteapps. Even if I tell the remoteapp server to lock, all you would have to do is close the session and double click the shortcut and it has my credentials cached. You don’t even need to disconnect network….
Lock your PC
Bryan
@Phil
Time out of mind, I saw odd behavior which led me to distrust RDP disconnections for reliably locking remote boxes. Subsequent habit is a small .bat file containing
%windir%\System32\rundll32.exe user32.dll,LockWorkStation
My team used VNC when I last saw frequent Windows use by many admins; we built the habit then of locking the remote screen. Wish I’d known then about the above gem.
lks.bat, FTW!
Anyway, the point is that some have built alternate habits in different environments. We’d lock both local and remote if we left our desks.
Ryan
Yeah, I agree with Phil. You’ve got much larger problems than your RDP session if you’re leaving your local computer unlocked. I’d rather install keylogger software or pull passwords out of memory on your local machine. I can do a lot more with all of your passwords than I could with access to your remote session.
Brad
Good, as I read this article I thought it was strange since I have never remote locked a server I was connected to. I’ve had the remote server lock from having it in the background, but never have I locked it intentionally. Why would you?
Bryan
@Brad
At the job I mentioned in a comment above (and my job now…like lots of places), servers were racked with KVMs. While entering the server room required a badge swipe, anyone who manages to get in there had access to the kingdom.
Phil
@Bryan I don’t see the relevance. In a server room with KVMs, all of the computers would be logged off and locked. There is no RDP.
Mark
That was my first thought too. Why would anyone think that locking a remote session while leaving your desktop unlocked is a secure option?
On the other hand, just on the off-chance that someone might think this is a sensible thing to do, it’s important that people are aware.
IT
That is just silly. Literally implementing a major security flaw, for the sake of easier access. Sadly, the only “easier access” you get out of this is if your RDP session for whatever reason lost connection (which shouldn’t happen all that often). This move makes no sense. Sounds like devops dropped this feature in without security even being aware of it over at Microsoft.
Anonymous
Why would you not lock your local computer? This is security 101 when you leave your desk, especially when you are likely an admin.
Sorry, siding with MS on this one.
Anonymous
1903, not 1803 just an fyi
Paul Ducklin
Fixed, thanks!
Josh
I agree with MS on this… Lock your local machine when you step away and you avoid the issue…
epic_null
The fix for this bug seems really easy though – you can either decache the credentials on lock or refuse cached credentials while locked
mikemos
Um, come on. You protect your local computer. I consider all of the connections on my computer as open. If I don’t secure it, I don’t expect to be secure.
Jeff
Who locks the rdp session when away, but not their local machine?
Seriously, I’ve never even considered locking the RDP, that’s not the appropriate machine to lock. Giving someone unfettered access to your technician machine by not locking it when you step away is insane, and likely far worse leaving an RDP session unlocked.
It’s no wonder Microsoft is not concerned, nobody with any sense operates this way. This is a non-issue.
Anotheruser
MS is right. Not an issue. I’ve not once locked a remote system via RDP. What do you just leave your logged in account unlocked when you walk away? Hey attacker, no getting my rdp session, but compromise my local logon to your heart’s content.
IT Pro: Hey Microsoft I want to use NLA to secure my network!
Microsoft: ok cool, here you go!
IT Pro: omggggg if I leave my computer unlocked and walk away people can do bad stuff.
Microsoft: 🤦♂️
NutSec
Sure, proper behavior mitigates this. But we could say that about a lot of things we protect against and patch. For me, it’s expected that when a session is locked, only actively entering credentials will unlock it. Period. That’s how it’s always been. Remote or otherwise. MS effectively coded a parlor trick and someone called them out. The risk doesn’t outweigh the benefit. Shrug.
NutSec
Edit: The benefit doesn’t outweigh the risk. Said that backwards.
Max
I don’t really get it. Am I only vulnerable if I lock the remote pc, but keep my local pc unlocked? If so, what is the issue? Who keeps their local PC unlocked?
John Leslie
If you’re worried a Bad Actor might have access to your PC when you’re away, then locking the remote session and leaving the local PC unlocked seems, err, a little brave. They get the remote connection for free even if it’s locked, due to the spyware they presumably installed on your local PC.
0laf T. Hairy
It’s and RDP session but the exploit needs physical access to the machine or it’s immediate network. If I’m that close to an important piece of infrastructure you’ve got bigger problems
Martin DiViaio
Let’s face it. We’re all human here. While I’m certain we all use good practices mistakes will happen.
That said, even though it’s saved my butt several time, I’ve never been a fan of “cached credentials.” If you are using remote auth you should always have to remotely auth.
J
The DoD STIG sets the limit of cached credentials at four. When a server is used by more than four RDP users, the cache becomes a factor for user disconnections.
In any environment where service accounts exist along with users who RDP into the server where the service account-count is greater than four, our team sees connections that are unstable – with users connected via RDP randomly disconnecting.
Does this feature cache the service accounts? Will the service accounts disconnect users when they kick in for maintenance purposes in the wee hours of the night?
Francesco
I cant believe how many people think this is not an issue.
Whether one locks or not their local machine is irrelevant, any machine, local or remote, once locked should require to re-authenticate, that’s how it’s been since the dawn of Windows! This is a bug however they dress it, and a serious one.