thomascannon.net Blog

Downloading APKs from Android Market

2011-06-13T10:14:35+01:00

Sometimes I need to get hold of an Android application from the Market for analysis. One way to do this is to manually use the Market on an Android device or emulator, install the App, and then copy it off. For various reasons this isn’t always ideal – I sometimes don’t want to install an App if I don’t know what it does, and I may want to get it a lot faster (i.e. automate it).

In this post I share what worked for me in creating a command line script to login to the Market and download the application’s APK. This isn’t anything particularly new as an unofficial Market API already exists for searching the Market and Tim Strazzere posted some Java source to emulate a download request. However, in Tim’s example you have to manually specify the App’s assetID and your authToken which means it isn’t automated. What I wanted was a script which takes a package name as a parameter and downloads it. To achieve this I used the Market API to login, get an authToken, search for the package, get its assetID, and then submit a download request.

I’ve documented this for interest, it isn’t supported software and there isn’t much error checking. If you use this it is assumed you know what you are doing.

What was used:

Linux with PHP including curl support
Rooted Android phone (I used a spare development phone)
Temporary GMail account associated with phone
PHP Android Market API by Splitfeed
ADB from the Android SDK

I’m using Ubuntu Linux and PHP with curl support. To install it you need something like this:

sudo apt-get install php5-curl

The first step is to get the Android Market userID which is required in the download request for APKs. I’m not aware of an easy way to get this at the moment but it is simple enough to sniff from the real Market App and only needs to be done once. Tim Strazzere comes to the rescue again with a nice tip for easily sniffing traffic on Android.

Open up the Market App on the device and find an app to install, start the following ADB command and then click install:

adb shell tcpdump -vv -s 0 -w /sdcard/output.cap

After install hit Ctrl+C to to stop sniffing. Open up the .cap file in something like wireshark and look for a GET request which contains the deviceID and userID parameters and make a note of them. I found that on my phone the GET request was different from the one in Tim’s post, it had extra parameters and when I manually emulated it I was given a 302 redirect to download the file. However, using the older GET request as per Tim’s post and ignoring the extra parameters seems to still work and leads to the direct download of the APK.

Download PHP Android Market API and unzip it somewhere. In the subfolder examples create a file called local.php with the following contents (replacing my values with yours):

<?php
define('GOOGLE_EMAIL','youremail@gmail.com');
define('GOOGLE_PASSWD','yourpassword');
// Use a random number with the same number of digits:
define('ANDROID_DEVICEID','0000000000000000');
// Use your real deviceID here that you sniffed:
define('ANDROID_REALID','0000000000000000000');
// Use your sniffed userID parameter here:
define('ANDROID_USERID','00000000000000000000');

I found that the Market API worked with a fake deviceID but not my real one, and the APK download request worked with my real deviceID but not the fake one. I didn’t look into it too much as it seems to work okay as above.

Download test_download.php.txt and save it in the examples folder as test_download.php.

Edit MarketSession.php in /Market so this line:

private $authSubToken = "";

Becomes:

public $authSubToken = "";

Okay that is the preparation. We can now use the script to grab any free app from the Market by passing the package name as a parameter. In this example I found a Notepad application on Android Market and saw the package name in the URL was bander.notepad, so:

