早前我写了一篇文章讲述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应用，继续不雅察看：