Playing in the Remote Sandbox: Adobe Flash Windows User Credentials Disclosure Vulnerability (CVE-2017-3085)
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 -
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.
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
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:
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
18.104.22.168. 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:
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:
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:
Finally, we reload our Flash application and observe what happens:
Success! We have established an SMB connection from the victim’s machine (22.214.171.124) to our remote server (126.96.36.199). 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:
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
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 188.8.131.52 fixes this issue, and can be downloaded through Windows Update and Adobe’s website.
Affected host environments
Firefox Internet Explorer Microsoft Office 2010, 2013 and 2016
Flash Player 184.108.40.206 to 220.127.116.11 Windows XP, Vista, 7, 8.x and 10
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 18.104.22.168. 08-08-2017: Vulnerability published.
- Adobe Security Bulletin APSB17-23
- Threatpost - Patched Flash Player Sandbox Escape Leaked Windows Credentials
- SC Magazine UK - Recently patched Flash Player sandbox leaks Windows credentials
- BleepingComputer - Recently Patched Flash Bug Can Leak Windows Credentials
- WCCFtech - Adobe Addresses Several Vulnerabilities in Flash Player, Acrobat, and Reader
- Security.NL (Dutch) - Radboud-student ontdekt opnieuw lek in Adobe Flash Player
- ZDNet (German) - Flash-Lücke erlaubt Diebstahl von Windows-Anmeldedaten
- SecNews (Greek) - Flash Player μετά την ενημέρωση: ευπάθεια και πάλι
- SecurityTracker - Adobe Flash Player Bugs Let Remote Users Obtain Potentially Sensitive Information and Execute Arbitrary Code