Have a quick read through the posts linked in the article this story points to. I show that using just a UDID, you could access the user's geolocation, games they played, private messages and friends lists on many of the affected social networks, and in some cases (which affected millions of users) completely take over Twitter and Facebook accounts. This is with _just_ a UDID. Some of the companies I notified a year ago are still vulnerable today. And remember, I only looked at social gaming networks - small slice of the app ecosystem. I know that there are similar systemic issues in many other places. So yes, this is definitely a catastrophe.

Unfortunately, there's just not much an ordinary user can do. There's no way for a user to tell if an app accesses and broadcasts their UDID (if you're an expert you can use mitmproxy or a similar tool), and certainly no way to tell if the UDID is being used safely. I would recommend de-linking your social media accounts from all apps unless you know they're safe, but that's the kind of drastic advice that people tend not to take.

UDID is a few years old is it not? It's surprising it took people this long to figure this out.

No more so than, say, a MAC address. The problem wasn't UDID, it's what people were doing with it.

You're the first I've heard say this. Would you mind passing a link along?

If they've deprecated the feature, are they doing anything instead to accomplish the same effect as the UDID?

Seeing as this is only 1 million sampled from a claimed 12 million list, that wouldn't be that useful since it's possible their UUID is just on the other part of the list.

> identify the traitor that did give your information to the FBI

Interesting use of the word "traitor" to mean "person who cooperates with the Government".

The device type is given in the leak

Indirectly it affects all of us.

Sorry, I don't think this strategy is workable. Consider - 74% of apps I tested sent the UDID to one or more upstream servers. Furthermore, Flurry alone received UDIDs from 15% of apps I tested. That's just one aggregator, and they surely have nearly 100% of UDIDs on file. The APNS tokens narrow it down somewhat, but not too much. It's also not at at all clear that there is a single source involved - this could be an amalgamation of a number of sources.

See this post for the source of these figures:

http://corte.si/posts/security/apple-udid-survey/index.html

They did mention the vulnerability they used

During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of "NCFTA_iOS_devices_intel.csv" turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.

Weev's AT&T adventure had nothing to do with UDIDs, and involved only about 100k records.

Push notifications don't use the UDID. They use a different token. UDIDs can be requested without user consent by applications, although that functionality is supposedly deprecated from iOS 5 onwards.

Yes, sorry - I'm on the road at the moment, and wrote that in a rush. Part of the problem is that there's not much users can do at this stage. The ecosystem of companies that use and abuse UDIDs is fragmented, and each service that relies on UDIDs for identification or authentication can have its own unique problems. I guess it would be possible to start aggressively releasing a list of services that users should close their accounts on, but that would also be a shopping list for bad guys out to take advantage of this situation.

No, you need a push token, which is a combination of device id and app id, and is only generated when the user authorizes the app for remote notifications. Additionally, you need a certificate on the server that is authorized to send messages to that app id.