Android Browser Cross Scheme Data Exposure + Intent Scheme Attack

tl;dr This exploit is an issue present in Android browser < 4.4 and several other android browsers which allows an attacker to read sqlite cookie database file and hence exposing all cookies. Along with it we also talk about a Cross Scheme Data exposure attack in Android < 4.4.

Introduction

During my research on ASOP (Stock Browser) I found out that is is possible to open links to local files using file:// protocol by from a webpage by selecting "Open Link in New tab" from the context menu". This itself is does not represent a vulnerability unless there is a way to read local files and use be able to retrieve the files remotely. However, what caught my attention here is this by default is not permitted browsers such as Chrome, Firefox, Opera etc.

The following screenshot demonstrates the error which is obtained when trying to access a local file from context menu.

Attack Plan 

In order to exploit this issue, the following was the attack plan we came up with:

i) User visits Attacker.com.
ii) Attacker.com forces a download (exploit.html) on the victim's browser using content disposition header. The purpose of the exploit.html would be read local files and send it back to the attacker.
iii) The victim opens up a link by selecting "Open Link in New tab" which opens the local file exploit.html which was forced as download.
iv) Our file exploit.html would then be reading other local files and sending it back to the attacker.

In order to write an effective exploit for the attack, I coped up with Haru Sugiyama a Security researcher from Japan. He came up with the following POC:

http://133.242.134.241/firefox/test.html

Upon accessing the above page from android browser, it would first force the following file "exploit.html". Both FireFox and Android browser save files to '/sdcard/Download/exploit.html' in case sdcard is available. The exploit.html file would then try reading the other local files. However, this was not easy as it looked at first sight. Let's first talk about how the results from Android Gingerbread were different from Jellbeans.

Android Gingerbread:Observations

In case of Android Gingerbread Emulator build 2.3 we are easily able to read other local files, this represents a vulnerability as in the browser, as it effectively allows a website to perform cross domains data theft and hence violating the same-origin-policy. The impact however is not large as roughly 11.4% of the users now use Android Gingerbread and they are dying slowly just like windows xp.

Android JellyBeans: Observations

In case jellybeans we found out that a local file was not able to read a local files,  We then tried our old null byte trick and it worked like a charm.

The following is the POC:

<button onclick="exploit()">Read iframe</button>
<button onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')">Try \u0000</button>
<iframe src="file:/default.prop" name="test" style='width:100%;height:200'></iframe>
<script>
function exploit() {
  var iframe = document.getElementsByTagName('iframe')[0];
  try{
    alert("Try to read local file.");
    alert("contentWindow:"+iframe.contentWindow);
    alert("document:"+iframe.contentWindow.document);
    alert("body:"+iframe.contentWindow.document.body);
    alert("innerHTML:"+iframe.contentWindow.document.body.innerHTML);
  } catch(e) {
    alert(e);
  }
}
</script>

However, due to the discovery of CVE-2014-6041 the nullbytes issue was already patched and the above exploit did not work on patched devices.

Intent URL Scheme Attack

Based upon our above findings it was concluded that in Android Jellybeans the access to local files was not an issue due to the fact that a local file could not read other local files. However Joe Vennix from metasploit team came up with a more strong way to exploit it by abusing the intent scheme. The following paper -> http://www.mbsd.jp/Whitepaper/IntentScheme.pdf describes a potential way of exploiting this issue.  The following is the POC described in the paper:

The idea behind the attack vector is to saved a cookie containing javaScript code and trick the victim into opening the sqlite database file. Upon viewing the injected javascript would be executed in the context of a cookie file and would grab the rest of the cookies from the database file. Following is the basic POC, when when executed would read the entire webviewCookieChromium.db file.

<!doctype html>

      <html>

        <head><meta name="viewport" content="width=device-width, user-scalable=no" /></head>

        <body style='width:100%;font-size: 16px;'>

          <a href='file:///data/data/com.android.browser/databases/webviewCookiesChromium.db'>

            Redirecting... To continue, tap and hold here, then choose "Open in a new tab"

          </a>

          <script>

           document.cookie='x=<img src=x onerror=prompt(document.body.innerHTML)>';   

</script>

        </body>

      </html>

Joe has created a Metasploit module, which automates the process of stealing the cookies and sending it back to you , since the db file also contains httponly cookies as well this attack is quite dangerous.

Steps to Reproduce with Metasploit

The following screenshots would walk you through the process of exploiting and retrieving the cookies:

Step 1 - Setting up the Module

Step 2 - Stealing The Cookies

All you need to sit back and watch the cookies coming to you. 

Step 3 - Enjoy

Patch

The access to the data directory was tightened back in Feb 2014, however due to the android patch policies the patch did not make to most of the vendors. 

Credits

I would like to thank Tod Beardsley and Joe Vennix  from the metasploit team for their extensive support with analyzing and helping to co-ordinate with Google effectively. As well as Haru Sugiyama for his help and support.