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