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.

Thoughts?

James DeLuccia

Mind the Gap: When third party services are not enough to achieve security or compliance to PCI DSS

MasterCard published a very brief document outlining the very popular Use Case where a Merchant leverages a third party e-commerce system for processing transactions by redirecting to a separate hosted site.  The attraction is the obvious shift of the payment card environment to that of the hosted page provider.  This does help in reducing the PCI DSS scope, but as highlighted within the paper “…does not remove the need for a robust information security program.”

The brief highlights there is a risk to Merchants (“Based on the current compromise and attack trends”) where attackers may attack the Merchant’s web environment to redirect the traffic from the approved Hosted-Page vendor to a malicious party site.  This can be executed with a fake page where nothing but an error occurs, or the attackers can proxy (pass through) the traffic to the true Host-Page vendor.  This second approach allows the transaction to occur without any notice to the user of the attack.

The attack mitigation presented (follow best practices) are expected.  It does not say to solely or specifically to follow PCI DSS specifications, but instead to follow best practices appropriate for the web environment itself.

An additional attack mitigation stated is to establish SSL tunnels to fixed addresses and certificates.  This is definitely effective when securing the point to point connection, but generally would be ineffective from the attack described (as an attacker could simply compromise from the Merchant Host itself).

An alternative mitigation approach to consider would be expanding the monitoring & response capabilities.  As an example, if traffic is being redirected and the host Merchant server is compromised than the next best technique would be (among many) to have automatic triggers at the IPS, FW, and ACL points when these hosts are transmitting to unapproved targets.  This highlights the important need of when procuring services with valuable data, to have a deep process of onboarding the Service Provider in a manner that brings to light these technical details and establishes operational response capabilities jointly with the vendor.

The article is short and worth a read.  A key question that rang throughout the article was – does the issuance of this guidance make it clear that if the Use Case Attack happens than Y Merchant is deemed out of PCI DSS compliance?  The closing paragraph provides some light.  Would love others thoughts here too!

“While a merchant may be able to reduce or remove the scope of its environment’s applicability to comply with PCI DSS requirements by using hosted payment pages, it does not remove the merchant’s risk of being involved in, or even the source of, an account data compromise event.

Merchants still have a duty to employ security controls based on industry best practices to their web based environment to protect payment card data.”

Link directly to the guidance.

Best,

James DeLuccia