In a remote sandbox, free to soar: Adobe Flash Windows user credentials disclosure vulnerability-vulnerability warning-the black bar safety net

One, Foreword
Recently, I published about the Flash sandbox escape vulnerabilities of an article, The final result has survived ten years of the Flash Player local security sandbox died a natural death.
Before this vulnerability to show us the input data to verify the correctness of importance. The attacker only needs to run the Flash input mixing UNC and a file URI, it is sufficient to extract the local data, and can use Windows user credentials sent to the remote SMB Server.
Flash Player in the 23 version to remove the local file system local-with-filesystem）sandbox, from the local point of view, this treatment effectively solves these two problems. However, very interestingly, the official release notes are ignored in the remaining two sandboxes: local network local-with-networking）sandbox and remote（remote）sandbox. So I want to know which of two sandbox questions whether it has been repaired.
In fact, according to initial test results, the Flash will refuse any UNC or file path. Both the sand box seems to not accept any non-HTTP form of the URL. Therefore, this poses a very interesting question: if we are able to another way to bypass this limit? Whether we can through input validation, modify the input expressions have a meaning?
In short, Adobe Flash may be subjected to a known Windows vulnerability. Although we can by runtime security solutions to diminish the vulnerability can cause effects, but these security solutions was originally used for a different purpose, so it can be targeted to bypass. Therefore, we can bypass the Flash Player to the newly introduced input validation mechanisms that allow the attacker to recover access Windows user credentials the ability.
This article analyzes my recent to Adobe reports a security vulnerability, Adobe on the vulnerability of the number of APSB17-23, the corresponding CVE number for CVE-2017-3085。
Second, the HTTP redirect problem
Again to reiterate, before that exploit the key point is to our malicious Flash applications to connect to our SMB Server. Does the client authentication of the premise, by refusing the client’s access request, the server may enable a Windows client to send the user’s credential information.
Adobe seems to be very aware of this attack method. The previous version of Flash from all of the SMB on the server to load resources, but in the 23 edition, the Flash will refuse to remove any UNC as well as file form the path, the two path is SMB host representation. Now many of the paths will be the Flash refused to fall, such as\\10.0.0.1\some\file. txt path, and the equivalent file://///10.0.0.1/ some/file. txt path.
We can, however, according to Microsoft provide the URI list, to construct a variety of creative URL, but still can not get any breakthrough. In both the sandbox, regardless of which sandbox the URLLoader seems to not accept does not use HTTP or HTTPS as the prefix of those paths. Seems Adobe seems to use a whitelist mechanism to reinforce their products.
In this case, if we can get in through input validation, modify the request path, then what would happen? According to the previous analysis, we must use the HTTP form of the address, so we need to use the HTTP redirection feature to access a SMB host.
Fortunately, SMB and HTTP or can be combined together. The first thing that catches my mind is a Windows vulnerability, called to redirect to the SMB（Redirect-to-SMB）vulnerabilities. By setting the HTTP header in the Location information, and providing an appropriate response code such as 301 or 302 code, the attacker can use this vulnerability to redirect HTTP requests to a malicious SMB Server. Attack scenarios as shown below:
! [](/Article/UploadPic/2017-8/2017821172324214. png? www. myhack58. com)
Third, the vulnerability reproduction
In our attack scenario, the malicious Flash applications, and the SMB server are hosted on a single host, the host IP address of the 23. 100. 122. 2。 This Flash application will run in the victims of the local host to the remote（remote）sandbox. That is, the Flash runtime will block access to the local file system, but allows remote connections.
Tracking the Win32 API, we found that by Redirect-to-SMB vulnerability affects a function in with. dll. Therefore, Internet Explorer and any IE browser of third-party applications are affected by the vulnerability.
This vulnerability has attracted much media attention, many manufacturers released a fix patch to fix their products. Then, Adobe Flash performance? We can try to redirect an outbound request GET /somefile.txt the results are as follows:
! [](/Article/UploadPic/2017-8/2017821172324308. png? www. myhack58. com)
#2032 error code is the Flash used to represent the stream error Stream Error code. According to previous research results, we know that in addition to the#2048 code, the other code can be used to represent a successful status. We look at the actual appear what situation:
! [](/Article/UploadPic/2017-8/2017821172324561. png? www. myhack58. com)
Uh, looks like the Flash Player and is not subject to any influence: we returned HTTP/1.1 302 response does not trigger an SMB traffic. However, we note that 抓取的报文中出现一个GET报文请求crossdomain.xml the. This file is cross-domain policy configuration file, when the Flash client is allowed from another domain to load the resource when it will involve this file. For example, if not through domain-b. com clear license, then hosting on domain-a. com on the Flash application will not load domain-b. com on the picture.
The attentive reader may notice that the Adobe of the about defining with the HTTP CORS（readers can read RFC6454 learn more details of the different is, Adobe will be self-limiting in a cross-domain, cross-domain data processing. More specifically, Adobe will not go to consider the different protocols to distinguish the problem. Therefore, our attack is blocked it should be with such a security mechanism-independent: because we are trying to redirect to the SMB, which is on the same host to a different Protocol.
Interestingly, according to the Wireshark recording, 我们发现应用正在请求某台主机上的crossdomain.xml while this host it is running Flash applications in the same host. Therefore, we can construct a most permissive cross-domain policy. According to the Adobe Developer Guide syntax, we construct the policy as follows:
1
2
3
4
5
6
7

Finally, we re-loaded our Flash application, to observe the implementation:
! [](/Article/UploadPic/2017-8/2017821172324580. png? www. myhack58. com)
Success! We eventually established from the injured host 23.100.122.3 to our remote server 23.100.122.2 the SMB connection. At this point, we need only repeat what we do before working on it. We can use a named SMBTrap the script to assume our malicious SMB server role, is used to capture any incoming request, including the victim’s user credentials information:

[1] [2] next