Apple to block in-app purchase hack in iOS 6, offers interim fix

Update on July 23 - Hacker on Apple's iOS in-app purchase fix: 'Game is over'

Last week Russian developer Alexey Borodin hacked Apple's In-App Purchase program for all devices running iOS 3.0 or later, allowing iPhone, iPad, and iPod touch users to circumvent the payment process and essentially steal in-app content. Apple confirmed the workaround and said it was investigating the issue. This week, Cupertino tried to block the hack but failed. Now the company is finally outlining a proper solution, albeit temporary, as it also revealed that iOS 6 will finally and completely block this hack.

In a document titled "In-App Purchase Receipt Validation on iOS" on iOS Developer Library, Apple finally outlines the problem, and promises to fix it:

A vulnerability has been discovered in iOS 5.1 and earlier related to validating in-app purchase receipts by connecting to the App Store server directly from an iOS device. An attacker can alter the DNS table to redirect these requests to a server controlled by the attacker. Using a certificate authority controlled by the attacker and installed on the device by the user, the attacker can issue a SSL certificate that fraudulently identifies the attacker’s server as an App Store server. When this fraudulent server is asked to validate an invalid receipt, it responds as if the receipt were valid.

iOS 6 will address this vulnerability. If your app follows the best practices described below then it is not affected by this attack.

Wait a minute Emil, you told us previously to use store receipts and then found out this method does not work. What gives? Well, Apple this week quietly started including unique identifiers in the validation receipts for in-app purchases (developers have started seeing new receipts which include a field called "unique_identifer").

Now that you know, here are the official details from Apple:

My app performs validation by connecting to my own server. How am I affected?

If your app follows best practices and performs receipt validation by sending the receipt to your server and having your server perform the validation with the App Store server, your app is not affected by this attack because it does not connect to the App Store server. However, it may be vulnerable to similar attacks when connecting to your server.

Use the appropriate cryptographic techniques to ensure that your app is actually connected to your server, and that your server is actually connected to the App Store server. You can use the mitigation strategy outlined in this document as a starting point. For more information, see Security Overview.

My app performs validation by connecting to the App Store server directly. How am I affected?

The best practice for validating receipts is to send the receipt to your server, and have your server perform the validation with the App Store server.

If your app connects to the App Store server directly from the device, your app may be affected by this vulnerability. You can address this vulnerability as follows:

• Check that the SSL certificate used to connect to the App Store server is an EV certificate.
• Check that the information returned from validation matches the information in the SKPayment object.
• Check that the receipt has a valid signature.
• Check that new transactions have a unique transaction ID.

How can I validate transactions that have already completed?

Consumables If you have saved the receipts, either on the device or on your server, revalidate the receipts after implementing your mitigation strategy. If you have not saved the receipts, you cannot validate these past transactions; you should not take any action.

Nonconsumables Set aside the current receipts, perform a restore operation, and validate the new receipts. Avoid redownloading content that is already on the device during this process.

The worst part about this hack is that iOS developers had no way of protecting their apps. Using store receipts didn't work as Borodin's service simply needed a single donated receipt, which it could then use to authenticate anyone's purchase requests. His circumvention technique relied on installing certificates (for a fake in-app purchase server and a custom DNS server), changing DNS settings to allow the authentication of "purchases," and finally emulating the receipt verification server on the Apple App Store.

Affected iOS apps treat Borodin's server as an official communication because of how Apple authenticates a purchase. Until recently, there was nothing that ties the purchase directly to a customer or device, meaning a single purchased receipt could be used again and again. In short, this hack meant in-app purchase requests were being re-routed as well as approved. Now developers can thwart the approval process.

Still, Cupertino is transmitting its customers' Apple IDs and passwords in clear text (Apple assumed it would only ever be communicating with its own server). The following information is transferred from your device to Borodin's server: app restriction level, app id, version id, device guid, in-app purchase quantity, in-app purchase offer name, app identifier, app version, your language, and your locale. Whoever operates in-appstore.com could easily be gathering everyone's iTunes login credentials (as well as unique device-identifying data) in a classic man-in-the-middle attack. My guess is Apple will address this part of the hack in iOS 6.

Update on July 23 - Hacker on Apple's iOS in-app purchase fix: 'Game is over'

See also:

• Apple iOS in-app purchases hacked; everything is free (video)
• Apple investigating iOS in-app purchase hack
• Apple tries to block iOS in-app purchase hack, fails
• Apple adds unique identifiers to fight iOS in-app purchase hack
• Cross-platform Trojan attacks Windows, Intel Macs, Linux
• New Flashback variant silently infects Macs
• Over 600,000 Macs infected with Flashback Trojan