Android browser cross-Origin data theft and Intent Scheme attacks

Android browser cross-Origin data theft and Intent Scheme attacks

The vulnerability we will introduce next affects self-built browsers and some other specific Android browsers in Android versions earlier than 4.4. It allows hackers to read cookie database files in sqlite format, to steal cookies. Next, let's talk about cross-site data theft attacks for Android versions earlier than 4.4.

2cto

Intent Scheme URL attack: This attack method uses the lack of browser protection measures to indirectly implement Intend-Based attacks through the browser as a bridge. Compared with General Intend-Based attacks, this method is extremely concealed, and because Malicious Code hides WebPage, traditional feature matching does not work at all. In addition, such attacks can directly access components (whether public or private) and private files (such as cookie files) of the browser, resulting in leakage of user confidential information.
Intent-based attack: This kind of intent-based Android attack method is very common. If it is light, it will lead to application crash, and the privilege escalation vulnerability may evolve.

Attack lab background

When I studied the transaction process standards of the Stock browser, I found that if I asked the browser to open a new tab and use the file: // protocol, I could open the local file through the web page. Of course, this is indeed not a loophole, But if it can read the local file and then send the file information to a remote, it is completely different. I also noticed that this is a killer vulnerability in the Android browser, and it is not limited to Chrome, Firefox, or Opera.

The following shows an error that occurs when you want to open a local file from the menu bar when the permission is disabled after the vulnerability is supplemented:

Attack lab plan:

 

To exploit this vulnerability, we simulate the following attack process:

Hacker will read local sensitive information files and send feedback to hackers

In order to construct an effective exp for this attack, after discussing with a Japanese security researcher Haru Sugiyama, he gave me the following POC:

http://133.242.134.241/firefox/test.html

When you access the preceding example Page through the Android browser, malicious scripts in specific operations will affect Firefox (the specific Android browser instance mentioned in the first section of this article) or the Android browser downloads malicious code to/sdcard/Download/exploit.html. The premise is that the sdcard directory does exist. The browser will open the malicious file exploit.html in the new folder, and then read the content from other local files. In fact, this attack process is not as easy as I said. Here we will make a comparison experiment to see the differences between attacks against Android 2.3.x and Android 4.1.x-4.3.

Android 2.3.x observation report

In this experiment, we used the Android 2.3simulator to easily read the contents of other local files through the malicious file exploit.html. This indicates that the browser of this version has a corresponding vulnerability that allows malicious websites to bypass the same-origin policy of the Android browser for cross-Origin data theft. However, because Android 2.3.x only accounts for 11.4% of Android users, and is slowly dying like winxp, the harm is not that great. The usage statistics of Android versions are as follows:

 

However, although Android 4.1.x-4.3 cannot directly read local files, after trying to bypass NULL bytes, we found that the effect was very good. The POC is as follows:

<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>

 

Unfortunately, according to the CVE-2014-6041, the vulnerability has been patched and tested to expire.

Attack Using Intent scheme URL

According to the above research, it is not feasible to read local files through Android 4.1.x-4.3, because in this series of versions, local files cannot read content from any other files. However, Joe Vennix from the metasploit team said that an attack can be easily initiated starting with intent scheme, and relevant articles are attached. The following is the POC in the article:
 

The idea of this attack POC is:

After the victim saves a cookie containing the malicious JS Code, when the browser opens the sqlite database file storing the cookie, the malicious JS code injected into the cookie is automatically executed, attackers can steal other cookies from database files. Based on this POC, hackers can try to read the entire webviewCookieChromium. db file.

<!doctype html>      
 
Joe implements a Metasploit module that can automatically steal cookies and report them to hackers. Even if the database file adopts httponly technology, this attack method is still very harmful.
Metasploit module implementation steps:
The following describes how to use this module to obtain cookies:
Step 1: Set the module

Step 2: Steal Cookies
After you finish this step, you can have a cup of coffee and wait for the fish to hook up.

Step 3: Waiting for cookies