Thursday, February 12th, 2015

Visual Studio VSTFS protocol handler command injection

Last week, someone told me that my blog was on the “LovelyHorse” list. I’ve always thought that I was the only person who cared about this blog, but I guess there is a lonely analyst out there that also cares… lonely analyst, this one is for you :)

I reported an issue affecting Visual Studio 2012 (which I had installed on one of my dev machines at the time). The issue was a blast from the past and reminded me of simpler times when I had the privilege of doing vulnerability research with Nate McFeters and Rob Carter :). Microsoft has addressed the issue, but determined that this issue did not warrant a bulletin, so you’ll have download the Visual Studio 2012 update 4 if you want to “patch” this issue. I have not verified whether other versions of Visual Studio were/are affected. Tested on Win7 with IE10 and VS2012.

Visual Studio 2012 registers the “vstfs” protocol handler during the installation process. This protocol handler calls devenv.exe in the following manner:

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “%1″

As you know, protocol handlers can be instantiated remotely, most commonly via web pages. The “%1″ value can be attacker controlled and contains the values supplied when the attacker calls the protocol handler:

<iframe src=”vstfs:test“></iframe>

will result in the following being passed to the shell:

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “vstfs:test

Some time ago, I discovered that it was possible to escape out of double quotes when passing argument values to protocol handlers via Internet Explorer (and other browsers on Windows like Chrome). Sadly, this behavior is “by-design” and will not be fixed anytime soon. Knowing this, we can inject additional command line switches which will be passed to devenv.exe. If we know of suitable command line switch for devenv.exe we can repurpose devenv.exe and the vstfs protocol handler to do our bidding. For example, if we pass the following the Internet Explorer (copy/paste into the address bar or serve from a webpage):

vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe

We’ll end up with the following being passed to the remote system:

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe” /TfsLink “vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe”

The line above, launches devenv.exe and also shells an executable of our choice (with the ability to pass arbitrary command line arguments to that arbitrary executable).

Fortunately, modern browsers (with the exception of Safari… but who uses Safari on Windows?!?!) have warnings when launching protocol handlers. This means users will likely encounter two prompts from IE (protocol handler warning and an elevation warning), you can witness this if you copy/paste the vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe” string into the IE address bar (tested against IE10 with a system that has VS2012).

There might be a way to bounce this protocol handler off a whitelisted protocol handler (one that doesn’t cause a protocol handler warning) running at medium. Alternatively, we could pass this protocol handler to a remote user via an application that doesn’t have protocol handler warnings (like a chat application that supports URLs). If we can find such a case there will be no warnings to the user and we’ll have a zero click or one click remote command injection exploit against Visual Studio users.

Posted by xssniper | Filed in Security



Please leave a Comment