[+]####################################################################################################
|
| Title: Adobe Flash local-with-filesystem sandbox bypass via
navigateToURL() and UI redressing
| Author: Leone Pontorieri
| <leone [dot] pontorieri [at] truel [dot] it>
| https://www.truel.it
| Product: Adobe Flash
| <= 23 (before September 13, 2016)
| Changelog:
https://helpx.adobe.com/flash-player/release-note/fp_23_air_23_release_notes.html
| CVE: Requested
|
[+]####################################################################################################
[!] Full article with PoC and videos available @
http://lab.truel.it/flash-sandbox-bypass/
[+] 13 September 2016, Adobe kills the local-with-filesystem sandbox
Like a lot of love stories, the one between Flash and local files is
over. Local-with-filesystem sandbox has today, after a decade, been
killed by Adobe, making (almost) obsolete those Flash files using that
feature. Before we start explaining why on earth you should care about
this policy change and why this is a huge leap forward in Adobe Flash
Security, we need to explain what local-with-filesystem sandbox is and
how modern web browsers handle local files. If you’re an impatient guy
and want to go ahead to the PoC, you can go directly to the paragraph
“In Practice – Why it didn’t work”.
[+] What is local-with-filesystem sandbox and why on Earth should I care about
it?
If you had the pleasure of starting ActionScript programming and if
you’re not one of those developer that read only the odd pages of the
documentation, you should have heard about Adobe Flash Security
Sandboxes (luckily for me it was on page 53).
In simple terms, Security Sandboxes control which external resources can
be loaded by a SWF. The most famous one is the “Remote Security
Sandbox” whose task is to identify which files can be loaded by a Flash
file located on a remote host: you encountered it every time you loaded a
SWF via HTTP. Instead, when a flash file is loaded on file:// URI
scheme, SWF files are placed in one of the following Security Sandboxes:
local-with-filesystem, local-with-networking, local-trusted or the AIR
application sandbox.
The local-with-networking sandbox is the most common (and the default)
one: it forbids Flash files to load resources on the local filesystem.
This behaviour serves the security purpose to keep local files away from
remote hosts. In this way your romantic rivals won’t be able to steal
pictures of your girlfriend saved on your desktop, but even more
importantly it prevents bad guys, from access your private documents,
passwords, credit card information... and pictures of your girlfriend on
your desktop.
Similarly, the local-with-filesystem sandbox (which can be chosen when
compiling your ActionScript code), has been designed to keep remote
hosts away from local files, but it’s designed in the opposite way: the
SWF can access every file on the local filesystem but it can’t access
remote networks. Keep in mind that this feature can’t be enabled on
Javascript in any way – Javascript is “stuck” in a sandbox that is more
similar to local-with-networking.
Now it’s time to answer the question “Why on Earth should I care about
it?”: well, simply, this security approach didn’t work properly... and
it didn’t for a long time.
[+] In Theory – Why it should work but it doesn’t.
In theory, that security model was good. In practice, it was too hard to
deploy correctly. And that’s why Adobe chose to get (almost) rid of
that sandbox.
As previously said, SWFs in local-with-filesystem sandbox can’t
«communicate with the network in any way». In an HTML document, SWF is
surrounded by other technologies that aren’t bind to that principle:
just think about Javascript. The real issue behind every vulnerability
reported in this article is that it’s really difficult to make sure that
Javascript (which can communicate with remote networks) won’t be able
to read a single bit of what Flash is reading.
To sum up, when we are using file: URI scheme:
- Flash can access local filesystem
- Javascript can send data to remote hosts
It’s obvious that the only thing between the attacker and user’s local
files is the fact that Javascript can’t communicate with Flash in any
way. Flash tries to block every dangerous feature that may leak
information to Javascript, but it fails to do it correctly with
navigateToURL().
In the next paragraph we’ll talk about 3 different (but linked to each
other) issues, which can be exploited to extract data from local
filesystem. The first two take advantage of the web browsers RFC 3986
implementation (Uniform Resource Identifier: Generic Syntax) to pass a
malicious argument to navigateToURL() and extract data from local files.
The last one, designed to work on Google Chrome, shows how an old enemy
like Clickjacking can be used against Flash to exploit these
vulnerabilities in the wild, despite the mitigation.
[+] In Practice – Why it didn’t work
§ A) navigateToURL() – local sandbox bypass via URI percent-encoding
As previously said, navigateToURL() method can be used, even if the SWF
is in local-with-filesystem sandbox. Obviously, if we try to get files
on remote networks a security exception will be returned, but it can
surely be used to reach local files. Due to the fact that Javascript can
access information contained in the URL, navigateToURL() is the perfect
way to communicate data from Flash to Javascript (and then, remote
hosts). At the time of the discovery, Adobe Flash was performing a lot
of sanitizations on URIs (e.g to get rid of multiple slashes, changing
backslashes to forwardslashes, etc.) but it ignored percent-encoding.
Let’s see how it’s possible to abuse this behaviour:
Following RFC 3986, 2.1, this URI
navigateToURL(new URLRequest("file:///tmp/attack-this-sandbox.html"));
can be also requested as
navigateToURL(new URLRequest("file:///tmp/%61ttack%2Dthis-sandbox.html"));
Despite the fact that both of them are valid, they’re not the same
thing. Javascript in Mozilla Firefox and Safari can detect the
difference by simply reading document.URL. In this way, Flash is
communicating with Javascript: we can now bypass local-with-filesystem
sandbox and reach external networks. This concept is used in the
following PoC to steal a credit card number.
* Proof of Concept available on http://lab.truel.it/flash-sandbox-bypass *
§ B) navigateToURL() – Abusing whitespaces to bypass local sandbox
Similarly to the issue described in the previous paragraph, a little
known feature of local URIs on Windows systems is ignored by
navigateToURL(). This URI
navigateToURL(new URLRequest("file:///C:/attack-this-sandbox.html"));
Can be also requested as
navigateToURL(new
URLRequest("file:///C:/attack-this-sandbox.html%20%20%20"));
As you can see, there are spaces at the end of the URI, and even in this
case, its behaviour makes Flash able to exchange data with Javascript,
violating local-with-filesystem sandbox. In fact, Javascript can detect
the difference between the first and the second URI, giving Flash the
opportunity to pass a little amount of data per each navigateToURL()
call. In this case, the mitigation warning dialog that we’ve talked
about before seems to strongly limit the impact of this issue since we
need to perform multiple navigateToURL() calls to pass a similar amount
of data of the issue A). At a first glance, this vulnerability seems to
be unusable in a real world scenario.
In the next paragraph, we’re trying to discredit this last statement, in
order to prove once again how mitigations aren’t a good answer to
security holes.
§ C) Adobe Flash – Clickjacking against navigateToURL() warning dialog
Adobe Flash has been the favourite target of Clickjacking attacks since
the very first moment of the spread of that issue. Ironically, the same
kind of attack can be used against Adobe’s navigateToURL() issues
mitigation on Google Chrome. In the following link you can find an
Exploit PoC that uses the vulnerability in paragraph B) and the lack of
Clickjacking protection to extract credit card data in Google Chrome,
while the victim is playing a (really boring) Javascript game.
* Proof of Concept available on http://lab.truel.it/flash-sandbox-bypass *
[+] Is Adobe Flash still vulnerable? Is it fixed?
Yes but No. Flash has never fixed these issues and local-with-filesystem
sandbox can be optionally enabled, by editing a configuration file. So,
Flash still contains the vulnerable piece of code, but it can be
exploited only if an uncommon setting is enabled. In this way, these
vulnerabilities are “frozen” in the code and their fate is to be
reproduced in every future version of Adobe Flash, but it seems
unrealistic to use those again in a real world scenario.
At least, for now.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
