Android Market Security

While I was in the middle of writing this post and a proof of concept this morning, Google seemed to fix a vulnerability I was going to talk about, so this post is no longer as interesting. I decided to post it anyway because some of the findings are still relevant.

A few days ago Google announced the Android Market website. This site allows users to browse for apps and when they click install it will remotely trigger the install on the user's phone without any further interaction. Vanja Svajcer from Sophos wrote a post about how it could open a back door for phone hackers. I thought this article was a little over-dramatic at first, since to do that they would need your Google Account password to login, and if they had your password then there is all manner of damage they could do anyway. It was risk versus convenience and I personally like the convenience and power to be able to easily deploy apps to my phone.

I decided I ought to take a closer look at how apps were deployed to my phone just in case, and I found a few interesting things:

  1. Any free app can be deployed to a phone by making 1 post request. The request doesn't need your Google password but must contain a couple of security tokens.
  2. All required tokens can be read by JavaScript and posted to an external site (think XSS). Update: While running my PoC it suddenly stopped working and it seems a change was made to prevent this which I will talk about below.
  3. The app name can be whatever you want to deploy, regardless of what permissions it needs.
  4. If you log out of the website, the post request with the old tokens still works in deploying apps.
  5. If you log out, change your Google Account password, the post request with the old tokens still works in deploying apps.
  6. I do not know if there is an expiry on the tokens, but after 3 days they are still working, meaning I have retained access to an account with no apparent way to revoke that access?

Post Request

The http post below, when filled with the correct values, will deploy an app (in this case a stopwatch app) to a phone:

SERVER: market.android.com:443

REQUEST:
POST /install HTTP/1.1
Host: market.android.com
Cookie: androidmarket=<310 char market token>
Content-Type: application/x-www-form-urlencoded
Content-Length: 107

id=com.android.stopwatch&device=<19 digit phone ID>&xhr=1&token=<41 char token>

Stealing the Tokens

Tokens can be read. Oh well, there goes a cool little demo. While I was refining the code, a cookie that held one of the tokens, androidmarket, seemed to change so as to include the httponly flag. This means it will only be transmitted by the browser when making a request, and can't be read by JavaScript in a XSS attack like regular cookies. I don't know if this was due to a misconfiguration, response to someone reporting it or something else.

Still, to see the other bits of data we were going to use you can manually trigger the following (while logged in to the Android Market of course):

javascript:alert(initProps['userEmail'] + ' | ' + initProps['token'] + ' | ' + initProps['selectedDeviceId']);

It should pop up a message box with your email address, security token and phone ID. Without the androidmarket authentication token stored in the cookie they aren't much good so an attacker will have to look at another way to get it.

Deploying Malware

If an attacker harvested all tokens they could deploy malware with full permissions en masse. Even when I changed my Google Account password I was still able to automatically deploy software days later with a script and the same tokens.

Since I can't test this on a large scale I do not know if Google have a mechanism to detect such shenanigans, it may be that they do. Certainly they seem to be keeping on top of things security wise.

I'm currently coming down with a cold so that's all for now :-)


Update: A couple of years after I wrote this, someone from Lookout told me they had disclosed some issues to Google just as I was working on the PoC, and that it was indeed patched while I was writing the article.