A hack that lets iOS users trick the App Store into giving them in-app purchases for free has gone public, potentially costing app makers revenue and causing Apple a major headache.
The exploit was first posted Wednesday, but came into prominence early Friday, after it was publicized by several websites. (In fact, the hack has proven so popular that the server allowing it is down as of this writing due to overwhelming demand.)
Alexey V. Borodin of Russia built the in-app purchase hack, which requires several steps—including installing bogus certificates on your device, and using a specially-crafted DNS server. Those ingredients combine to fool apps into believing that they’re communicating with the App Store, when they’re actually going to a Web server that pretends to be the App Store instead. Borodin told Macworld that his exploit works in part by faking—or “spoofing”—the code receipts that Apple issues for in-app purchases which developers use for validation, with the iOS device configured to mistakenly believe that those receipts are coming directly from Apple.
Speaking to Macworld over instant message, Borodin claimed that because “every in-app receipt is generic” and contains no direct user data, those receipts were “easy to spoof.”
So why did Borodin do this? “It’s my hobby,” he said. “And it’s a challenge to CSR Racing.” That’s an iOS game with a freemium model; though the game is free to download, it offers a slew of in-app purchases to unlock extra in-game options and features. Borodin disapproves. “I set this up due to hungry and lazy developers … I was very angry to see that CSR Racing developer taking money from me every single breath.” Borodin confirmed that he’s comfortable with other users getting in-app purchases for free if they feel similarly about the apps they use.
Behind the hack
To understand the hack, it’s important to learn a bit about how in-app purchases work. When a customer completes an in-app purchase, Apple sends the app back a bit of data. The app is then meant to ping Apple’s servers directly, in real-time, to confirm the validity of that receipt.
In short: The app gets notice of a completed transaction and should immediately confirm with Apple that the receipt came from it.
Borodin’s hack doesn’t work for all in-app purchases. That’s because there are two ways for developers to validate the receipts they receive from Apple—from the iOS device or on the app’s own Web servers.
Developer Marco Tabini told Macworld that Apple’s approach to receipt validation is flawed, and that thus the company itself is at fault for this exploit’s existence. (Disclosure: Tabini is an occasional Macworld contributor, and developed an app with me.)
The exploit, Tabini explained, is not due to developer incompetence. “Merely validating a receipt against Apple is not enough,” he said. Tabini said that processes like Apple’s should use a shared secret—sort of a secret code known only to the app and to Apple: “If Apple provided a shared secret as part of the IAP process, using that secret in conjunction with a random salt would prove to developers that responses from Apple were genuine when they validated receipts.”
Apple spokeswoman Natalie Harrison told Macworld: “The security of the App Store is incredibly important to us and the developer community. We take reports of fraudulent activity very seriously, and we are investigating.” The company had no further comment.
So Borodin’s hack works with purchases validated solely on iOS, because those purchases look only at the fake Apple server addresses the hack provides. Apps that instead rely on their own Web servers to validate receipts, of course, talk to the genuine Apple servers—which in turn respond that the receipts are invalid, since Apple didn’t really generate them. But Borodin says that the next phase of his hack will go one step further: “The future is to cache developers’ server responses,” he said, which would mean that even apps that validate on the Web would be at risk.
Tabini points out, however, that if developers use their own secure measures—shared secrets, secure signing, and the like—it would be an order of magnitude more work for Borodin to hack their apps’ server responses.”
In short, Borodin’s hack is a classic “man in the middle” attack, where the malicious code (or lucrative code, depending upon your perspective) sits between you and the real server you’re meant to hit.
Implications
The fact that Borodin’s hack exploits an apparent weakness with Apple’s system is unlikely to sit well with app makers. “The whole point of the [in-app purchase] system and the App Store is that you shouldn’t have to worry about the system,” Tabini said. “Otherwise, what are you giving Apple its 30 percent for?”
More to the point, app makers are more likely to rely on Apple’s receipt validation approach than building their own solution. “I’m willing to bet that 99 percent of all developers validate on iOS because it’s a lot of extra work to setup a server that does the validation,” developer Craig Hockenberry told Macworld.
Marco Arment, developer of Instapaper, believes that the hack will only work with standalone in-app purchases, not subscription-based ones like Newsstand apps employ. Via email, Arment told Macworld: “It probably won’t affect the auto-renewing subscriptions, since they rely on a lot of server-side processing to track, but it wouldn’t surprise me if it could affect any other [in-app purchase] type (including non-renewable ‘subscriptions’ like what Instapaper uses) if the apps don’t check with Apple’s verification servers from their own web services.”
iOS users who try the hack may find that, in addition to robbing the developers behind apps that they enjoy, they’ve put themselves at risk. “I can see the Apple ID and password,” for accounts that try the hack, Borodin told Macworld. “But not the credit card information.” Borodin said that he was “shocked” that passwords were passed in plain text and not encrypted.
According to Tabini, though, “Apple presumes it’s talking to its own server with a valid security certificate.” But that was clearly a mistake—“This is entirely Apple’s fault,” Tabini added.
What next
Fixing the exploit won’t be too difficult for Apple, but Tabini says, “I can’t think of an easy way to solve this problem without an iOS update.” While the servers that power Borodin’s exploit are currently down at this writing, there’s nothing to stop them from sprouting up again, or even to block him from releasing the code so that anyone can run it. That means that customers who don’t install the presumed iOS update that would patch this vulnerability could, in theory, continue to avail themselves of free in-app purchases for apps that continue to validate as they always have.
Apple could also change how app makers validate their receipts—which seems like a must. But that process will take time. In the meantime, developers can protect their apps against the exploit by switching to secure, Web-based receipt validation. But that fix will only work for users who upgrade to the latest version of their apps.
As for Borodin, he didn’t seem particularly concerned about what Apple does next. Asked if he was afraid about what Apple’s response to him directly might be. “No,” he replied, adding, “I’m a happy user of iPhone 4S … I think they will hire me.”
Updated 2:18 p.m. PT with comment from Apple.
Author: Lex Friedman, Senior Contributor
Lex is a former writer for Macworld. He lives in New Jersey with his wife and three kids.