How a flaw in Apple’s in-app purchase process enabled more than 30,000 illegal virtual transactions

Earlier today a method came to light that allows Apple device users to ‘purchase’ any kind of in-app content for free. The content can be obtained without “hacking” the device and cannot be prevented by developers using Apple’s recommended receipt signing procedures, as has been widely suggested. Updated with statement from Apple below.

The method for stealing this content was discovered by hacker Alexey V. Borodin, who has created an online service called In-Appstore.com to facilitate it.

The method was first reported on Russian blog I-ekb.ru, and subsequently on 9to5Mac. We’ve now spoken directly to Borodin about the method and can supply more information about how it works, what the causes are and some possible solutions.

As of earlier today, some 30,000+ in-app purchases have been made through Borodin’s service, which he says gathers no personal information from its users, though those using the hack do transmit their Apple ID and password to the service when using it. That alone should deter any potential users.

How it’s done

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

It’s important to note that this is technically not a hacking of the software on a user’s device, nor is it altering any code in the apps themselves. It is simply a method for bypassing Apple’s authentication servers for in-app purchases, directing the requests to Borodin’s service, which then delivers a receipt back to the device that fools the app into thinking that it has ‘purchased’ the content. This is commonly referred to as a man-in-the-middle attack.

All Borodin’s service needs is a single donated receipt, which it can then use to authenticate anyone’s purchase requests. Many of those receipts have been donated by Borodin himself, who has spent several hundred dollars on in-app purchases testing and generating receipts.

The exploit requires that a CA certificate and a profile needed to establish a connection with iTunes be installed on the device, a simple procedure that can be done right from an iPhone or iPad. It also requires that a user routes the internet traffic of the device through a Domain Name System server that Borodin set up to act as an intercept for the purchase requests made from the device.

Once these steps have been taken, the user simply taps on the ‘purchase’ button in an app and the server intercepts the request and furnishes it with a receipt for the purchase.

Apple currently provides a method for developers to verify their App Store receipts with its own servers, leading some to believe that this method could prevent a bypass like Borodin’s from working. We have confirmed with him that this is not the case. Because the bypass emulates the receipt verification server on the App Store, the app treats it as an official communication, period.

These purloined in-app purchases cannot be restored using an app’s ‘restore purchases’ dialog, but they can be re-downloaded by using the service again and are included in full-device backups.

If a developer was to use their own servers to verify in-app-purchases using Apple’s recommended method, it would currently be safe from the bypass, but only because the In-Appstore service is not caching the traffic to those sites. Borodin says that it would be simple for it to begin doing so.

Note that this vulnerability is similar to the one that was noted could affect Mac App Store apps on its launch last year, but this one cannot be prevented by simply validating App Store receipts.

At the core of what makes this method work is the fact that Apple only includes generic information in its receipt framework. This means that the item being purchased, the app, and a few other identifying bits are in the receipt, but nothing that ties the purchase directly to a customer or device. This makes it easy to capture a single purchased receipt and pass it off as a new one on each request.

Apple must act, but developers can prevent

According to Borodin, one fix for this vulnerability would be for Apple to alter its API for in-app purchases (IAP) to offer a more unique kind of receipt for purchases, which would raise privacy issues.

Another possible fix, however, would be for Apple to update the API used for IAP to add a way for developers to ensure, without a doubt, that the verification call mentioned above is talking directly to Apple.

“The fact is, this would be easy for Apple to solve by providing a method for developers to validate IAP receipts using what’s called a “shared secret,” that is, a piece of information known to both Apple and the developer that is not exchanged as part of the validation process,” says developer Marco Tabini. “Coupled with another technique called “salting,” in which each communication is digitally signed in a time-sensitive way, this would make it much harder for someone to subvert the IAP process using a man-in-the-middle attack.”

So a combination of two-way encrypted communication between the receipt server and the app, as well as a more stringent protocol provided by Apple, is needed to completely solve the issue. If every developer used a securely encrypted receipt validation method like the one described above, Borodin’s method would never have worked. Unfortunately, many use only the standard method which authenticates with Apple’s servers only, not their own…and not securely.

We asked Borodin if he would be willing to share his findings with Apple, and he agreed, so we put him in touch with the company. He also says that he is no longer in control of the In-Appstore site, and will be deleting any information that he has about the site from his computer. The site is now in the hands of an unnamed third party, as Borodin says he does “not want to be in jail =).”

“I work alone. There was an idea. An angry idea due to CSR racing. Now the idea is reality,” says Borodin of his motivations for hacking the in-app purchase model of the popular arcade game. This idea led to the method used by In-Appstore to spoof those services.

Borodin has a PayPal button up on the site. So far, he has received $6.78 in donations.

We have reached out to Apple for comment on this story.

Update: Apple has issued a statement about the issue to The Loop:

“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.”