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.