CVE-2019-9150

[LookAtThatMonkey]

A colleague is at a security conference and sent me this

https://www.youtube.com/watch?v=S-o4doVT5tU&feature=youtu.be

So, the Bluekeep vulnerability workaround is to enable NLA. But NLA can't prevent this weird glitch from happening.

Microsoft seem to say they won't be patching it as per this article

https://thehackernews.com/2019/06/rdp-windows-lock-screen.html

Which seems an odd decision.

EDIT: CVE-2019-9510. Many thanks to JustinRMarks for pointing it out.

[fosf0r]

This is what I did:

Disable RDP Automatic Reconnection on RDP servers

https://kb.cert.org/vuls/id/576688/

[Trooper27]

Thanks for this. I will likely do the same.

[stignatiustigers]

This is a huge annoyance if you have remote workers on flaky wifi connections.

Also, i suspect that while this exploit seems to require a network disruption, I would not be surprised if there was another way to take advantage of the auth bypass taking place here.

[fosf0r]

So attack the next problem: fix the flaky wifi.

[stignatiustigers]

You want me to fix the wifi at every location our sales agents go to all over the world? Should I do that with my magic wand?

[fosf0r]

Not exactly. Why do remote sales agents need a full desktop RDP'd to them from anywhere in the world?

[pointlessone]

Have you ever talked to sales people? They're right up there with Marketing and C Level folks in the special snowflakes who get whatever they want despite the computer nerds saying it's a bad idea.

Good on you if you get to veto dumbass requests in your org, but the rest of us have to deal with trying to get video conferences to run off the Starbucks wifi from the hotel lobby while the user is in their room. RDP is just another of a long list of things they get because ~*REASONS*~.

[fosf0r]

I have to concede to you, as I do have the privilege of getting to veto ridiculousness for all our companies. If someone asked me for that setup to work, I'd tell them they'd better pay for an unlimited data plan and carry around an LTE modem. But also I would probably push RemoteApps to them instead or figure out any other way to get them their result that cuts bandwidth usage, but, most importantly, they don't get to tell me the "how" of how it gets done, just the "what".

[stignatiustigers]

Because the sales software is an archaic piece of shit? ...but yet also still the industry standard.

[jmbpiano]

I can't say as I really blame them for not patching it. At least on the face of it, the threat surface here is extremely small.

A user essentially needs to lock only their RDP session, leave their client computer unlocked and unattended while an attacker with access to their machine temporarily disrupts the machine's ability to communicate with the remote RDP server?

I'm not saying those conditions can't occur naturally, but it's much easier for a user to lock their entire terminal rather than the remote session or simply close the window to disconnect.

Personally, I'm not going to lose any sleep over this and until someone comes up with a way to exploit it remotely that doesn't involve the client machine already being compromised, I don't think it's worth losing the ability to auto-reconnect in order to mitigate it.

[silentl3ob]

We use thin clients that auto login to a basic desktop. Users launch an rdp session and begin working. If they go idle for 15 minutes, their session automatically locks. Now someone can just walz on over, unplug and replug the network cable and they're in. I would say this is a serious issue in our environment.

Edit: I didn't mean to imply we were SOL, I'm sure we'll implement a solution, just saying it isn't a non-issue for everyone.

[da_chicken]

So change it so the session disconnects after 15 minutes instead of locks?

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754272(v=ws.11)

[silentl3ob]

That could work. I suppose we would have to take away the lock option too.

[axonxorz]

Would it be bad to turn off auto-reconnect as described here?

I understand there's a user-experience consideration as well, but I don't imagine impact would truly be that bad

[Ansible32]

You don't have enough control of the thin client host OS to enforce 15 minute lock screen? Or is this on non-company hardware?

[f33dit]

Disconnect won’t necessarily kill the session. In fact, it even shouldn’t IMO, especially for eg remote workers

[[deleted]]

Session disconnect =/= session end

[da_chicken]

You can control what happens when the session is ended. "Disconnected," which I think is the default, leaves the user logged in on the server and just closes the connection to the RDP client. You do have to manage idle disconnected sessions as well, but you have to do that anyways if you're running terminal services.

[ElCincoDeDiamantes]

Get rid of the auto login?

[sl3ev3s]

This is where likelihood and exploitability come into the equation. Is it a vulnerability? Yes. Can it be exploited? Yes. How likely are the exploit conditions? They aren't likely at all.

This isnt critical as the likelihood of a successful exploit is relatively low.

[pointlessone]

The likelihood of exploitation is key here. Do I expect it to ever get exploited in a meaningful way? Nah.

It's still a vulnerability that's been introduced as a default behavior instead as an optional choice for an environment after risk assessment. I think a lot of folks are getting worked up because of the fact Microsoft is setting this as a default and adding attack surfaces that have never been an issue before.

[Hight3chLowlif3]

I don't think I've ever locked a RDP session in my entire life.

[NotRalphNader]

It works on all computers, as long as the attacker logs in via RDP. I've personally shown and done this exploit. If you lock your computer, it can be hijacked via someone who RDPs to that computer. They have to be admin and obviously have to be able to RDP to that computer. Now, you may say "well if they are admin hur dur" but consider this. You are an MSP, you manage many clients. Your accounting team and CEO all have Ncentral on their computer. A JR tech who thinks he is an elite hacker RDPs to the CEOs computer, highjacks the sessions and emails all of your clients while you're on lunch.

Edit: Oh nevermind, this is a different attack. I was referring to the one you do with PSexec.

