about    blog     feed    archive

Playing in the Remote Sandbox: Adobe Flash Windows User Credentials Disclosure Vulnerability (CVE-2017-3085)

Aug 8, 2017

Recently, I posted a writeup on a Flash sandbox escape flaw that ultimately led to the demise of Flash Player’s decade-old local security sandbox. This post is a follow up.

Tracked as CVE-2016-4271, the former flaw highlights the importance of proper input validation. Feeding the Flash runtime a mixture of UNC and File URI schemes turned out sufficient to exfiltrate local data, and disclose Windows user credentials to a remote SMB server.

Flash Player 23 dropped the local-with-filesystem sandbox, effectively solving both issues from the local perspective. Interestingly though, the release notes quietly disregarded the two remaining sandboxes - local-with-networking and remote - leaving me to wonder whether these had been patched as well.

Indeed, initial tests show Flash rejects any UNC or File-style paths. By extension, neither sandbox seems to accept any non-HTTP URLs. Hence, this raises the obvious question of interest: what if we approach this issue the other way around? Can we change input expression meaning after having passed input validation?

In short, Adobe Flash can be rendered susceptible to a known Windows vulnerability. Albeit partially mitigated by a runtime security measure, the latter was designed for a different purpose, and can therefore be circumvented. These two facts combined turn out sufficient to workaround Flash Player’s new input validation, restoring an attacker’s ability to obtain Windows user credentials.

This post is a writeup on a flaw I recently reported to Adobe, acknowledged in APSB17-23, and assigned CVE-2017-3085.

HTTP: Can’t Redirect This

To reiterate, key to exploiting the previous flaw is having our malicious Flash application connect to our SMB server. By denying access without authentication, the server then triggers Windows clients to conveniently send their user credentials.

Adobe seems well aware of this attack vector. While previously Flash would load resources from any SMB server, version 23 rejects any UNC and File-style paths - two schemes used to reference SMB hosts. Example paths now being rejected include, respectively, \\10.0.0.1\some\file.txt and the equivalent file://///10.0.0.1/some/file.txt.

Unfortunately, taking Microsoft’s URI list for some creative URL generation does not yield any results. In neither sandbox, URLLoader appears to accept any paths not being prefixed by either HTTP or HTTPS. It seems Adobe has stepped up their game by switching to a whitelist approach.

Now, what if we could change the requested path after having passed input validation? Seeing as we are restricted to HTTP, this would translate to leveraging HTTP redirection for accessing SMB hosts.

Fortunately, SMB and HTTP are not an unlikely combination. Immediately coming to mind is a Windows vulnerability known as Redirect-to-SMB. By setting the HTTP Location header and an appropriate response code (e.g. 301, 302), this vulnerability can be used to redirect HTTP requests to a malicious SMB server. An attack can be executed as shown in the following screenshot:

rdr2smb_httpresponse Figure 1. Attacker redirecting victim to attacker’s SMB server

Susceptible, or is it?

In our attacker scenario, the malicious Flash application as well as SMB server are hosted on a machine having the IP address 23.100.122.2. This Flash application runs on the victim’s local machine in the remote sandbox. That is, the runtime prohibits local file system access but allows remote connections.

Tracing back to the Win32 API, the functions affected by Redirect-to-SMB reside in urlmon.dll. Hence, Internet Explorer and any third-party applications using them are vulnerable.

Having generated quite some media attention, the vulnerability triggered many vendors to patch up their products. So, what about Adobe Flash? Attempting to redirect an outbound GET /somefile.txt request gives:

rdr2smb_httpresponse Figure 2. URLLoader output when redirecting victim to SMB

Code #2032 is Flash terminology for Stream Error. From last time, we know anything but #2048 may indicate success. Let’s see what actually happens:

rdr2smb_httpresponse Figure 3. Wireshark trace for initial attempt

Alas, it seems Flash Player is not susceptible - our HTTP/1.1 302 response does not trigger SMB traffic. However, notice there is a GET request for crossdomain.xml. Dubbed the cross-domain policy file, it dictates when a Flash client is allowed to load resources from a different domain other than the originating one. For example, if not explicitly allowed by domain-b.com, the runtime will not load images from that domain if the Flash application is hosted on domain-a.com.

The careful reader might notice that Adobe’s definition, unlike HTTP CORS (referencing RFC6454), restricts itself to cross-domain data handling. More specifically, it does not take into account differing protocols. This security mechanism should therefore be unrelated to our blocked attack: we are trying to redirect to SMB, a different protocol, on the same host ;-).

Interestingly however, our Wireshark trace seemingly suggests otherwise: crossdomain.xml is being requested from the same host that serves our Flash application. Hence, we proceed by constructing a least-restrictive cross-domain policy. Taking the syntax from Adobe’s developer guide, we have:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<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>

Finally, we reload our Flash application and observe what happens:

rdr2smb_httpresponse Figure 4. Wireshark trace after consuming crossdomain.xml

Success! We have established an SMB connection from the victim’s machine (23.100.122.3) to our remote server (23.100.122.2). From here, we simply reiterate what we did last time. A Python script called SMBTrap operates as our malicious SMB server, and captures any incoming requests along with the victim’s user credentials:

smbtrap_output Figure 5. SMBTrap output

A word about affected environments

Interestingly, and in contrast to the previous flaw, Edge as well as Chrome (with Flash enabled) are unaffected. While otherwise showing similar behavior, including a cross-domain policy file request, both browsers appear to prevent Flash from connecting to SMB hosts.

That said, Firefox as well as Internet Explorer are vulnerable. This also applies to all current versions of Microsoft Office. In addition, the flaw affects both remote and local-with-networking sandboxes.

Conclusion

Having introduced new input validation measures, Flash Player 23 minimizes potential attack vectors by rejecting any outbound requests for non-HTTP URLs. Quite unexpectedly, however, input validation is only done once: while the initial HTTP request is validated, consecutive redirects are not. Combined with the fact Flash is still susceptible to a known Windows vulnerability therefore effectively kills a seemingly solid approach. This is unfortunate, and perhaps once again illustrates the underlying problem that platform-specific vulnerabilities need to be taken into account whenever possible.

Flash Player 26.0.0.151 fixes this issue, and can be downloaded through Windows Update and Adobe’s website.

Overview

Affected host environments
Firefox
Internet Explorer
Microsoft Office 2010, 2013 and 2016
Affected platforms
Flash Player 23.0.0.162 to 26.0.0.137
Windows XP, Vista, 7, 8.x and 10
Timeline
11-02-2017: Vulnerability reported to Trend Micro Zero Day Initiative.
21-04-2017: ZDI acknowledges the vulnerability and assigns it ZDI-17-634.
05-06-2017: Requested status update. Adobe replies Flash Player 26, to be released in July 2017, is being targeted to fix the vulnerability.
12-07-2017: Requested status update. Adobe replies it is still working on a fix, moving its expected release to August 2017.
08-08-2017: Adobe fixes the vulnerability in Flash Player 26.0.0.151.
08-08-2017: Vulnerability published.
Tags: vulnerability research  adobe flash  smb