Replay attack on Apple In-App Purchases

The Next Web reports of a flaw in the Apple In-App Purchase process which allows the re-use of In-App Purchase receipts. Using this flaw a hacker named Alexey V. Borodin has created an online service that allows people to receive In-App Purchase services without paying for them.

The normal process of authenticating In-App Purchases is as follows:

1. The client device sends a request to Apple to make the In-App Purchase
2. Apple charges the client user and returns a digitally signed receipt of the purchase to the client device
3. The client devices sends the receipt to the application server as a proof of purchase to receive the in-app service

The problem is that the digitally signed receipt is the same for all clients. So if one person makes a purchase and receives a receipt, that person can then distribute the receipt to others who can then get the In-App service without paying Apple. This is what Borodin did.

Now it's not as simple as that. The client device expects to receive the receipt from Apple - not from Borodin. The client device goes to a server with an Apple domain name and authenticates the server using TLS. So how could Borodin impersonate Apple?

The answer lies in the fact that DNS and TLS security in iOS (and in general) are intended to protect client users from a malicious third party - not to protect Apple from malicious clients. Because of this iOS allows the client user to override the DNS server and to add her own CA (Certificate Authority) certificates. So the client user can easily point the client device to Borodin's site instead of Apple's (by replacing the DNS server) and authenticate Borodin's site with Apple's name (using Borodin's CA certificate).

What Apple should have done is make the receipts unique, preferably by including a device unique identifier (such as the iOS UDID or a derivative thereof). If they deemed this problematic due to privacy (which it isn't) then they could had at least included a time stamp to limit the amount of time the receipt could be used or even just a cryptographic nonce [Wikipedia] which could be used by the application server to identify and prevent attempted re-use of an In-App Purchase receipt.

So why didn't Apple do this? My guess is that the Apple engineers who developed the In-App Purchase solution assumed that their connection to the Apple domain is protected (thanks to TLS) and didn't consider the fact that iOS allows users to add CA certificates. The Apple engineers who designed the certificate system which allows this were trying to protect the user from hackers - not to protect Apple from users. This is not the first time Apple have been hit by this mistake.

But even if it weren't possible for users to add CA certificates, using a fixed receipt for multiple devices is just bad security. If you have input on why Apple did this - please comment below.

Doctor, is it Siri-ous?

Last week the web was full of reports of a "security hole" in Siri, Apple's new voice control mechanism for the iPhone. ZDNet went so far as to headline "Siri not so serious about security".

So what's the "security hole"? The default iPhone configuration is such that Siri is active even when the iPhone is locked with a passcode. This means that a person with access to your supposedly secure locked iPhone can, for example, send emails from your phone using Siri. It's not difficult to understand the kind of attacks that this would allow someone impersonating you, not to mention the prank potential.

Who owns your identity? The UDID in iOS 5

As you may have read, Apple has removed from iOS 5 the API that allows applications to access the UDID (Unique Device IDentifier). The UDID is a non-modifiable unique ID given to each iOS device and is used by many applications to identify a specific device.

Why is Apple preventing application developers from accessing the UDID? Two possible security reasons for this are to protect user privacy and to protect the secrecy of the UDID.

User privacy: Though the UDID identifies the device and not the user, many applications have access to both the device UDID and the user's identity. Such applications could be used to create a mapping of users to UDID which could then be used to identify users using applications that don't have access to the User's ID. For example, let's say a user has both a Facebook app and a porn app on their iOS device. Assuming the porn app doesn't require the user to enter any personal identifier, the user can assume that the distributors of the porn app don't know his identity. But since the Facebook app has access to both the UDID and the user's Facebook account, it is possible (for Facebook) to generate a mapping of UDIDs to Facebook accounts and this could subsequently be used by the porn app distributor to identify users of the porn app.

UDID secrecy: There is reason to believe that some Apple applications use the UDID as a secret value. Apple cannot rely on other applications with access to the UDID to keep this value a secret.

A conspiracy theorist might think that in fact the reason Apple is doing this is to keep the UDID to itself. As TechCrunch notes:

If Apple does continue to use UDID for itself but denies it to developers that would be an “extremely lopsided change.” It would give Game Center and iAds yet one more advantage over competing third-party services.

In this case I'm voting with the conspiracists. If Apple wanted to protect the secrecy of the UDID or to protect user privacy they could have easily replaced the current UDID API with a new API that would still give the application developers a reliable unique identifier of the device but wouldn't compromise the secrecy of the UDID nor the privacy of iOS users. Specifically, Apple could have done this by replacing the UDID API with an API that returns a one-way function hash value of the UDID which is keyed using an application specific identifier (e.g. the App ID).

I'm sure the security engineers at Apple are smart enough to have thought of this. The fact that they didn't do so but simply removed the UDID API tells me that their goal was not to enhance security but to gain exclusivity on the device identity. Having such exclusive ownership of devices' identity gives Apple a great advantage in the development of identity-dependent applications including DRM.

Sometimes security is just an excuse for increasing control.