Android Vulnerability: Install App Without User Explicit Consent

This vulnerability allows an app to install any number of apps with any type of permissions without user’s explicit consent. It is based on two things:

  1. You can install an app from Google Play using just the browser, even from PC, take a look here.
  2. An app can embed a browser and automatically login into your Google account without any notification, using a few permissions.


One can build an Android app, let’s call it Trojan, that requires these permissions:

  • android.permission.INTERNET – Allows applications to open network sockets.
  • android.permission.GET_ACCOUNTS – Allows access to the list of accounts in the Accounts Service.
  • android.permission.USE_CREDENTIALS – Allows an application to request authtokens from the AccountManager.

from here.

These are the steps to reproduce it:

  1. Trojan app contains a WebView that will automatically login into user’s Google account by requesting authtokens from the Account Manager, user will not be notified nor have any way to stop this.
  2. The WebView will load the Google Play web site and inject JavaScript code on page load.
  3. The JavaScript code will make a request to get the device information and CSRF tokens, it will get information about all devices registered with that account. Remember the browser is logged in with user’s Google account.
  4. Using this information it can issue a request to install ANY app on Google Play, on EVERY device registered with that Google account. The user will not be prompted and will not have any way to stop this.


  • Trojan app could be full screen and the user will not even see the install notification.
  • Trojan app could choose to install the app on a different device, from the devices registered with the Google account, the user will not see anything unusual on the current device where the Trojan runs.
  • The installed app can have access to ALL permissions (if it specifies so in the manifest) without the user explicitly approving that, it could have access to services that cost you money, like sending SMS or making phone calls, manage accounts, disable your phone, just look at the permission list.
  • Since you have access to all Google data for that account, there are other scenarios, like accessing emails and more, but the PoC did not address those.

The fix

The Google fix, as far as I could tell,  was to not allow the browser to automatically login. Instead, the user will be prompted with a text that says it would allow the app to have access to all Google data. This however does not inform the user that it will allow automatic installation of any app, potentially causing direct and immediate loss of money.

I will not release the PoC, I think it would be too easy to cause real damage. However it is not that difficult to implement.

Vendor contact timeline

  • 2013-12-16 – Contact security(at)
  • 2013-12-17 – Received reply that the issues was passed to security(at)
  • 2013-12-20 – Received reply that they could not reproduce the issue.
  • 2013-12-20 – Sent a stripped down version of the PoC, not much different.
  • 2014-01-16 – Request status update.
  • 2014-01-24 – Received response that the rollout of the fix started last week.
  • 2014-02-12 – Received response that the fix is live for 100% users/devices.




#1 John Douglas on 03.19.14 at 4:49 am

Normally, when there is a request for authtokens from an application, the user gets presented a screen and has to agree to authorise the application to access the google credentials for a particular thing (e.g. weblogin:URI).

Is this screen not presented at all during the credentials request phase?

#2 Daniel on 03.20.14 at 12:31 am

Yes, that was the problem. I did not see that screen. The screen appeared after Google fixed it.

#3 John Douglas on 03.20.14 at 4:13 am

That is very interesting! Such attacks have been performed in the past and that screen was always there!
I now wonder how you did not get it, you must have done something very smart!
Since the fix is live for everyone, could you please share the relevant part of the code? (getting the authtoken and launching the webview).

#4 Daniel on 03.23.14 at 2:00 pm

“Always” is such a strong word 🙂
BTW, Elad Shapira pointed me to this original attack:
I will not make it public, however I shared the PoC with security researchers that requested it and will continue to do so.

Leave a Comment