thomascannon.net

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 :-)

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

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