Message-ID: <bafe8d7e-dc29-5def-629e-54be75376986@truel.it>
Date: Tue, 27 Sep 2016 17:39:44 +0200
From: TRUEL IT | Leone Pontorieri <leone.pontorieri@...el.it>
To: fulldisclosure@...lists.org
Subject: [FD] [Adobe Flash] local-with-filesystem sandbox bypass via
 navigateToURL() and UI redressing

[+]####################################################################################################
 |  
 | 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/

Powered by blists - more mailing lists