Bypass UAC by using Remote Desktop to connect to localhost?

1

0

I can use Remote Desktop (RDP) to connect to computer B from computer A without typing my password, and vice versa, because I use the same account on these two computers. Further, in a remote desktop session I can click UAC prompt buttons on the remote computer.

What is stopping malware from bypassing UAC by using RDP to connect to a remote computer, then use it to RDP back (or just use RDP to connect to localhost) and then click the UAC yes button?

The malware could easily implement the RDP protocol itself or just start an RDP session and move my mouse cursor in the RDP session.

zzh1996

Posted 2018-03-20T18:09:31.363

Reputation: 111

First of, the malware has to be run, then it has to actually know a computer that it can RDP into, then it has to know how to RDP back. These situations are so unlikely to encounter, that the chances are slim to none that malware will utilize this. You cannot RDP to yourself so its more likely that there will not be a situation exploitable by generic malware to do this. – LPChip – 2018-03-20T18:36:27.833

Also, the only reason you can remote into another computer, is because you once entered your username and password, and hit save credentials, and when you RDP into a remote computer, the host is locked out, so a loopback as you suggested is not even possible. – LPChip – 2018-03-20T18:37:13.713

@LPChip It is possible to RDP to localhost on 1) Computers that support multiple simultaneous RDP sessions (e.g. Server editions), and 2) If the Restrict each user to a single session policy is set to "No". Even if that policy is set to Yes, it's still possible as long as you use a different user account, which would be feasible for a user with admin rights on the remote machine, as the OP obviously has since the remote UAC buttons are Yes/No. – I say Reinstate Monica – 2018-03-20T20:03:06.743

Answers

1

You're asking the wrong question

Remember that UAC helps protect against malicious code by giving a user with administrative rights the option to deny a (potentially malicious) process from starting execution on the local machine.

That said, in simple terms, your example scenario describes malware on a computer leveraging RDP to bypass UAC and launch an attack against the local computer. For this attack to work, the malware must already be running on the computer, rendering efforts to bypass UAC entirely pointless.

Therefore the correct question to ask is how the malicious process was able to bypass UAC on Computer A in the first place.

What about Computer B?

While not the direct query of your post, your scenario could work in an attack against Computer B. Allowing that Computer A is already compromised, it's possible a malicious program could start an RDP session and send mouse movements or keystrokes to Computer B, including those necessary to bypass UAC.

But neither is this a legitimate security vulnerability.

First off, the following is not default behavior in Windows:

I can use RDP (remote desktop) to connect to computer B from computer A without typing my password.

This is only possible if you have either:

  1. Saved credentials for the remote computer (which are then stored in Credentials Manager), or
  2. The Allow Delegating Default Credentials group policy has been configured.

Neither of these are present in a default configuration. I'll refer to both of these as having "saved your credentials."

Therefore, the RDP connection to Computer B by the malware is only possible if you've saved your credentials on Computer A. Since any code running in the context of your account on Computer A can access saved the credentials, the act of saving them is the equivalent of declaring, "I explicitly trust any current or future code executing in the context of my user account, including malware."

By saving Computer B's access credentials on Computer A, you disable the access control mechanism meant to control access to Computer B (from Computer A, at least). Code that leverages this fact isn't exploiting a OS-level vulnerability, but rather a user-created one.

I say Reinstate Monica

Posted 2018-03-20T18:09:31.363

Reputation: 21 477

You miss a point here. Nowadays, malware runs without admin privileges BECAUSE of UAC, and it tries to trick a user into getting admin permissions, but there is malware that never even uses admin rights and just is very limited in what it can do. These usually try to see what it has access to and collect data and send that to an offshore server. – LPChip – 2018-03-20T20:38:40.670

Seeing as the question is about bypassing UAC, how did I miss the point of malware that doesn't need admin rights in the first place? Or am I misunderstanding what point you say I missed? – I say Reinstate Monica – 2018-03-20T20:46:36.847

If I saved credentials of B on A, and credentials of A on B (I think this scenario is not rare for people who have two PC), then malware running on A without admin privilege can use RDP to make itself running as admin. Is this correct? – zzh1996 – 2018-03-20T20:52:32.277

You write: "For this attack to work, the malware must already be running on the computer, rendering efforts to bypass UAC entirely pointless." but malware can be running on the computer, by means of abusing an exploit of a browser, but is not running as admin and may try tricks to gain admin access which is what the question is about. – LPChip – 2018-03-20T20:52:53.507

@LPChip Ah, yes I understand now. So I don't explicitly frame it in those terms, but I cover that in second part of my answer. The attack you describe depends on the user saving their credentials, which indeed creates a "vulnerability", but it's still a user-created vulnerability. – I say Reinstate Monica – 2018-03-20T20:56:54.827

@zzh1996 In theory, that's correct. That's why it's important to understand that saving credentials = trusting code on your computer. – I say Reinstate Monica – 2018-03-20T20:58:29.050

Yup, basically. :) – LPChip – 2018-03-20T20:59:03.007

@LPChip Also, it's worth noting that an attack by an unprivileged process against the local machine wouldn't succeed in this manner because in that case the "remote" UAC prompt would demand an actual password to proceed. – I say Reinstate Monica – 2018-03-20T21:01:28.240

Not to mention that the user would actually see everything happen on screen and knows exactly what is going on and can simply stop it... :) – LPChip – 2018-03-20T21:07:24.203

I hadn't thought of that. Obviously there are a lot of specific variables required for this to have any traction. – I say Reinstate Monica – 2018-03-20T21:09:24.133