TL;DR

This vulnerability allows attackers to impersonate Microsoft Support via the built-in remote support tool of Windows 10 named "Quick Assist".
Microsoft decided not to fix it since it needs high level of social engineering to exploit this vulnerability.

Quick Assist User Spoofing (Vuln/Feature)

As any researcher other would do, I started looking at the interesting features Microsoft added to Windows 10. As you may recall, last year i've found a quite simple vulnerability in Microsoft's Remote Assistance tool which allowed users to ask for assistance. You can read all about it. here.

So I stumbled upon "Quick Assist" I was wondering if it was just MSRA repackaged in a fancy name.
I fired up Burp Suite and let everything pass through the proxy and started looking at the HTTP requests coming in.
Once you startup "Quick Assist" it looks as follows:

You get 2 options, either provide assistance or request assistance.

An attacker/scammer would obviously like to "assist" another person. If we continue down that route you can see a bunch of HTTP requests going back and forth and you'll be finally asked to sign-in.

In order to be able to assist a person you'll have to sign-in/up with a microsoft account (@outlook.com,hotmail.com, live.com, ...), which can be created easily. Once you've logged in, Quick Assist will continue its HTTP requests (HINT: it's setting up an anonymous Skype Businness meeting room) and retrieve a security code which needs to be sent to the person/victim requiring assistance.

There are several ways to send this code as you can see above. Now here things get interesting, since a scammer would like to make the victim believe that he is genuinely someone from Microsoft providing support he can choose the option to send the code via email.
Interesting enough this mail is delivered without any information regarding the person who exactly is sending it. The sender of the mail is a legitimate Microsoft email address. Now this is the first step that makes the "victim" seem confident he/she is talking to a real Microsoft Support representative.

Above you can see the HTTP request, it's a JSON request with "destination" and "code" as the 2 parameters. (FUN FACT: you can put pretty much anything in the "code" parameter value)

The victim will get an email that looks something like the screenshot above.

Now we simply wait for the victim to put in the code and the victim will get a "waiting" screen.

The attacker/scammer's "Quick Assist" will wait for a reply from the "remoteassistance.support.services.microsoft.com" servers to initiate the next step of the process.
After some HTTP calls the attacker is prompted with the following window:

The attacker has the choice to either take full control of the remote computer or simply view the screen without controlling any input devices. In my opinion this is strange to give the "helper" (attacker/scammer) the option to choose what he wants to do with the "victim".

The attacker/scammer will (most) likely choose the first option and simply take control of the victim's machine.
Now we are reaching another interesting point within this whole process. After clicking on "continue" Quick Assist will perform some additional HTTP requests and one of them looks like this:

I'll give you a minute to look at the above request and figure out what's wrong here.





































































You've probably figured it out by now and noticed a very interesting parameter in this JSON request, namely "userInfo"
UserInfo contains some really interesting options:

  • Email
  • FirstName
  • LastName
  • IsMicrosoft
  • IsMicrosoftSupport
  • CompanyName

You're probably wondering what if you change these values? Well, that's what I did.
I've changed my FirstName, LastName, IsMicrosoft, IsMicrosoftSupport and CompanyName parameters.
Switching boolean flags from "false to "true" for "IsMicrosoft" and "IsMicrosoftSupport".
Below you'll see the comparison between not changing those flags and changing them.

As you can see above there is a slight difference in the prompt the "victim" receives. I'm sure you'll agree that the right one looks much more convincing (apart from the name "SupportMcSupportFace", which can be changed obviously!)

Once the "victim" clicks on "Allow" an screen sharing session is setup which is basically RDP over HTTPS using WebSockets.

There is also another parameter which I indicated in the previous screenshot which is "promptuser" which also takes a boolean flag and is by default set to "true" changing this to "false" simply bypasses the prompt message shown above and directly continues to setting up the screen sharing session.

Conclusion

After discovering this spoofing vulnerability/feature I've contacted MSRC and after almost 3 months, I've received the message they won't fix it since it requires high level of social engineering. Which I don't dispute by any means.
However knowing how prevalent tech support scams are these days and are making money off of innocent people not knowing what they are getting themselves into.

This technique could be used by these tech support scammers and is way more convincing since the victims don't have to install anything (unlike current scams where they force victims to install Teamviewer or other screen sharing tools) everything from receiving the "code" up until the last step of asking for "consent" looks completely legitimate.

I hope Microsoft will consider putting a little effort on mitigating this issue so their platform can't be used to scam people.

Timeline

  • April 15th 2019 (submission to MSRC Portal)
  • May 8th 2019 (Case opened & assigned)
  • June 4th 2019 (Case closed & Won't Fix)