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.

Ryanair Insecurity

Economy airline Ryanair sees good security as "superfluous" according to a report by The H Security. Newspaper Der Tagesspiegel discovered that Ryanair's booking system gives a user three ways to verify their identity in order to modify their booking. One of those ways is by entering only three pieces of information:

  1. Date of flight
  2. Email address
  3. Origin and destination of flight

As Der Tagesspiegel points out, it is not hard to guess these details about someone you know based on their Facebook updates or simply asking them when they are going away.

Ryanair spokesman Daniel de Carvalho rejects concerns:

The experts consulted by the Tagesspiegel talking complete rubbish [sic]

He emphasised that it is each passenger's responsibility to keep their personal information secure. Umm...okay.

Most airlines have implemented this functionality properly, by using a unique piece of data only known by the airline and the passenger, such as a password or booking reference. And this is why they do that:

First of all, an email address is usually not considered secret, otherwise nobody would be able to email you. It may be on your business card, your website, your social networking profile and so on.

With regards to the other pieces of information, assuming the user does indeed keep them secure, how easy is it to guess them?

Let us start with the origin and destination of a flight. Each airport has a limited number of routes to other airports, so for example from Aberdeen you can only fly to Dublin, and from Dublin you can fly to 75 other airports. These routes are on the Ryanair web page in a JavaScript array called "Stations". Running the following Ruby command on the data told me how many permutations of origin and destination there are:

ruby -e 'n=0; File.readlines("stations.txt").each {|lines| n+= lines.scan(/"[A-Z]{3}"/).size-2}; puts n' 

The answer was 2488. If we knew someone's email address and were to write a script that programatically submitted requests to the Ryanair website at a relatively slow rate of 4 per second, it would take just over 10 minutes to check every flight permutation for a flight on a single date. To brute force every permutation against an email address for the whole of next month it would take just over 5 hours.

We haven't optimised it of course. Say you knew someone's email address, and knew they were based in the UK. It is a good bet they will be departing from an airport on the UK mainland. Running the Ruby command again for UK airports got it down to 394 permutations. Meaning you could scan next months flights for a target email address in about 49 minutes. Clearly it gets worse if the target lives in, say, Latvia, as the limited number of destinations means someone could scan the next six months worth of flights for a booking in about 10 minutes.

So, I think I will have to agree with the experts consulted by Der Tagesspiegel.

Update on Android Vulnerability

In many ways I concluded the Android Data Stealing advisory not long after I'd released it. The media interest and resulting debates achieved what I'd hoped, which was to warn users and put some focus on the issue of poor update frequencies for Android devices. A few interesting things have happened since the release, however, and I wanted to round them up into an update post.

  • Google released a patch for the specific exploit I created.
  • The patch won't be rolled out until some time after Android 2.3 as originally advised. Users may then have to wait for their device manufacturer and carrier to get the update to them. Some customers, such as those who own shiny new (and expensive) Sony Xperia X10 phones, won't ever be getting an official update.
  • Pulser, a developer from the group VillainROM who make custom Android ROMs, confirmed that the fix was ported into the Froyo Cyanogenmod sources. This means that many users of custom ROMs are already protected. Pulser/VillainROM were the only people to get in touch regarding the safety of their end users and how to protect them, kudos to them!
  • jduck contacted me about writing an exploit, and subsequently developed it into a Metasploit module. Read his great blog post about it.
  • Ludovic Courgnaud from CONIX Security developed an exploit for the vulnerability to demonstrate his XSSF module for Metasploit. He wrote a post about it (in French) along with an absolutely fantastic video demo. He really pushed the limits of what is possible with this simple vulnerability.

And that is pretty much it. For future reference I've listed below a small selection of articles or bulletins about it that I thought were worth saving:

SecurityFocus | Heise | Android Police | PC World | The Inquirer | The Register | Maximum PC | Der Standard | SoftPedia | Slashdot | Sophos | Lookout | Information Week

Android Data Stealing Vulnerability

While doing an application security assessment one evening I found a general vulnerability in Android which allows a malicious website to get the contents of any file stored on the SD card. It would also be possible to retrieve a limited range of other data and files stored on the phone using this vulnerability.

