未加星标

Microsoft Edge RCE - (CVE-2018-8495)

字体大小 | |
[系统(windows) 所属分类 系统(windows) | 发布者 店小二04 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏
Microsoft Edge Remote Code Execution

(CVE-2018-8495) Chaining a few bugs in Edge I was able to achieve remote code execution by mainly abusing custom URI schemes.

Launching External Applications Many of you are probably aware that within the browser one can launch the default mail client by having a user go to a URL that looks like 'mailto:test@test.test' . A prompt will appear asking the user whether to switch applications, once a user agrees, the application will run.
Microsoft Edge RCE - (CVE-2018-8495)
In my case, Outlook is the default mail application and as you can see in the image below certain parameters are sent to the Outlook executable.
Microsoft Edge RCE - (CVE-2018-8495)
So there is user tainted string being passed as a parameter value, clearly something could go wrong here. But the question is - What other external-application-launching URI schemes are there? The Most Convenient Protocol When looking at the registry we can find all the registered custom protocols we can use. Within 'Computer\HKEY_CLASSES_ROOT\' we look for folders which contain 'shell\open\command' as sub folders. For example, I found that 'ms-word' has such sub folders.
Microsoft Edge RCE - (CVE-2018-8495)
So if we look at the values of 'Computer\HKEY_CLASSES_ROOT\ms-word\shell\open\command' we find 'C:\Program Files (x86)\Microsoft Office\Root\Office16\protocolhandler.exe "%1"' . This means if we have a user click on an anchor tag that points to 'ms-word:test' the following will occur:
Microsoft Edge RCE - (CVE-2018-8495)
I am too lazy to look at all the possible command line parameters we could throw at 'protocolhandler.exe' to achieve something useful. So let's take a look at a lower hanging fruit.
Microsoft Edge RCE - (CVE-2018-8495)
Well, this is very convenient! A URI scheme that passes user tainted arguments directly to 'WScript.exe' . In case you don't know: "windows Script Host provides an environment in which users can execute scripts in a variety of languages that use a variety of object models to perform tasks." Let's see what happens if a user navigates to 'wshfile:test' from Edge. First, we get a prompt asking to choose the default application that should handle this URI scheme. By default, as we've seen in the registry, 'Windows Script Host (WScript.exe)' is the handler.
Microsoft Edge RCE - (CVE-2018-8495)
Pressing 'OK' yields the following:
Microsoft Edge RCE - (CVE-2018-8495)
What 'WScript.exe' does is it attempts to execute the file located in the path you pass to it. In this case, it tried to locate 'C:\WINDOWS\system32\wshfile:test' but it does not exist. So what can we do about this? Can we somehow drop a file that's named 'wshfile:test' ? Nope. So what can we do? Exploitation The first test here is obvious: path traversal. I simply navigated to 'wshfile:test/../../foo.vbs' , pressed OK on the prompt and then:
Microsoft Edge RCE - (CVE-2018-8495)

Awesome! We can now point to any file in any directory and so long as we can drop a file in a predictable location, we will have RCE. But that is easier said than done, looked like most if not all cached files from Edge go into a salted directory location. In other words, we could plant files but we can't predict their location. This is where I remembered an awesome article written by Matt Nelson . In this article he points out that Windows comes with a signed VBS located in 'C:\Windows\System32\Printing_Admin_Scripts\en-US\pubprn.vbs' that suffers from 'WSH Injection'. I highly recommend you read it, it essentially shows that the specific VBS file accepts 2 arguments passed to it and these arguments can be crafted as such that it would trick the VBS script into executing arbitrary commands. But! This was fixed already and the only affected computers are the ones that haven't updated yet. So that's not good enough, the article mentions that many more such cases exist but did not specify, thus begins my search for a similar case.

I started by looking at every single VBS file I could find in Windows and then looking if it accepts any parameters. I found one located at

'C:\Windows\WinSxS\amd64_microsoft-windows-a..nagement-appvclient_31bf3856ad364e35_10.0.17134.48_none_c60426fea249fc02\SyncAppvPublishingServer.vbs'

This specific script takes in a few arguments and passes them into a powershell.exe shell execution without filtering it, allowing us to inject arbitrary commands. If you look at line 36 of 'SyncAppvPublishingServer.vbs' we see:

psCmd = "powershell.exe -NonInteractive -WindowStyle Hidden -ExecutionPolicy RemoteSigned -Command &{" & syncCmd & "}"

And we can influence the value of 'syncCmd' but not only that, Edge also does not sanitize quotation marks, so we can pass as many parameters to 'WScript.exe' as we want. Again, conveniently this powershell will run hidden as indicated by '-WindowStyle Hidden' which makes this a perfect WSH injection vector.

The problem in this version is that this specific folder name depends on what windows build the user is on. In my OS build 17134 the folder contains '10.0.17134' if you were on a different OS build it will be different. As far as the other things, there is little to no documentation of how they are determined. This is the only article I found about it with any useful information.

I made the argument in my report that all we needed was a stepping stone vulnerability in Edge that allowed us to detect local files (not read them), I was not able to find such a bug but hypothetically it can popup at any moment. On top of that, we don't have to guess the entire folder name char by char. In Windows folders come with a shorthand version called "DOS PATH" and so guessing the DOS path version of the folder location is more than possible.

Instead of trying to guess:

'C:\Windows\WinSxS\amd64_microsoft-windows-a..nagement-appvclient_31bf3856ad364e35_10.0.17134.48_none_c60426fea249fc02\SyncAppvPublishingServer.vbs'

We can guess:

'C:\Windows\WinSxS\AMD921~1.48_\SyncAppvPublishingServer.vbs'

So this makes my argument even stronger. Since both of these point to the exact same file.

But wait, what about that pesky prompt that appears? No user would be fooled into clicking 'OK' and run Windows Script Host! Thankfully when this prompt appears, the default focus is on the 'OK' button which means all the user has to do is hold down enter key and we can trick them into accepting the prompt.

Finally

The final proof of concept is as follows:

<a id="q" href='wshfile:test/../../WinSxS/AMD921~1.48_/SyncAppvPublishingServer.vbs" test test;calc;"'>test</a>
<script>
window.onkeydown=e=>{
window.onkeydown=z={};
q.click()
}
</script>

..and the a video of it in action:

This was my first time reporting through ZDI and I must say that it is a breath of fresh air. The fact that I did not have to deal with vendors directly was a big plus, as I could focus on other things.

References:

ZDI Advisory: https://www.zerodayinitiative.com/advisories/ZDI-18-1136/

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

tags: Windows,user
分页:12
转载请注明
本文标题:Microsoft Edge RCE - (CVE-2018-8495)
本站链接:https://www.codesec.net/view/604911.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(35)