Early Tuesday, a file was released detailing the compromise of 1,000,001 records, supposedly from an FBI laptop. Reportedly, these represented only a small portion of a much larger breach – over 12 million records. It’s further claimed that the full breach includes personal information such as mailing addresses and telephone numbers, while the published data was limited to only a few specific fields.

That’s what we’ve been told. But what do we actually know?

We know that there are, indeed, 1,000,001 records. We know that they contain universal device IDs (UDIDs) for iPhones, iPads, and iPod Touches. We believe that they also contain valid device tokens (devtokens) for the Apple Push Notification Service (APNS). And that’s about it.

But that hasn’t stopped the Twitterverse from becoming all, ahem, a-twitter, about this breach. Some selected headlines and tweets:

But, amid the noise, some legitimate questions have been raised:

“What can malware hacker do with UDID? Any attacks yet using UDID?" “Wouldn’t having a device UDID + APNS token make it easier to silently ‘push’ malware/spyware to a phone?"

Let’s talk about some of these.

First, could the FBI have built this database? They couldn’t easily build it by eavesdropping: That much data simply isn’t passed in a conveniently concise fashion. It’d take a lot of work to pull together, and it’d be highly unlikely to end up on some agent’s laptop.

Could they have received it from Apple? While Apple would need a list of devtokens to route push messages to end users' devices, that list could be built on-the-fly as devices come online and connect to Apple. It probably wouldn’t need UDIDs, and certainly wouldn’t need all the other personal information allegedly contained in the breach. [Update: A statement from Apple says, in part, “The FBI has not requested this information from Apple, nor have we provided it to the FBI or any organization."]

So where could this data have come from? The logical answer is a 3rd party application server. For example, a cable TV carrier might have an iPhone app for their customers to view and pay bills. The back-end account database would then need mailing addresses and probably phone numbers. If they also push messages to customer’s devices (for example, to alert of an outage) then they’d need devtokens. A compromise of that kind of application (from a utility, bank, social media company, game company, publishing company, etc.) is a very plausible source of this leak.

What about the tracking question? Couldn’t this information be used to track people? Tracking genrally implies a time-based log of what people are doing, where they’ve been. And even from what the hackers have said, this database contains nothing of the sort. It’s simply a static association between a device, an APNS devtoken, and a mailing address (and similar information).

Okay, so the FBI is definitely NOT using this to track people. (Also, the FBI has officially denied it came from them.) But the UDID is, you know, ZOMG bad, right?

Right. Sort of. The UDID itself isn’t so bad, and is used internally by a bunch of Apple services (including the app store and Mobile Device Management). What makes it problematic is when other services use it to track user activity. For example, a game application might tell a 3rd party service whenever you start a level, when you finish it, how long you spent playing it, and whether you won. The big risk comes when this tracking information can be correlated across many applications, and many external services. Then it’s a huge privacy issue. For example, instead of a game, think of a newspaper app, and a 3rd party knowing which articles you read, and how long you spent on each one. And possibly sharing that information with other users of their system (that is, other application vendors).

This is why Apple has been working for over a year to get developers to stop using UDIDs altogether.

So what about the last questions? Can this be used to push malware to a phone, or do something else bad?

Not really. Push messages are short (under 256 bytes), and generally are just simple messages like “You have mail” or “It’s going to rain.” Mobile Device Management (MDM) servers can push out a message that says “Come to me for instructions,” and those instructions might be “Here, install this app,” but the device first has to be enrolled in MDM, and then the hacker has to forge the MDM message (and intercept the client’s response to then impersonate the server). Plus, even if this leaked database were from an MDM server, it still wouldn’t have enough information to forge an MDM message.

It could, in theory, be used to forge a message from whatever application the data was the source of the leak. But even that is exceptionally difficult. For one, you’d need the certificate used by the application’s push server (which might be in the hands of the original attacker, but certainly shouldn’t be available to anyone else who’s seen the UDID list). Plus, APNS uses fairly strong bi-directional certificate checks, so just impersonating the Apple APNS server is pretty difficult.

Too Long; Didn’t Read summary: After all that, what’s the bottom line?

  • This probably came from a 3rd party application vendor.
  • It probably didn’t come from an FBI laptop, unless (perhaps) it was there as part of an investigation into a breach at the aforementioned vendor.
  • There’s not much an attacker can do with this information directly, that is, targeting the users' devices.
  • However, wherever the UDIDs were improperly used by a 3rd party application, then it’s possible that some personal information / privacy concerns / account breaches may result from those uses.

What can you do about this? Really, not much at all. Complain to compaines which use UDIDs unsafely (if you’re even fortunate enough to know about it to begin with). But, as Aldo Cortesi has said, that’s a tough hill to climb. And as applications begin to filter out that require iOS 6, be sure to upgrade them, and hopefully that’ll slowly but surely kill the 3rd party use of UDIDs.

Also, hopefully the vendor who was the original source of this leak has realized what’s happened, and taken appropriate corrective actions (replacing their push certificates, etc.)

Finally, if you have a device that’s on this breached list, please contact me at david.schuetz at intrepidusgroup dot com. It’s possible that we can narrow down which applicaton was the source for the devtokens and, thus, the leak. I thought I’d managed to figure this out last night, but eventually decided I simply didn’t have enough solid information. Knowing clearly what the source of the leak is will give users the strongest ability to protect themselves against its effects.