The vulnerability is present because of a combination of factors. I've been asked nicely to remove some details from the following section, and as my intention is to inform people about the risk, not about how to exploit users, I've agreed:

  • The Android browser doesn't prompt the user when downloading a file, for example payload.html, it automatically downloads to /sdcard/download/payload.html
  • It is possible, using JavaScript, to get this payload to automatically open, causing the browser to render the local file.
  • When opening an HTML file within this local context, the Android browser will run JavaScript without prompting the user.
  • While in this local context, the JavaScript is able to read the contents of files (and other data).

Then, once the JavaScript has the contents of a file it can post it back to the malicious website. This is a simple exploit involving JavaScript and redirects, meaning it should also work on multiple handsets and multiple Android versions without any effort.

One limiting factor of this exploit is that you have to know the name and path of the file you want to steal. However, a number of applications store data with consistent names on the SD card, and pictures taken on the camera are stored with a consistent naming convention too. It is also not a root exploit, meaning it runs within the Android sandbox and cannot grab all files on the system, only those on the SD card and a limited number of others.

A demonstration of the proof of concept exploit in action can be seen in the video embedded below. The demo uses the Android emulator with Android 2.2 (Froyo) and I have also successfully tested it on an HTC Desire with Android 2.2. In the demo I first create a file on the SD card of the Android device, then I visit the malicious page and it grabs the file and uploads it to the server automatically.

I notified the Android Security Team on 19-Nov-2010 and to their credit they responded within 20 minutes, took it seriously, and started an investigation into the issue. They have since updated me to say they are aiming for a fix to go into a Gingerbread maintenance release after Gingerbread (Android 2.3) becomes available. I have been advised that I can also mention an initial patch has already been developed, which is being evaluated.

Responsible disclosure would normally prevent me from publishing the advisory while there is a chance the users will get a fix in a reasonable time frame. However, despite the speed at which Google has worked to develop a patch I don't believe this can happen. The reason is that Android OS updates usually rely on OEMs and carriers to provide an update for their devices. Not all OEMs are providing Android OS updates to all of their devices, and the ones that are we have seen are not always doing it in a timely fashion. There may be legitimate reasons for this but the bottom line is there will still be a great deal of devices exposed for quite some time or perhaps forever, including my own.

Better that we know now and have the chance to protect ourselves, or at least understand the risk. I don't expect to see the exploitation of this issue become widespread, but if you are really worried about it there are a few things you can do to identify it or prevent it:

  • When the payload is downloaded it generates a notification in the notification area, so watch for any suspicious automatic downloads. It shouldn't happen completely silently.
  • You can disable JavaScript in the browser (uncheck "Settings > Enable JavaScript")
  • You can use a browser such as Opera Mobile for two reasons: 1) It prompts you before downloading the payload 2) If a vulnerability is found you can easily update a 3rd party browser after they release a fix.
  • Google have advised that another option is to unmount the SD card ("Settings > SD & phone storage"). This could have an impact on the usability of the device but for some situations, perhaps in organisations, I can see this could work. It has not been fully tested, however.

A word of caution though, you may prevent the automatic exploit this way, but as always you will still need to be vigilant and watch for other vectors, such as an HTML file sent through email.

For those of you who assess the security of products for use in a corporate environment, you'll know that this kind of advisory is essential in making accurate risk assessments and informed decisions before your business commits to a direction which will later leave it vulnerable. I do not mean to say Android is not a suitable platform for corporate use, like any mobile technology it entirely depends on the use case, compensating controls, risk appetite and so on. I hope this information helps you in the decisions you may be facing right now and goes some way to suggesting a suitable mitigation.


Update 1: I'd like to thank Heise Security for their help to independently validate the issue on a couple of their devices.

Update 2: Sophos understands the real issue here (that devices are not getting timely updates) and has written a good response to this post. To take a real example, Motorola has just announced that their Milestone XT720 will remain on Android 2.1 and not get an update, despite it only being a few months old. They have published a list of handsets with the updates they are getting, and the number of devices that are no longer going to receive official security patches is alarming.


This vulnerability was assigned CVE-2010-4804 and a Metasploit module was created. Original exploit code is now available on GitHub.