user@linux:~/market-api/examples$ php test_download.php bander.notepad
* About to connect() to android.clients.google.com port 80 (#0)
*   Trying 74.125.71.139... * connected
* Connected to android.clients.google.com (74.125.71.139) port 80 (#0)
> POST /market/api/ApiRequest HTTP/1.1
User-Agent: Android-Market/2 (sapphire PLAT-RC33); gzip
Host: android.clients.google.com
Accept: */*
Cookie: ANDROID=DQAAAREDACTED
Content-Type: application/x-www-form-urlencoded
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Content-Length: 586

< HTTP/1.1 200 OK
< Content-Type: application/binary
< Date: Sun, 12 Jun 2011 23:34:37 GMT
< Expires: Sun, 12 Jun 2011 23:34:37 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Content-Length: 140
< Server: GSE
< 
* Connection #0 to host android.clients.google.com left intact
* Closing connection #0

Downloading Notepad (3073103588488610805)

user@linux:~/market-api/examples$ ls -hl *.apk
-rw-r--r-- 1 user user 45K 2011-06-13 00:34 bander.notepad.apk

And now we have the APK. The Market API is actually really good and it can also get other data about the app such as author, version, what permissions it needs, screenshots, etc. It would be a fairly trivial enhancement to get the script to save this extra metadata at the same time as the APK if needed.

Developments on Android Security and Forensics

2011-03-27T11:42:30+01:00

It has been a little while since I’ve had the chance to blog and a few things have been going on so I thought I’d sneak in an update.

While I was in the Caribbean, the annual Pwn2Own competition happened. There were several contestants lined up to exploit the Android device but in the end none of them stepped up. The first was security expert Jon Oberheide who I learned just before the competition had a working exploit, but unfortunately he informed Google who patched it before the event. Now that Jon has revealed details about how he almost won Pwn2Own everyone can see he was going to use a simple XSS in the Android Market! I discussed the same type of attack after my initial look at the Market security here and remember a lot of people dismissing it. Well, Jon actually went ahead and developed the attack, and it was a shame he didn’t get to show off the fantastic work he had done at Pwn2Own. Google were fast to rectify as usual and their site was combed over for a new XSS before the competition with no luck. They have really enhanced the security since the first time I looked. Still, the case remains that users are one XSS flaw away from having software installed and run on their device!

I haven’t published much new research recently in part because my free time has been spent developing the next version of an Android Forensics tool for a mobile forensics company. Due to NDAs and such I am not able to give details, but it is looking really good, and it is scary to see what data we can extract from Android phones!

Speaking of Android forensics, there is a new book coming out shortly by Andrew Hoog, CIO of viaForensics, about Android Security and Forensics. I’ve been lucky enough to get an early preview and it looks very good and very detailed, and the best resource on the subject I’ve seen to date. Some of my research is referenced a couple of times as well!

Android Lock Screen Bypass

2011-02-10T00:05:57+00:00

So far I have tried out 5 Android devices here in the UK (test device, personal phone, and those of friends). They all lack the same feature – if you forget your PIN or pattern code, there doesn’t seem to be a way to reset it. You are effectively locked out of your device. Searching online I see that some people are able to reset it after a certain number of attempts by entering their GMail credentials, but I am unable to do so on mine or others I have tried.

We now have the fantastic web based Android Market, and I wrote about a few minor security findings here. One of the common responses I saw to articles talking about the threat of malware distribution was that when remotely installed, an application doesn’t automatically run and the user would have to manually launch the malware. This is not actually correct, and to demonstrate I decided to create a legitimate utility which can be deployed to a locked phone, executed remotely, and set to disable the lock screen. This will yield access to a locked device so that the user may go in and backup their data.

How it works
Quite simple really. Android sends out a number of broadcast messages which an application can receive, such as SMS received or WiFi disconnected. An application has to register its receiver to receive broadcast messages and this can be done at run time, or for some messages, at install time. When a relevant message comes in it is sent to the application and if the application is not running it will be started automatically.

After testing out various broadcast messages the best one I found for the purpose of this utility was android.intent.action.PACKAGE_ADDED. This exists in all APIs since version 1 and is triggered when an application is installed. So to get the application to execute remotely, we first deploy it from the Android Market, then deploy any other application which will cause the first one to launch.

Once launched it is just a matter of calling the disableKeyguard() method in KeyguardManager. This is a legitimate API to enable applications to disable the screen lock when, say, an incoming phone call is detected. After finishing the call the app ought to enable the screen lock again, but we just keep it disabled.

Get the Screen Lock Bypass application: Android Market

Android Market Security

2011-02-05T10:25:50+00:00

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:

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.
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.
The app name can be whatever you want to deploy, regardless of what permissions it needs.
If you log out of the website, the post request with the old tokens still works in deploying apps.
If you log out, change your Google Account password, the post request with the old tokens still works in deploying apps.
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 :-)

Ryanair Insecurity

2011-02-02T00:05:54+00:00

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:

Date of flight
Email address
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 rejects concerns: “The experts consulted by the Tagesspiegel talking complete rubbish,” said Daniel de Carvalho, a spokesman for Ryanair

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

2011-01-25T23:32:36+00:00

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.

Android Data Stealing Vulnerability

2010-11-23T00:00:00+00:00

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.

View on Vimeo or download original.

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.

UK Cyber Security Challenge

2010-08-08T02:00:45+01:00

The UK Government recently launched a Cyber Security Challenge to help get interested and talented people into the industry. Their first challenge was quite easy and the results have now been released. The first step was a string of characters which was clearly base64 encoded. Decoding that gave a binary output and the header indicated it was a jpg. The jpg was an XKCD cartoon strip. Apparently many people thought this was the solution and submitted their answer. However, the border of the image contained a binary message which lead to another URL. At this URL was a string of hex characters and decoding this was the final challenge.

Unfortunately I heard about this several days after it went live and it was already solved (although the answers hadn’t been published yet.) I managed to decode the final message with only one line of Ruby which I thought was quite neat and wanted to share:

print File.read('cipher.txt').scan(/../).map { |pair| pair.reverse.hex.div(2).chr }.join

I had noticed the distribution of hex characters was far from random (indicating it wasn’t encrypted with an algorithm like AES or DES.) I started to solve it as a basic substitution cipher and after a couple of obvious characters and referring to an ASCII chart I noticed the pattern and came up with the code above.

It opens a file containing the cipher text, reading 2 characters at a time it flips the 2 characters, treating the 2 characters as a single hex byte it divides by 2 and then prints out the ASCII representation of each byte, revealing the secret message. All in one line of easy-to-understand code! On reflection it should have been just a circular bitshift of the data by 3 bits but I didn’t find an easy way to do that in one line of Ruby anyway.