Jul 21

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 documentthat describes the issue and teaches developers how to temporarily plug the issue.

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.
    Source [9to5ma]



    \\ tags: , , , ,

    Leave a Reply