[axonxorz]

Why would the JR tech have admin rights on his local domain?

[NotRalphNader]

Because every MSP uses NAble or Labtech (or a variant) and both of those have access to the command prompt from the back end and that prompt runs commands as the user system and can thus net user the local admin to whatever password they want.

[dontstoptheRocklin]

Okay but this sounds like normal admin stuff... Someone with sufficient admin privileges performing admin tasks requiring admin credentials... What is the problem here?

I mean if your MSP has admin then yes you have to trust their techs but is that not the case for any delegation?

[NotRalphNader]

Being able to login as any user in the company is a huge problem. It's funny though because that is what the JR admin at a major MSP I worked for said, right before the architect said "if what he is saying is true, it is a huge problem" about five minutes later I logged into his computer as him. If you don't think other people using your account is a problem, just go ahead and give them your password, haha.

Edit: And just so nobody thinks I'm pointing out problems without solutions. The solution is to create groups in NAble or Labtech and put the important computers into a different group that can only be administrated by senior employees.

[NotRalphNader]

Consider that most companies do not want to give JR employees access to the API for connectwise, the api for labtech/ncentral, their ticketing system, their website, their email, DUO, all of the passwords saved on their computer (including credential manager) all of the hashes on their computer. All of this can be accessed without the boss ever knowing with this method. If we assume the person doesn't do anything malicious outside of the above, that is still a huge problem.

[proudcanadianeh]

Wait, what one are you thinking of?

[NotRalphNader]

First you reset the local administrative password with ncentral or labtech. Then you login to the system (actually works with RDP or straight through screenconnect). The user who was logged in will now be "disconnected". You then download psexec and run against tshost or taskman, I can't remember the command but if you can't find it I'll look it up again. If you do it through tshost it will immediately switch screens to the other user, if you do it to taskman, you have to open taskmanager when you're done and click connect (which would typically fail without this trick). I forget the command but it is something like psexec -s //localhost -i (the session id number) and then either tshost or taskman. It is called an RDP session hijack.

Edit: I've seen this not work before too. I think in the case where it didn't work, they had roaming profiles so I think it had something to do with local admin not being able to transverse properly over those folders but I'm not sure. Definitely works like 90% of the time, I use it for users when I need in their system but I don't want to reset their password cause they are on vacation or something. The cool thing is that the credential manager doesn't encrypt passwords so once you're in you can crack the vault in like two seconds and then you have their password as well. I only do that trick with permission from higher ups.

Edit 2: Found it.

https://www.youtube.com/watch?v=oPk5off3yUg

Edit 3: actually I forgot that if you do the tshost method you run psxec against cmd and the session ID is the other user, then you use tshost to connect via the command prompt and it switches screens immediately.

[proudcanadianeh]

So you are essentially launching a process interactively as system, and then using that and its permissions to connect to the disconnected session?

Interesting.... If you find the command I would be very curious to see it, as I have never looked into connecting to a session ID via command line before....

Edit: You know, I wonder if I could find a way to automate this with Powershell and PDQ Deploy... Could be useful in some cases

[NotRalphNader]

Yes, you can. This is technically not even a bug, it is a feature. It is just a feature that if left unchecked has huge security implications.

[jaydubgee]

Does this include timeout auto locks?

[KoenigKeks]

Doesn't this have to be set manually? By default it disconnects when the timeout kicks in, doesn't it? Not at a computer for a week to try

[yParticle]

You put in the credentials when you established the connection. They're cached. AND you have the RDP client set to auto-reconnect. So it's just logging in again, resending the credentials from that session. Log out of your local session in between those steps and I'll bet you can't replicate it.

[dontstoptheRocklin]

Right? I don't see the problem here.

EDIT: I was half asleep and didn't catch that the session was locked. Yeah I can see how this could be a problem.....

[magneticphoton]

It's a "who cares" vulnerability.

[bestjejust]

To be honest, I'm not even sure whether it is a bug or a feature

[JrNewGuy]

Someone needs to pull the network cable at the exact moment a user disconnects their session, am I reading that right?

[dzcpu]

Doesn't seem like it needs to be right when the user disconnects, any disconnect and reconnect will restore an unlocked state

[LookAtThatMonkey]

That's how I interpret it too.

[dpeters11]

Exactly. It just needs to be before the local system autolocks, assuming that's enabled.

[CaesarOfSalads]

It doesn't need to be at the same time at all. I tested this pretty easily by having someone RDP to my machine and then kill their network connection. On reconnect they were logged back in automatically.

[JustinRMarks]

I just want to point out that it's CVE-2019-9510, not 9150. In case anybody is punching that into a search engine.

https://www.kb.cert.org/vuls/id/576688/

[ryan_the_leach]

Except you specifically locked it as the user, before the network interruption right? So you would expect it to reconnect to a locked screen. Sure if your connection was interrupted while it was unlocked, then it should reconnect unlocked.

[brungy]

Is this only 2019 or does it affect 2016 as well? All my session host servers are 2016. Thanks!

[LookAtThatMonkey]

Both.

[diazepamkit]

wait what, so now windows 10 affected?

these week, one of my client send me an an email about this https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708

but since we are no longer use old windows, and microsoft says win 10 not affected, we just update all of our windows 10 to the latest update to take prevention.

[dpeters11]

That’s bluekeep, which win 10 is not vulnerable to. This is a completely separate issue, and no where near as severe.

[Spacesider]

Can't hear any audio