Why the Apple UDID had to die
09 September 2011
EDIT: A WSJ Digits article is now up, containing a responses from Zynga and Chillingo. Other networks declined to comment.
A UDID is a "Unique Device Identifier" - you can think of it as a serial number burned permanently into every iPhone, iPad and iPod Touch. Any installed app can access the UDID without requiring the user's knowledge or consent. We know that UDIDs are very widely used - in a sample of 94 apps I tested, 74% silently sent the UDID to one or more servers on the Internet, often without encryption. This means that UDIDs are not secret values - if you use an Apple device regularly, it's certain that your UDID has found its way into scores of databases you're entirely unaware of. Developers often assume UDIDs are anonymous values, and routinely use them to aggregate detailed and sensitive user behavioural information. One example is Flurry, a mobile analytics firm used by 15% of apps I tested, which can monitor application startup, shutdown, scores achieved, and a host of other application-specific events, all linked to the user's UDID. I recently showed that it was possible to use OpenFeint, a large mobile social gaming network, to de-anonymize UDIDs, linking them to usernames, email addresses, GPS locations, and even Facebook profiles.
This post looks at the way UDIDs are used in the broader social gaming ecosystem. The work is based on a simple question: what happens if we swap our UDID for another while communicating with the network? There are a number of ways to do this - in my case I used mitmproxy, an intercepting HTTP/S proxy I developed which lets me re-write the traffic leaving a device on the fly. In most cases this was a simple matter of replacing one string with another, but two networks (Scoreloop and Crystal) prevented UDID substitution using cryptography. Unfortunately, both networks relied on the secrecy of key material distributed in the application binaries to every device. I have verified that it is possible to reverse engineer the application binaries to extract the key material and circumvent the cryptographic protection.
The outcome of this experiment shows that social gaming networks systematically misuse UDIDs, resulting in serious privacy breaches for their users. All the networks I tested allowed UDIDs to be linked to potentially identifying user information, ranging from usernames to email addresses, friends lists and private messages. Furthermore, 5 of the 7 networks allow an attacker to log in as a user using only their UDID, giving the attacker complete control of the user's account. Two networks had further problems that compromised a user's Facebook and Twitter accounts - Crystal lets an attacker take control of a user accounts by leaking API keys, while Scoreloop partially discloses users' friends lists, even if they are private.
| Data leaked | Log in as user | Social Media Accounts | |
|---|---|---|---|
| Crystal | Username, friends, Facebook, Twitter, games played, location, email address | Yes | Control of Facebook, Twitter accounts |
| GameLoft | Username, email address, games played, nationality, friends | Yes | No |
| Geocade | Username, email address, games played, location | Yes | No |
| OpenFeint | Username, last played game, online status, friends | Yes | No |
| Scoreloop | Email address, gender, username, nationality, friends | Yes | Access private Facebook and Twitter friends lists |
| Plus+ | Username | No | No |
| Zynga | First name, username, friends*, in-game messages*, mobile number* | Yes* | No |
* The starred Zynga findings rely on the fact that other networks can be used to obtain the user's email address using the UDID.
There are two caveats to keep in mind while considering these results. First, the findings are based on the default settings for each social network - some networks may have settings that reduce the amount of information exposed. Second, some of the data leaked is optional - for instance, it's not mandatory for a user to link Facebook or Twitter accounts with any of the networks.
All the affected companies and Apple were notified 5 weeks ago. The Crystal and Scoreloop teams have both repaired the problems that could lead to a follow-on compromise of a user's social network accounts. At the time of writing, it is still possible to log in as a user using only a UDID on five of the vulnerable networks.
The future
A few days after I notified the companies involved, it was revealed that Apple was quietly killing the UDID API. It will still be present in IOS5, but is marked deprecated, and will probably be removed in future. I recommend that developers shift away from using UDIDs now, rather than wait for formal removal of the API.
We can now expect a frenzy of activity as developers look for alternatives. The challenge will be to make sure that the cure isn't as bad as the disease - Apple's recommendation to "create a unique identifier specific to your app" could tempt developers to replicate the UDID mechanism on a smaller scale, flaws and all. Expect more blog posts on this topic soon.
Related:
- De-anonymizing Apple UDIDs with OpenFeint 04 May 2011
- How UDIDs are used: a survey 19 May 2011
- mitmproxy: Breaking Apple's Game Center with replay 31 Mar 2011
- UDID media roundup 10 Jun 2011
- Neighborhoods of trust on the web 27 Sep 2011
More posts:
- Malware 05 Jan 2012
- Visualizing entropy in binary files 04 Jan 2012
- Visualizing binaries with space-filling curves 23 Dec 2011
- mitmproxy 0.6 07 Aug 2011
- mitmproxy 0.5 27 Jun 2011
- subscount: Counting RSS feed subscribers 02 Apr 2011
- mitmproxy: A 30-second client playback example 31 Mar 2011
- mitmproxy 0.4 has been released 30 Mar 2011

