Apple adds unique identifiers to fight iOS in-app purchase hack

Update on July 20 - Apple to block in-app purchase hack in iOS 6, offers interim fix

Last week Russian developer Alexey Borodin hacked Apple's In-App Purchase program for all devices running anything from iOS 3.0 to iOS 6.0 (the In-App Purchase program requires iOS 3.0 or later), allowing iPhone, iPad, and iPod touch users to circumvent the payment process and essentially steal in-app content. Apple confirmed the workaround and said it was investigating the issue. This week, Cupertino tried to block the hack but failed. Now the company is finally starting to offer a proper solution, though it's not quite there yet.

Apple has quietly started including unique identifiers in the validation receipts for in-app purchases. Yesterday, developers started seeing the new receipts, which include a new field called "unique_identifer." I say quietly because this key is not yet mentioned in the "Verifying Store Receipts" documentation on the iOS Developer Library. MacRumors has the scoop:

As one developer noted to us, apps are no longer supposed to be collecting the UDID and thus it is unclear whether Apple's use of the identifier for this purpose is simply a first step toward a broader implementation of unique receipt identifiers for increased security or if Apple is attempting to identify those users and devices who are sharing their receipts with the Russian hacker to allow the method to function.

I would wager that it's the former. You see, the worst part about this hack is that iOS developers have no way of protecting their apps. Using store receipts does not work as Borodin says his service simply needs a single donated receipt, which it can then use to authenticate anyone's purchase requests. His circumvention technique relies on installing certificates (for a fake in-app purchase server and a custom DNS server), changing DNS settings to allow the authentication of "purchases," and finally emulating the receipt verification server on the Apple App Store.

The iOS apps treat Borodin's server as an official communication because of how Apple authenticates a purchase. Until now, there was nothing that ties the purchase directly to a customer or device, meaning a single purchased receipt can be used again and again. In short, this hack means in-app purchase requests are being re-routed as well as approved.

With these new unique identifiers, Apple is on its way to offering a proper solution. Borodin has declared he wants the company to fix the problem by either changing its APIs or placing new blocks on its service. That's what this looks like to me.

Still, Cupertino is transmitting its customers' Apple IDs and passwords in clear text (Apple assumed it would only ever be communicating with its own server). The following information is transferred from your device to Borodin's server: app restriction level, app id, version id, device guid, in-app purchase quantity, in-app purchase offer name, app identifier, app version, your language, and your locale. Whoever operates in-appstore.com could easily be gathering everyone's iTunes login credentials (as well as unique device-identifying data) in a classic man-in-the-middle attack.

From my understanding, Apple has to start encrypting the connection and update iOS so that the operating system is aware of the changes being made. This will stop from apps being able to approve false purchases. I will continue to keep you posted as this story develops.

See also:

Update on July 20 - Apple to block in-app purchase hack in iOS 6, offers interim fix

• Apple iOS in-app purchases hacked; everything is free (video)
• Apple investigating iOS in-app purchase hack
• Apple tries to block iOS in-app purchase hack, fails
• Cross-platform Trojan attacks Windows, Intel Macs, Linux
• New Flashback variant silently infects Macs
• New targeted Mac OS X Trojan requires no user interaction
• Over 600,000 Macs infected with Flashback Trojan