CVE-2017-3085：Adobe Flash泄漏Windows用户凭证
早前我写了一篇文章讲述Flash沙盒逃逸漏洞最终导致Flash Player使用了十年之久的本地安全沙盒项目破产。从之前爆出的这个漏洞就可以看出输入验证的重要性，靠着Flash运行时混合UNC以及文件URI就足够提取本地数据，之后获取Windows用户凭证传输给远端SMB服务器。
Flash Player 23开始使用local-with-filesystem沙盒，有效的解决了本地存在的这两个问题。然而有趣的是在发行说明中却忽略了local-with-networking以及remote这两个沙盒，实在让我怀疑官方是否有用心在修补漏洞。
事实上，最初的测试显示Flash拒绝所有的UNC或者文件风格的路径，就连沙盒似乎都不接受非HTTP URL。反过来思考这个问题，是不是我们只要先通过了输入验证就可以随意修改输入表达式了？
本文所述漏洞已向Adobe报告(APSB17-23)，分配的CVE为CVE-2017-3085.
HTTP重定向
再次重申利用之前那个漏洞的关键，在于我们的恶意Flash应用能连接到SMB服务器。不经过身份验证直接让服务端拒绝我们的访问，之后服务端触发漏洞获得Windows用户凭证。
Adobe似乎有意识到这种攻击向量的存在。Flash之前的版本都可以从任意SMB服务端加载资源，23版本之后就开始拒绝所有的UNC及文件风格路径（两种用于引用SMB主机的方案），例如\10.0.0.1\some\file.txt以及file://///10.0.0.1/some/file.txt，两者等效且被拒绝访问。
不幸的是本想采用微软的URI列表来构造生成我们想要的URL，然而最终的结果让人不太满意。沙盒及URLLoader都不接受前缀非HTTP或者HTTPS的路径，似乎是Adobe通过切换到白名单方法来进行加强。
现在我们是否能在通过输入验证之后更改请求路径？虽然HTTP的使用被限制了，但我们可以转而利用HTTP的重定向去访问SMB主机。
HTTP与SMB的这个组合虽然不常见，但并非不能组合。根据这个思路，我立马联想到知名的Redirect-to-SMB漏洞。通过设置HTTP的Location头信息以及一个恰当的响应代码(例如301，302)，就可以利用该漏洞将HTTP请求重定向到一个恶意SMB服务器
漏洞利用
在我们的攻击场景中，恶意Flash应用以及SMB服务都运行在IP地址为23.100.122.2的机器上。该Flash应用运行在目标本地机器上的remote沙盒，也就是说运行时禁止本地文件系统访问，但允许远程连接。
追溯Win32 API发现受Redirect-to-SMB影响的函数驻留在urlmon.dll，因此使用该Flash的IE及其他第三方应用都是存在威胁的。
尝试重定向到一个出站请求GET /somefile.txt：
Code #2032是Flash对Stream Error的代号，此外#2048可能表明成功，使用Wireshark看看到底发生了什么：
我们的HTTP/1.1 302响应没有触发SMB通信，可是请注意这里有一个对crossdomain.xml的GET请求,被称为跨域策略文件，如果没有明确允许domain-b.com，托管在domain-a.com的Flash应用运行时就不会从该域加载资源。
细心的读者可能注意到Adobe的定义与HTTP CORS(参考RFC6454)不同，限制了其本身的跨域数据处理。具体来说它没有去考虑其他不同的协议，因此该安全机制与我们的攻击没有任何交集：我们尝试重定向到SMB，相同主机上的不同协议。
然而有趣的是，通过Wireshark获取的信息表明：crossdomain.xml请求的地址与我们Flash应用的地址相同。采用Adobe开发指南中的语法构造一个限制最小的跨域策略：
cross-domain-policy>
site-control permitted-cross-domain-policies="all"/>
allow-access-from domain="*" secure="false"/>
allow-http-request-headers-from domain="*" headers="*" secure="false"/>
cross-domain-policy>
重新加载Flash应用，继续观察：
成功建立目标机器(23.100.122.3)与我们的远程服务器(23.100.122.2)之间的SMB连接。至此我们便可以重复之前的操作。使用一个Python脚本调用SMBTrap对恶意SMB服务器进行操作，之后通过传入的请求捕获目标的用户凭证：
总结
有趣的是与之前的漏洞相比较，这次Edge与Chrome（开启Flash）都不受影响，似乎这两个浏览器都对Flash连接SMB主机已经有了防护机制。Firefox及Internet Explorer受该漏洞影响，当前版本的Microsoft Office同样适用。除此之外，该漏洞还影响到remote 和 local-with-networking两个沙盒。
Flash Player 26.0.0.151已修复该漏洞，用户可通过Windows Update以及Adobe官网进行下载更新。
附录
受影响主机环境
Firefox
Internet Explorer
Microsoft Office 2010, 2013 and 2016
受影响平台
Flash Player 23.0.0.162 to 26.0.0.137
Windows XP, Vista, 7, 8.x and 10
早前我写了一篇文章讲述Flash沙盒逃逸漏洞最终导致Flash Player使用了十年之久的本地安全沙盒项目破产。从之前爆出的这个漏洞就可以看出输入验证的重要性，靠着Flash运行时混合UNC以及文件URI就足够提取本地数据，之后获取Windows用户凭证传输给远端SMB服务器。
Flash Player 23开始使用local-with-filesystem沙盒，有效的解决了本地存在的这两个问题。然而有趣的是在发行说明中却忽略了local-with-networking以及remote这两个沙盒，实在让我怀疑官方是否有用心在修补漏洞。
事实上，最初的测试显示Flash拒绝所有的UNC或者文件风格的路径，就连沙盒似乎都不接受非HTTP URL。反过来思考这个问题，是不是我们只要先通过了输入验证就可以随意修改输入表达式了？
本文所述漏洞已向Adobe报告(APSB17-23)，分配的CVE为CVE-2017-3085.
HTTP重定向
再次重申利用之前那个漏洞的关键，在于我们的恶意Flash应用能连接到SMB服务器。不经过身份验证直接让服务端拒绝我们的访问，之后服务端触发漏洞获得Windows用户凭证。
Adobe似乎有意识到这种攻击向量的存在。Flash之前的版本都可以从任意SMB服务端加载资源，23版本之后就开始拒绝所有的UNC及文件风格路径（两种用于引用SMB主机的方案），例如\10.0.0.1\some\file.txt以及file://///10.0.0.1/some/file.txt，两者等效且被拒绝访问。 本文来自无奈人生安全网
不幸的是本想采用微软的URI列表来构造生成我们想要的URL，然而最终的结果让人不太满意。沙盒及URLLoader都不接受前缀非HTTP或者HTTPS的路径，似乎是Adobe通过切换到白名单方法来进行加强。
现在我们是否能在通过输入验证之后更改请求路径？虽然HTTP的使用被限制了，但我们可以转而利用HTTP的重定向去访问SMB主机。
HTTP与SMB的这个组合虽然不常见，但并非不能组合。根据这个思路，我立马联想到知名的Redirect-to-SMB漏洞。通过设置HTTP的Location头信息以及一个恰当的响应代码(例如301，302)，就可以利用该漏洞将HTTP请求重定向到一个恶意SMB服务器
漏洞利用
在我们的攻击场景中，恶意Flash应用以及SMB服务都运行在IP地址为23.100.122.2的机器上。该Flash应用运行在目标本地机器上的remote沙盒，也就是说运行时禁止本地文件系统访问，但允许远程连接。
追溯Win32 API发现受Redirect-to-SMB影响的函数驻留在urlmon.dll，因此使用该Flash的IE及其他第三方应用都是存在威胁的。
尝试重定向到一个出站请求GET /somefile.txt： www.wnhack.com
Code #2032是Flash对Stream Error的代号，此外#2048可能表明成功，使用Wireshark看看到底发生了什么：
我们的HTTP/1.1 302响应没有触发SMB通信，可是请注意这里有一个对crossdomain.xml的GET请求,被称为跨域策略文件，如果没有明确允许domain-b.com，托管在domain-a.com的Flash应用运行时就不会从该域加载资源。
细心的读者可能注意到Adobe的定义与HTTP CORS(参考RFC6454)不同，限制了其本身的跨域数据处理。具体来说它没有去考虑其他不同的协议，因此该安全机制与我们的攻击没有任何交集：我们尝试重定向到SMB，相同主机上的不同协议。
然而有趣的是，通过Wireshark获取的信息表明：crossdomain.xml请求的地址与我们Flash应用的地址相同。采用Adobe开发指南中的语法构造一个限制最小的跨域策略： copyright 无奈人生
cross-domain-policy>
site-control permitted-cross-domain-policies="all"/>
allow-access-from domain="*" secure="false"/>
allow-http-request-headers-from domain="*" headers="*" secure="false"/>
cross-domain-policy>
重新加载Flash应用，继续观察：
成功建立目标机器(23.100.122.3)与我们的远程服务器(23.100.122.2)之间的SMB连接。至此我们便可以重复之前的操作。使用一个Python脚本调用SMBTrap对恶意SMB服务器进行操作，之后通过传入的请求捕获目标的用户凭证：
总结
有趣的是与之前的漏洞相比较，这次Edge与Chrome（开启Flash）都不受影响，似乎这两个浏览器都对Flash连接SMB主机已经有了防护机制。Firefox及Internet Explorer受该漏洞影响，当前版本的Microsoft Office同样适用。除此之外，该漏洞还影响到remote 和 local-with-networking两个沙盒。
copyright 无奈人生
Flash Player 26.0.0.151已修复该漏洞，用户可通过Windows Update以及Adobe官网进行下载更新。
附录
受影响主机环境
Firefox
Internet Explorer
Microsoft Office 2010, 2013 and 2016
受影响平台
Flash Player 23.0.0.162 to 26.0.0.137
Windows XP, Vista, 7, 8.x and 10
www.wnhack.com