Apple says iOS 6 to fix in-app-purchase fraud, gives developers a temporary fix

Apple has responded to the recent App Store in-app-purchase bug and fraud with an email and temporary solution for registered iOS developers. This email includes a link to a new Apple developer web document that describes the issue and teaches developers how to temporarily plug the issue. Apple says that it will fix the bug completely with the upcoming release of iOS 6 (thanks, @natesiphone).

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.

Apple has provided a question, answer, and solution section for three common questions from developers during the past few days (since the major App Store flaw was discovered):

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.

Apple has also provided developers with code and a step-by-stop process to mitigate the issue:

The code listings in this document’s companion files illustrate an implementation approach for the mitigation strategy described in this document.

Note: This listing uses the symbols kSecTrustInfoExtendedValidationKey and SecTrustCopyInfo, which are not public API. Your app is allowed to use them for this specific purpose.

To add this code to your project:

1. Download and unzip this document’s companion files. (The link is in the top right corner of this page.)
2. Add the VerificationController.h and VerificationController.m files to your project in Xcode, and add them to the appropriate targets.
3. Link your project against the Security framework.
4. Provide a base64 encoder, a base64 decoder, and the action to perform when validation succeeds.

Apple previously responded to the issue in a statement:

“The security of the App Store is incredibly important to us and the developer community,” Apple representative Natalie Harrison, told The Loop. “We take reports of fraudulent activity very seriously and we are investigating.”

We first publicized the issue one week ago today, noting that Russian hackers were able to circumvent Apple’s in-app-purchase process with only thee steps. We previously noted that the issue affects iOS devices ranging from iOS 3.0 to iOS 6.0, so Apple will likely rollout the fix in the next betas of iOS 6 or wait for the final release this fall.

A few days after the original news about the hack hit, Apple began making moves to stop people from being able to steal in-app-purchases from App Store developers. Apple’s early attempts at stopping the scheme included issuing takedown notices on the servers that powered the fraudulent hack. The hackers fought back by moving their servers to less-accessible locations.

It seems that iOS 6 will be the only true final solution to the issue, and Apple’s outreach to developers, today, is a temporary solution. It seems that the end of the issue will only be reached by Apple and developers working together. Apple is readying the iOS 6 patch this fall, and developers need to better protect their in-app-purchases with the new tools and guidelines that Apple released today.