Major Android Vulnerability, 75% Android Users Are "Abandoned"

Privacy Disaster is a major vulnerability on Android native browser component on the versions below 4.4. It’s a critical vulnerability because it shaken the foundation of client side web security: the same origin policy. By exploiting this vulnerability, an attacker could bypass the SOP protection and steal sensitive informations such as cookies and login credentials.

Q: How could a hacker exploit it? What’s the consequence?

A: Your Android version must below 4.4 (which occupies more than 75% of market share). If you unfortunately opened a malicious webpage using Android’s native browser or apps’ webview component, the attacker could extract your cookie from another website, which may contain personal data or login credentials. Also, the attacker is able to embed another good webpage in the malicious page, say Paypal, and manipulate the page’s source code to log your username and password when you are logging in.

Those malicious behaviors should never work if the Same Origin Policy mechanism works properly.

Screen Shot 2014-09-22 at 1.27.28 AM

Q: What is Same Origin Policy (SOP)?

A: “Same origin” here means the same domain, same port and same protocol. We can assume 2 pages have same owner if they matches the “same origin”. SOP is a basic client side protection mechanism on almost all browsers: JavaScript from one origin should not be able to access the properties of a website on another origin.

For instance, you own a webpage, and embedded an iframe pointing to an email login page inside the page (in this case, email is the child page, and your page is parent page). Suppose you write some JavaScript in the parent page, can these code manipulate the source code of the child email page? The answer is certainly no, your JS cannot access the page elements – including page source and cookies – from another domain. Otherwise the hacking would be fairly easy, how about modifying some code to post your password to somewhere else? Or open an invisible iframe pointing to a social media website, and then retrieve the cookie from the parent page?

Unfortunately, the nightmares became the reality, as the SOP on Android browser could be bypassed by “Privacy Disaster” vulnerability.


Q: What caused this vulnerability?

A: At first glance of this vulnerably, my reaction is like other security researchers: unbelievable. It’s a so critical mistake in the code: it seems the developer passed a wrong URL variable into the URL security check, and rendered the check meaningless. Here are the 2 major fixes on the AOSP (Android Open Source Project): 1368e05e8875f00e8d2529fe6050d08b55ea4d87 7e4405a7a12750ee27325f065b9825c25b40598c

Q: How do I defend against it?

A: The best way is to upgrade your Android to 4.4, however it’s not doable for everyone. Moreover, the default browser cannot be uninstalled, neither can you evade the webviews that widely used among apps. It’s hard to patch or mitigate, that’s why we say 75% users are “abandoned”. The best suggestion we could give you is to be careful clicking an untrusted URL or installing a suspicious app. Nevertheless, even the URL points to a trusted source, it is possible that a network attacker hijacks the traffic and redirect your HTTP requests to a malicious source.

Trustlook is still working on the solution via 3rd party security softwares. We’ll keep you updated.

UI state inference attack – phishing 2.0

Activity hijacking is the mobile version of “phishing attack”. By poping a forged UI under certain circumstances, an attacker could hijack the user’s input flow and stole sensitive information, such as login credentials, payment informations and camera pictures.

Imagine those scenarios:

  • You opened a shopping app, finished purchase and clicked “checkout”. The app jumped to the payment UI. Then you input your credit card information.
  • You opened a email app. To add a new account, you clicked “login” and input your username and password.
  • You opened a banking app. To deposit a check, you clicked the scanning button and the camera presents. You took a photo of the check.

Those scenarios could all be exploited by an attacker. Researchers from UMich and UC Riverside have already proved they can successfully implement such attacks on all versions of Android system.

Here’s the PoC video:

The attack flow is:

      Victim installed and opened a malware.
      The malware launched a background service, monitoring the newly launched activity. E.g. by monitoring the logcat.
      The victim opened an target app. Launched a target activity. E.g. Opened a shopping app and jumped to the payment activity.
      The malware service immediately pops up a phishing activity, which looks totally the same as the original payment activity. The former one poped just on top of the later one.
      The victim mistakingly input the payment information on the fake activity, which will be later sent to the hacker.



Why this attack is tricky?

Hard to detect –
For the user, if the fake activity is deceptive enough, the victim can hardly identify it; For the Antivirus, popping up an activity is legit in Android. Antivirus is good at detecting a technically malicious behavior but not a social engineering deception. A better way of identifying the phishing activity is needed.

No special permission needed for the malware – except the Internet permission to send the data out.

We are working on update the Trustlook Antivirus to mitigate this attack. Our approach is, if any background service pops up an activity, we will warn you “the current UI is opened by [service name]”.