Vulnerability Analysis and exploitation of Windows Media Center

Vulnerability Analysis and exploitation of Windows Media Center

Released by Microsoft in September 8 this yearMS15-100 Security noticeFixed the remote code execution vulnerability in a Windows Media Center. If Windows Media Center opens a specially designed Media Center link that references malicious code (. mcl) file, this vulnerability may allow remote code execution)

The MCL file format is XML-based. a mcl file can be as simple as this:

In addition to receiving a run parameter, the elements in the MCL file can also contain a url parameter, which means that the webpage URL can be loaded into the embedded browser (Internet Explorer) of the Windows Media Center.

In fact, we have at least two ways to use the MCL file to load arbitrary URLs in the embedded IE browser in the Windows Media Center. Let's look at my performances.

The MCL/HTML polyglot file itself can be read and leaked (MS15-134)

As I mentioned earlier, the url parameter in the MCL file element is a URL that will be displayed on the web page of the Windows Media Center. If we direct the URL to a Local HTML file, it will be loaded to the Local Machine Zone of the embedded IE. This Local Machine Zone is very subtle. All Local files are also the same! This means that the local HTML file can be read from your file system by running Javascript. (Note: This operation is only valid in IE, and the rules applied by other browsers are stricter)

This risk also allows Microsoft to release the Local Machine Zone Blocking Policy, which disables scripts running on Local HTML files. If the script contained in the local HTML file is loaded into the IE browser, the user will receive a prompt, which will prevent the script from running, unless the user clicks the "Allow to block content" button:

 

The Local Machine Zone blocking policy is enabled by default by IE browser, however, in other applications embedded with the IE browser engine, you must add the default security feature in the registry entry HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet.

Explorer \ MAIN \ FeatureControl \ FEATURE_LOCALMACHINE_LOCKDOWN. The problem is that Windows Media center does not have the default value of the Local Machine Zone Blocking Policy. The following is the default list of security features applied by embedded IE Engine Applications in Windows 7 SP1:

 

After understanding this problem, you can try to create a local HTML file containing Javascript code in the MCL file. You can see that the Windows Media Center automatically runs JS Code without any security prompts.

However, from the perspective of exploitation, we assume that we can trick users into clicking the MCL file we created. There is a problem: how can we put the HTML file referenced by the MCL file in a vulnerable User File System (so it will be loaded to the Local Machine Zone ), what files do we need to control?

In the Messing with binary formats document, we learned that polyglot is a file used to explain different valid file formats and is processed according to different programs. For example, it may be either a Windows Executable File or a valid PDF file. It depends on whether you are running it on Windows or importing it to a PDF reader.

We can use this feature of polyglot files to solve the above problem: Create a valid Windows Media Center MCL file and an HTML file. Because of the MCL format (based on XML) and HTML Markup languages, Our polyglot file is simpler. Although it is not as amazing as Ange artini said, it does bring us a lot of help!

We can easily createTags contain MCL files embedded with HTML + JS Code. When the javassw media center begins to parse the MCL file, this extra payload can be easily bypassed. If the url parameter of the MCL file points to itself, then an identical MCL file will be loaded as HTML content to the embedded IE in the Windows Media Center. The Web browser is named out of the loose HTML parsing, so the labels belonging to the MCL file are ignored. Then, our HTML + Javascript payload will run in the context of the embedded browser Local Machine Zone without any security prompt. Once our JS Code is successfully run, we can use XMLHttpRequest to read arbitrary files from your local file system and upload them to our remote server.

The vulnerability is named as a CVE-2015-6127 inMS15-100 Security noticeIs fixed. If you are interested, you can viewCore reports.

In the following conceptual verification, you can see that a MCL/HTML polyglot file steals files from the local file system and uploads them to 192.168.1.50. This is a test on Internet Explorer 11 in Windows 7 SP1 x64. Since the MCL file needs to be referenced by the url parameter, the MCL file name must match the url parameter:

Bypass Internet Explorer sandbox

When an mclfile includes a url In the tag, the submitted urlwill be rendered in the ehexthost.exe (embedded IE engine) process. Unlike i2.16e.exe, ehexthost.exe is a single-process application running on the Medium Integrity Level without sandbox protection. Therefore, Windows Media Centers can be abused to exploit the IE Component Vulnerability without worrying about the IE protection mode.

The following shows a typical Internet Explorer 11 Exploitation. If you want to escalate the permission and bypass the sandbox, You need to exploit the second vulnerability.

 

Use the url parameter of the MCL file in the Winodws Media Center to pass the same exploit to IE, and get the code execution in the Medium Integrity Level: