Tag Archives: apple

Why I preferred Anonymous hacking the FBI laptop for those UDID

Today NoVA Blogger David Schuetz (@darthnull) was recognized for his hard work in uncovering the mystery of the UDID that Anonymous stated was pilfered from the FBI.  The fact that the FBI had these (or the threat) opened an interesting and heated discussion around the privacy and security channels.  The concerns were on privacy, rights of the users, and of course the weakness of the FBI security controls.  Interesting enough the FBI was direct and absolute that they did not have this data / it was breached.

@darthnull interviewed on NBC News discovered it was actually stolen from a small (relative to the FBI) organization in Florida called BlueToad.  This organization showed a 98% correlation in the datasets, and put out a press release stating the facts as they know them …

Please read all the details on this report, see the news story video, and additional links and resources.

This scenario is actually worse than if the FBI had the data.  In this situation we see a demonstration where a single small business recorded the UDID for their application.  These UDID are used throughout the App Universes (Apple and Google), despite the providers recommending to NOT use these.  The simple reason is these are essentially sensitive data – dare I say eventually PII.

The use of the UDID is even requested as a secure token for enterprise tools such as the GOOD email app messenger.  In fact, many tools, apps, games, and other smartphone platform applications utilize these UDID as the key identifier of the user.  The problem here is that if each App is collecting each UDID (even if done once and then switched to a better practice), that means there are A LOT of these databases lying around.

The quantity of such repositories of such UDID is large – marketing firms, analytics, games, productivity apps, enterprise MDM apps, etc…  It would be interesting to determine how many Apps are using these IDs, but ultimately it is irrelevant when we realize the breadth of these records across so many parties, at some point we just accept the data is retrievable.   The UDIDs are especially utilized across the mobile advertising & developer testing industry – as a means, for instance, of tracking marketing for instances, and within analytics (now part of a COPPA legal complaint).

The takeaway here is that enterprises should evaluate as part of their mobile strategy the authentication methods and dependencies deployed for these devices.  If the UDID is being utilized in a “multi-factor” / “token” method, it should be reconsidered or at least the risk mitigated given the simplicity and likely broad amount of existing databases with such records.  A positive note is that since March Apple has begun rejecting Apps that access these UDID, and a great write-up on the impact and effect can be found here at VentureBeat.  To be clear there will be alternatives in the future to UDID, but their unique nature and “assignment” to a person will not likely reduce the sensitivity of the “token”, as it will be employed similarly.

Congrats to David for solving the mystery and helping illuminate this poor security practice of app developers.


James DeLuccia

Download iCloud backups without the device, risk considerations

The ability to save data, sync information, and manipulate information online is extremely convenient and productive.  The risks that exist with this activity are fresh and emerging.  Unlike the physical-world risks that are impacted by kinetic attacks; weather impacts, and human events where the current state remains stable (i.e., the building doesn’t move addresses dynamically over night) the online Cloud-mobile device ecosystem does not.

This lack of state is an aspect that is both a feature that serves and cuts the enterprise.  The ability to provide updates without patches to the user is a key feature to cloud-mobile providers, and something in fact expected now of the end-users.   The virtual elimination of patching is upon us.

To highlight but a few alternate challenges that must be considered:

  • Configuration management – the onboarding of new applications and systems into an enterprise is done in a manner that ensures the system components themselves comply with the enterprise policy and industry operating standards.  This is challenged and new triggers and actions are required for cloud-mobile systems, as these may have new features (i.e., file transfer) automatically available to all users over night
  • Access and authorization – as the title implies (though such attacks are not limited to that of Apple) the technology deployed may permit alternative data access methods.  In the cloud-mobile ecosystem there is a presumption by the user that there is a physical link between the device (iphone / tablet) and possession implies such control / protection.  This is a fallacy of cloud-mobile, as possession of the device is not the key but instead the credentials associated to the stored repository of data.  Therefore the safeguards and information governance programs must focus on these assets (the credentials).
  • Geo-Location – Knowing where the data is processed & stored is critical, but not to a severity of knowing a zipcode.  Precise locations being shared introduce a security risk in general and do not serve the risk mitigation process.  Instead, gaining confirmation on regions of operation (i.e., so that weather can be considered in BCP), and the number of in parallel instances that will be running are important additions to consider with regard to these facilities.

So, as the “attack / forensic method” described in the title … one can w/ the authentication credentials of the user connect to iCloud and download a user’s total backup.  This may include contacts, documents, etc…  The tool is described here.

Again the point here is to begin considering operational and information security risk at the governance and sustainment level with respect to these mobile-cloud ecosystems.  Not focus on the single symptom of operating in this environment (having data d/led from iCloud).

Other thoughts?

James DeLuccia

/cp ITCC