Apple has notified app developers of a fix for a Russian hacker’s method that let him make more than 8.4m fake in-app purchases and pass them on to users.
The fix gives developers access to two of Apple’s private APIs on iOS, a move the company has not made before and which demonstrates the seriousness of the flaw.
At least 115 games were affected, including Tap Tap Revenge 4, Temple Run, Plants vs Zombies HD, Infinity Blade 1 and 2, Fruit Ninja, Fifa 2012 and Angry Birds.
The fix will check whether both new and old purchases are valid – meaning that once it is implemented in an app, faked purchases will effectively be wiped off on the devices of users who used the system developed by Alexey Borodin, and which he made public a fortnight ago.
That could, however, dissuade those who have already used the fake system from upgrading their apps. Apple says that the hack will be irrevocably fixed in iOS6. Meanwhile, it is trying to block attempts by Borodin to connect to its servers to make further faked purchases.
In-app purchases have become an increasingly important way for developers to make money from apps, by letting users download a simple version for free and then offering paid-for levels, upgrades or capabilities inside the game.
Borodin, who figured out how to hack the system for in-app purchases by spoofing the receipt from Apple’s servers, says on his blog that once developers implement and roll out the fix, “[the] game is over. Currently we have no way to bypass updated APIs.”
But he adds that he will keep offering the service until the next version of iOS is released, expected some time in the autumn.
Next he says that he will look to see if the App Store on Apple’s Mac OSX desktop operating system has a similar vulnerability. “We are still waiting for Apple’s reaction and we have some cards in the hand,” Borodin notes. “It’s good that OS X is open.”
Borodin’s hack will probably keep working on apps until they are updated, and users download the revised apps. After posting that the game is over, on Monday he posted a further hack suggesting that he has now figured out how to get content from Apple’s Newsstand, giving access to magazines and comics.
His workaround uses his own In-Appstore website to act as a proxy server that pretends, from the app’s viewpoint, to be Apple’s servers which validates in-app purchases.
In the app, such purchases check that an SSL certificate has been received, to indicate that a secure transaction has taken place – but Apple failed to build in checks to let apps confirm that the transaction was made with Apple’s servers, rather than any site returning the correct code and a certificate.
In a new page on the iOS developer site, Apple says that developers can re-validate transactions that have already been carried out by checking them against Apple’s SSL certificate for its own server, using two private APIs:
This listing uses the symbols kSecTrustInfoExtendedValidationKey and SecTrustCopyInfo, which are not public API. Your app is allowed to use them for this specific purpose.
Developers who use their own servers for validating in-app purchases, which then connect to Apple’s servers, will not have been affected by the hack, which Borodin began showing off around a fortnight ago.
However Tony Million, an iOS developer running Zummer, a startup, suggested that developers should never have fallen victim to the hack.
“Apple has an entire server architecture for developers to confirm the receipt they’ve received from the in-app purchase was valid and made via the iTunes store,” he said.
“Once you have performed the in-app purchase, you contact Apple’s servers separately, send them the receipt data, and they [Apple’s servers] respond with a YES or NO. You then act on this result. The second part of this [process] is to store the receipt so it can’t be reused fraudulently – every receipt from the iTunes store is unique.”
Million said that while the documentation was somewhat obscure, it is on Apple’s site. But Apple made a mistake in not letting developers check the validity of the SSL certificate returned from the transaction. “That’s why the hack works in the first place,” he said.