长话短说：由于Adobe产品中的漏洞和微软登录凭证的错误使用，导致恶意攻击者可以在微软旗下的signout.live.com域名中远程执行代码。
所谓远程代码执行漏洞，指的是用户可以通过浏览器提交代码指令，由于服务器端没有针对执行函数进行过滤，导致远程用户可以在没有指定绝对路径的情况下执行任意命令。这种漏洞往往会给服务器带来非常严重的影响，因为攻击者可以通过各种手段，从而在服务器端执行恶意代码。
根据国外媒体的最新报道，安全研究专家在微软旗下的signout.live.com域名中发现了一个远程代码执行漏洞。安全研究专家于2015年底将这一远程代码执行漏洞报告给了微软公司的安全应急响应中心，目前该漏洞已经得到了修复。根据安全专家的描述，由于网站的运行环境中存在错误配置，再加上向网站提供服务的Adobe体验管理系统（AEM）中存在另外一个安全漏洞，这些因素共同导致了这一远程代码执行漏洞的出现。
Adobe体验管理系统（AEM）概述
Adobe体验管理系统（AEM）是Adobe公司推出的一款企业级内容管理系统，目前该产品主要由Adobe公司负责维护。在此之前，AEM系统名为CQ，分别有CQ5和CQ6两大版本。该系统提供了一整套完整的网站内容管理系统解决方案，它可以算得上是一个企业级的重型系统了。该系统的核心组件运行在Java虚拟机（JVM）中，并配置了Apache HTTP server作为系统的可选模块，用户可利用这一模块来缓存网站内容，或者平衡网站负载。当然了，在国内几乎没有多少人了解这套系统。但是在很多其他的国家，这套系统几乎已经在所有的金融行业遍地开花了。
AEM的体系结构
在对AEM有了初步了解之后，我发现AEM与很多典型的企业级应用一样。首先，它采用了Java语言进行开发。其次，如果你想要彻底弄清楚它的体系架构并进行相应的开发工作，那将会是一件非常痛苦的事情。当你在安装这一系统的过程中你就会感到非常的头疼，因为AEM的快速安装包实际上就是一个好几百兆的JAR包，解压之后你将会得到大量的java源文件。
解压完成之后你就会发现，这种“代码仓库式”的AEM安装包其实是由大量的开源产品和Adobe提供的一些服务所组成的。AEM的服务组件并不是采用传统的方式来进行部署的，这些服务将会作为Apache Felix的内部组件来进行部署和实现。
Apache Felix是OSGi技术的一个开源框架，那么什么是OSGi技术呢？OSGi英文全名为Open Service Gateway Initiative，中文即为面向Java的动态模型系统。该技术实际上是Java动态化模块化系统的一系列规范。简单来说，OSGi可以认为是Java平台的模块层。OSGi服务平台主要面向Java提供服务，这些服务可以使Java成为软件集成和软件开发的首选环境。Java的可移植性使得同一产品能够跨平台部署。OSGi技术的诞生，使得应用程序可以使用精炼、可重用和可协作组件构建的标准化原语，开发人员能够将这些组件封装进一个应用并进行跨平台部署。
该系统最大的一个优势就是一款名为“OSGi bundle”的组件。开发人员无需重启OSGi框架或者底层的Java虚拟机，就能安装、重启、或者重新配置OSGi bundle。OSGi bundle可以包含经过编译后的Java代码，脚本，或者数据内容。开发人员可以根据需要来将这些内容加载到相应的仓库，或者对其进行配置。除此之外，这一架构还允许AEM通过部署和安装自定义的OSGi bundle来进行功能扩展。
CVE-2016-0957
CVE-2016-0957本身是一个非常简单的漏洞，该漏洞存在于AEM的调度模块中。由于AEM调度模块中的“glob”过滤器存在设计缺陷，直接导致了这个漏洞的存在。安全研究专家发现，该漏洞最终会导致“glob”过滤器强制返回非法请求的资源，而这类请求应该被拒绝。这种情况不仅会出现在请求资源的URL参数正好与“glob”过滤器参数相匹配的时候，而且任何符合要求的HTTP查询参数都有可能导致这类情况的发生。
该漏洞的利用方法也十分的简单。攻击者只需要在URL地址或者HTTP查询参数后面添加一个已知可访问的资源路径，就能利用这一漏洞了。
我们在下面给大家提供了一个绕过实例，假设配置与下方给出的类似：
－https://Dispatch.example.org/system/console
1. 根据规则“0001”，调度过滤器会拒绝该请求。
2. 无法匹配规则。
3. 访问被拒绝。
－https://Dispatch.example.org/system/console?.css
1. 根据规则“0001”，调度过滤器会拒绝该请求。
2. “.css”URL查询参数会强制“glob”过滤器引擎匹配规则“0041”。
3. 允许访问
漏洞影响
根据用户主机中安装的AEM版本和配置情况的不同，上述的这个漏洞还有可能导致一些其他的安全问题出现：
－/libs/opensocial/proxy
提供了一个代理，可以利用这个代理在服务器端执行任意请求。
－/etc/mobile/useragent-test.html
会导致旧版本的AEM（5.x）中出现跨站脚本（XSS）漏洞。
－/etc/reports/diskusage.html
能够允许他人在未经身份验证的情况下浏览代码库中的完整内容，这将有可能导致信息的泄漏。
有史以来最差劲的远程代码执行（RCE）漏洞
在对AEM和CVE-2016-0957有了大致的了解之后，在接下来的章节中，我们将准备给大家描述一下signout.live.com到底出了什么问题。由于AEM调度模块中的“glob”过滤器存在漏洞，再加上AEM Publish节点中存在错误配置，使得攻击者可以在signout.live.com网站中远程执行任意代码。
当时，安全研究人员发现signout.live.com网站上出现了微软Live服务的注销页面，在经过了简单的分析之后，便发现了这个远程代码执行漏洞。
当安全研究人员首次见到这个注销页面时，他们发现该页面的URL地址结构看上去有些可疑，该地址似乎是由AEM生成的。为了证实他们的猜测，安全人员对该页面<body>标签内的HTML代码进行了检查，并在其中发现了大量AEM组件。除此之外，页面内还嵌入了大量Javascript库文件，这也就意味着该页面肯定是由AEM生成的了。
在与Adobe公司的产品安全事件响应团队（PRIST）进行了沟通交流之后，我们便开始对网站进行更加深入地分析，以确定网站是否使用了默认配置的“glob”过滤器。我们通过AEM OSGi的控制台发送了一个带有.css后缀的HTTP查询请求：
https://signout.live.com/system/console?.css
虽然这一请求将会导致HTTP 401错误，但是如果在请求中去掉HTTP查询参数的话，服务器就能够响应并处理我们的请求了。我们的猜测也就得到了证实，我们的确可以利用上述的方法成功绕过AEM的调度过滤器。
漏洞报告
安全研究人员于2015年12月3日将有关该漏洞的详细信息报告给了微软公司的安全应急响应中心（MSRC），响应中心在二十四小时之内确认了这一漏洞，并分派了专职人员负责跟进这一漏洞。在与安全应急响应中心的技术人员进行了不断地沟通之后，该漏洞于2016年5月3日正式被修复。
不幸的是，MSRC在2016年5月4日确认，这个漏洞并不符合微软在线服务漏洞奖励计划的标准和要求，所以发现并报告该漏洞的安全专家也就无法获得漏洞奖金了。
也许，这就是生活!
文章原文链接:https://www.anquanke.com/post/id/84327
