What the in-app purchase hack means for app makers
The recent news that a simple hack makes it trivial to circumvent iOS’s in-app purchasing mechanism raises the question of whether Apple is doing enough to help developers safely conduct transactions through the App Store.
In-app purchases—IAPs for short—are a mechanism that allows an app to charge a user’s iTunes account in exchange for digital goods and services: It’s what makes it possible for so many games to let their customers purchase some sort of app-specific currency like coins, or subscriptions to a service. Given how many apps have adopted a business model that relies on a very low initial download price—often free—to then charge customers as they use the app, IAPs have become a very important tool for app makers.
How IAPs work
Without going into needless technical details, IAPs are relatively easy to use from a developer’s perspective: Before submitting an app to Apple, the developer simply registers whatever products an app sells (e.g.: “Buy 1,000 coins for $0.99”). Later, upon the user’s requests, the app asks iOS to complete the purchase. The device, in turn, usually asks users for their iTunes login and proceeds to complete the transaction, at which point it notifies the app that the latter has taken place.
Behind the scenes, iOS connects to Apple’s servers to perform two tasks: First, it validates a username and password, and then it asks for the user’s iTunes accounts to be charged based on the details of the IAP that the developer has registered when they submitted the app. To help protect the user’s information from prying eyes, this process takes place over an encrypted channel using TLS/SSL—the same protocol that Web browsers use when connecting to Websites whose URLs begin with “https://”.
From the developer’s perspective, this entire process is completely opaque. The operating system simply responds to an IAP request by either notifying the app that the transaction failed—for example, because the user changed his mind or didn’t have sufficient funds—or by returning a “receipt” that indicates that the purchase went through. Later on, 70 percent of the purchase price shows up in the developer’s bank account. (Apple keeps the remaining 30 percent as a commission.)
In keeping with Apple’s commitment to privacy, the receipts do not contain any information that can be used to identify the user who made the purchase. Critically, other than a unique identifier and some other minor information, therefore, two purchases for the same product result in essentially identical receipts.
IAPs are a boon to developers large and small. Compared with having to set up your own payment system, they are easy to implement. And, because they rely on iTunes, they present users with a familiar, safe, and frictionless way to pay.
How the hack works
Without any security and third-party validation, it would obviously be very easy to corrupt the IAP process. All that needs to be done is to trick a device into contacting a server other than Apple’s real ones, and then respond to IAP requests with receipts that contain plausible, but fake, information.
To alleviate this problem, Apple uses the industry standard SSL/TLS protocol to secure its communications. This both encrypts the data so that a third party cannot intercept it and uses digital certificates to positively identify Apple’s servers; if the digital certificates can be trusted, the device can be sure that it is, indeed, communicating with the Cupertino giant’s real servers.
The validity of digital certificates is assured by so-called Certificate Authorities—basically, third parties that validate the identity of a company and “countersign” its certificates. Some authorities are normally hard-coded in the operating system, but others can be configured manually—a process that is supported by Apple and is, indeed, very useful in many scenarios, including enterprise deployment.
The in-app purchase hack currently making headlines takes advantage of this capability by installing custom, forged certificates and using a custom DNS server. That results in successfully redirecting all the traffic that would normally go to Apple’s IAP servers to a different address, while the faked certificate makes the device believe it is still talking to Apple, when in reality its communications are going to a server that is under the hacker’s control.
With this fairly easy one-two punch, the entire security around the IAP process is breached; if the hacker can produce believable receipts, it is essentially impossible to tell these apart from real ones just by looking at their contents. As an added bonus, it appears that iOS sends both your iTunes username and password in clear text—making it possible for the hacker to collect those as part of the fake purchase process.
Oh, so simple
If this sounds a little too simple—well, it is. The hacker is performing a classic example of something called a “man-in-the-middle” attack—the Internet equivalent of listening in on a phone call, and then pretending to be one of the two callers at a later point.
Apple is perfectly aware of this limitation, and strongly recommends that developers use their own mechanism to validate IAP receipts. Typically, this involves setting up a separate server, sending the receipts over to it, and then validating them against Apple’s servers. Because the server is entirely under the developer’s control, a man-in-the-middle attack is much harder to pull off.
Leaving aside the cost of setting up your own server, however, it is unfortunately easy to implement even this kind of validation in a way that leaves an app greatly vulnerable, because nothing prevents a hacker from pulling the same kind of attack on the developer’s servers and foiling the app’s secondary validation in exactly the same way.
A better approach consists of using mechanisms that rely on asymmetric encryption, a technique that requires two passwords. When the first password is used to encrypt the data, only the second can be used to decrypt it, and vice-versa; if one of the two passwords is stored on the developer’s server and is never transmitted between the two, a man-in-the-middle attack would be very hard to pull off, particularly if each transaction is crafted so that it is only valid for a very short period of time.
This is not an impossible task, but it is a much harder one that needs to be performed for each individual app. The protection mechanism is also relatively simple to implement, if the developer has the necessary know-how.
Oh, so broken
On the surface, then, it looks like this is a problem for the developers to solve; after all, Apple makes no guarantees that its IAP verification process is to be trusted, and explicitly warns developers that they should implement their own validation system—not to mention that the hack in question only succeeds because the users essentially poke a giant security hole in their devices.
To me, however, that seems a bit unreasonable. Despite the fact that Hollywood appears to have convinced the majority of the world’s population that all developers need to do in order to produce working apps is smash their pudgy hands on the Big Green Button (the red one is reserved for emergencies only), programming is a highly specialized profession. Thus, an independent developer who knows how to create a beautiful and engaging game does not necessarily have sufficient experience to understand the complexities of data cryptography.
To that, we must add the cost of setting up your own server. It may not take a large amount of money, but a small amount of money is all that many developers make; servers must be maintained, and server-side code must be written—all activities that take time and cash.
Besides, the entire premise of the App Store is that the whole app distribution process is delegated to Apple precisely so that developers can focus on what they do best: Write great apps. Apple’s 30 percent cut becomes much harder to justify if, in addition to writing great software, developers also have to worry about being defrauded.
What Apple could do
Given what’s involved, it’s no surprise that many developers forego any secondary IAP validation, exposing themselves to hacks of the kind we have just seen. The question is, what can be done about it?
The first, and perhaps most obvious response, is that Apple could make the IAP process more secure. This would relatively easy for the company to implement, and would fit well within the App Store distribution model, leaving the developers free to worry about writing more great apps for the iOS platform.
Unfortunately, it would most likely require an iOS update to do so, which means that it would be a while before any Apple-provided solution could be made available to developers. More immediately, the folks from Cupertino could try to better educate developers, helping them understand the limitations of IAPs and guiding them in implementing validation procedures that are both simple and secure. iOS’s developer documentation is severely lacking in this area, and could definitely use a bit more information.
And, finally, the public needs to be educated as well. While it may sound fun to “stick it to The Man” and make IAPs without paying the developers a dime, there’s a fair chance that The Man may strike back.
Remember, this hack exposes the iTunes credentials of everyone who uses it, which means that the hacker now has access to the iTunes accounts of everyone who used his trick. And, since circumventing IAPs is essentially fraud, it’s not entirely unthinkable that law enforcement may one day get their hands on those credentials as well, leading to plenty of uncomfortable questions for all involved.
What it all means
It’s hard to say whether this incident is going to have any long-lasting effects on the App Store. Judging from its success, the hack seems to affect a large number of apps, which should, at least, serve as a wake-up call to both developers and Apple.
On the one hand, developers can (and should) do a better job handling IAPs. Despite the software industry claims to the contrary, it’s difficult to properly correlate piracy to lost sales; still, it’s in each developer’s best interest to ensure that their software is well-written, and that includes making sure that they get paid when they deserve to.
On the other, Apple could have largely prevented this problem, which threatens not only to leave it with a large contingent of unhappy developers, but also could have wide-ranging repercussions for users who are compromising the security of their devices for a purpose that is trivial in relation to the amount of damage that they could be doing to their data. Even if Apple shuts down this specific hacker, the proverbial cat is definitely out of the bag, and there is relatively little that prevents someone else from trying something similar, with possibly more nefarious intentions.
Still, Apple has a long history of doing the right thing, and it has gone to bat for developers in the past, as was the case with the Lodsys affair. In this particular case, the company has a number of solutions at its disposal, some of which can fit easily into its existing developer outreach programs. With a little help from Cupertino, it’s very likely that IAPs will continue to be an important part of the iOS user (and developer) experience.
[Frequent Macworld contributor Marco Tabini is also a developer.]