Home > Apple > How a Russian hacker cracked Apple’s iOS…

How a Russian hacker cracked Apple’s iOS in-app purchasing

app store

Last week, Russian programmer Alexey V. Borodin shook one of the foundations of Apple’s iOS application ecosystem: He went public with a trick that enables iOS users to make in-app purchases within a wide variety of iOS applications for free. It doesn’t work with all apps, but many programs that rely on Apple’s own in-app purchase confirmation mechanisms can be fooled into thinking a user has made a legitimate purchase even though no money has flowed to Apple — or the developer. For some apps, this might be a mere inconvenience, but for apps that rely on some types of subscription updating or follow a “freemium” model wherein the app itself is free but additional levels or in-game currency costs money, Borodin’s attack could be a nightmare scenario.

Borodin’s attack is fraud, pure and simple, and Apple has been actively striking back, blocking his servers and working with YouTube to get how-to videos taken down. However, Borodin’s success could have wide ramifications for Apple’s iOS ecosystem and iOS users: Developers are being cheated, and thousands of iOS users are now willingly handing over their AppleID names and passwords to someone in Russia in exchange for things like free game levels.

Meet Alexey Borodin

Borodin in-appstore hack confimation

For folks who aren’t familiar, iOS’s in-app purchases enable application users to make purchases via iTunes from within an iOS application itself, rather than having to saunter out to the app store, navigate around, authorize a purchase, and then scurry back to the original app. Purchases are made against a user’s existing AppleID: depending how a user has an account set up, that might lead to a credit card transaction or a deduction against iTunes credit. In-app purchases (IAPs) can’t be used to purchase services or physical goods for things outside the app — so retailers can’t use in-app purchases to, say, sell shoes or dinner reservations — but they’re perfect for things like unlocking additional content within an application, purchasing virtual goods or currency, or subscribing to regular content updates. Just like apps sold through the App Store, developers get to keep 70 percent of the purchase price, while the remaining 30 percent flows to Apple.

In-app purchasing is particularly useful for so-called “freemium” applications, where the app itself is free of charge to encourage people to try it out, but additional content or features have to be purchased. Maybe the purchase unlocks advanced capabilities or functionality, maybe users can pay to receive auto-renewing subscriptions to new content, or (for games) maybe the purchase unlocks new levels, activates new powers, or provides virtual currency that can be spent in-game.

This is where Alexey Borodin took issue with in-app payments: not with the concept itself, but apparently with CSR Racing — a free game that offers a number of add-ons via in-app purchases. “I was very angry to see that CSR Racing developer taking money from me every single breath,” Borodin told Macworld’s Lex Friedman. So, Borodin decided to find a way to get all the add-ons without actually paying for them.

How the attack works

App Store In-App Purchasing (quarters)

When a user makes in in-app purchase, the application connects to Apple’s iTunes service to approve the transaction. If the transaction fails due to an invalid AppleID, bad password, or so forth, then the Apple tells the app that the transaction didn’t go through. Otherwise, Apple’s iTunes service returns a digital “receipt” for the transaction. These receipts are remarkably generic: they don’t contain any personally identifiable information about the user who made the purchase, but basically consist of a unique transaction code and a few other details. To keep things secure, Apple uses industry standard SSL technology to encrypt the connection to the iTunes service. This is the same technology behind the https:// protocol used in secured Web connections.

Apple then recommends developers validate the in-app purchase receipts on their own. That is, securely send the receipt to a service controlled by the developer, then have that service confirm with Apple that the receipt is legitimate. If it checks out, that service can then tell the application to honor the receipt.

Except most developers don’t do that. Instead, they ask Apple to verify the receipt they just received. That means, most of the time, there are only two parties in an in-app purchase transaction: the user (as represented by the app) and Apple.

Borodin’s attack works because he substitutes himself for Apple, setting up his own server that approves every transaction and then verifies they’re legitimate. To do this, users have to install forged security certificates that claim to be from Apple — this is how Borodin is able to fake a secured connection — and then set up a system controlled by Borodin as their DNS server.

The result is that when an application tries to connect to iTunes to perform an in-app purchase, the connection gets redirected to Borodin’s servers, which are able to set up a secure connection that looks — so far as the app is concerned — that it’s from Apple itself. The simplicity of Apple’s receipt format means Borodin can easily generate fake receipts apps will honor. Those receipts do not verify as legitimate with Apple’s real iTunes service, but since most developers relying on in-app purchases don’t do independent verification, the trick works.

Man in the middle

espionage spy shutterstock squid mediaIf Borodin’s attack against iTunes sounds familiar, that’s because it’s a classic “man-in-the-middle” strategy. Think of a man-in-the-middle attack as someone at the post office who reads letters to and from individuals, then — one he gets a sense for how they write and what they’re talking about — starts inserting letters of his (or her) own into their correspondence. Internet-based man-in-the-middle attacks work much the same way, except the post office can effectively be anywhere in the world.

Man-in-the-middle attacks are a malware classic. In fact, the DNSChanger malware servers that were recently shut down by the FBI were part of an elaborate man-in-the-middle attack, and the Flashback malware that sent the Mac OS X world into a frenzy earlier this year was another form of man-in-the-middle attack.

A crucial difference here is that Borodin is not launching his attack as malware: Instead, he’s providing instructions so users can subject themselves to the man-in-the-middle attack. It’s totally opt-in. There’s no vulnerability in Apple’s in-app purchasing that’s suddenly going to send user’s purchase information to some guy in Russia. Your credentials are safe as they ever were if you use Apple’s in-app purchases as intended. Instead, users have to make some relatively sophisticated changes to their devices to let Borodin’s trick work.

Is Apple to blame?

Apple iPad iPhone MacBook AirThe mechanisms Borodin is using for his attack are nothing new. DNS hijacking is almost as old as the Internet itself, and the forged certificates have been repeatedly used to target secure Web connections. Remember the Flame malware? One of the ways it spread was via forged security certificates. Forged security certificates have also been used to target Gmail users, the CIA, and many other organizations. Security certificates are usually validated by trusted third parties called Certificate Authorities. The ability to install and revoke individual security certificates on a local device is a core feature of SSL technology, and one that has widespread (legitimate!) uses in corporations, schools, and many other organizations. Apple isn’t to blame if someone taps into its SSL connections using forged certificates.

However, Apple does seem to bear responsibility for a couple of things. The first is the format of its receipts for in-app purchases. Although Apple is to be lauded for not including personally-identifiable information in those receipts, the straightforward format of those receipts has apparently made them easy to fake. Simple doesn’t necessarily mean “easily forgeable,” but in this case the two appear to go hand-in-hand.

Second, although Apple is relying on SSL security to encrypt the connection to its own iTunes service, Borodin claims Apple is transmitting the password for a user’s AppleID in clear text over that secure channel. That means a man-in-the-middle attacker can not only intercept purchasing connections to Apple’s iTunes service, he gets users’ passwords for free. This creates all sorts of opportunity for users to hijack or take over users’ AppleIDs and iTunes accounts. Borodin says he’s not collecting or using anyone’s password information, and so far there are no reports of users’ AppleIDs being compromised as a result of using Borodin’s fraudulent service, but we only have Borodin’s word on it.

What it means for Apple

All signs are that Apple is working quickly to shut Borodin down. Although Apple has only publicly confirmed it is “investigating” and takes App Store security seriously, it has managed to get Borodin’s initial systems blocked and his how-to-videos taken down from YouTube and other sites. For now, Borodin appears to be skipping around these blocks by migrating his servers to facilities hosted in other countries, making it even more complicated for Apple to get local law enforcement involved. Borodin appears to be taking a very cavalier attitude to the whole thing.

However, now that the cat is out of the bag, there’s nothing stopping others from replicating Borodin’s methodology — it’s not very complicated. If Borodin really wants to be a pain in Apple’s backside, he’ll wrap up and publish the necessary information so anybody who can buy some virtual hosting can set up their own private App Store that magically approves all in-app purchases. It’d be more difficult than installing some certificates and DNS settings on an iOS device, but within the skill set of anyone who has, say, set up a Web site.

For iOS developers, Borodin’s successful attack on in-app purchases can be a major problem. If they’re not validating Apple’s purchase receipts independently, they stand to lose in-app purchase revenue. That, in turn, makes developing for iOS less appealing for apps that rely on in-app purchases, and eventually damages the iOS ecosystem. After all, why develop an app that relies on in-app purchases if you’re just going to get ripped off?

Why aren’t most iOS developers separately validating Apple’s in-app purchase receipts? The basic answer is that the ability to design a nice iOS app or game and being able to deploy a secure ecommerce solution are two different things. Apple presents in-app purchases (and the entire App Store ecosystem) to developers as a turnkey solution: They don’t need to worry about the mechanics of how purchases are processed in their apps. Just plug in to the API, set up their in-app purchases, and like magic, 70 percent of purchases just appear in their account. Setting up a separate service to validate in-app purchases in real time isn’t necessarily something a small game developer or publisher knows how to do (or do well), so it’s simpler to go with Apple’s built-in validation.

Developers who want to be immune to attacks like Borodin’s in the future have a couple of choices. They could update their apps to separately validate purchase receipts. For developers who lack the savvy, this sort of service might present an opportunity for a third-party developer who wants to provide a service for validating receipts. (But, again, there would be trust issues: What if someone managed to spoof the third-party service?!) But even if developers put a receipt validation scheme in place, they still have to hope users update their apps — after all, the software out there now will still be vulnerable.

Developers could also wait for Apple to issue a fix. Apple could make its receipts harder to fake with technology asymmetric encryption, or so-called “shared secrets” (basically, unique codes) only known to both Apple and the application. Either approach would make it very difficult for a man-in-the-middle to generate fake in-app purchase receipts. It also means if a single shared secret is compromised, no other apps are impacted. Unfortunately, implementing a change like that would require an iOS update. And although Apple has very good adoption rates for new versions of iOS, the forthcoming iOS 6 is going to leave the original iPad and the older iPod touches in the dust. If Apple wants to solve this problem in iOS for most users, it’s going to have to update at least iOS 5 as well as iOS 6.

What it means for iOS users

Anyone who uses Borodin’s service to trick applications into processing fraudulent in-app purchases is not only ripping off application developers, they are sending their AppleIDs and passwords to an unknown third party. If you’re comfortable committing fraud and handing over your credentials to a self-proclaimed hacker halfway around the world…well, go for it. We can’t stop you.

We sympathize with Borodin to a certain extent: There are any number of iOS apps and games that make truly crappy use of in-app purchasing, nagging users, getting in their way, and trying to nickel and dime customers every step of the way. Just like poor use of graphics, sound, user interface, and design can make an app annoying-to-impossible to use, in-app purchasing can turn an otherwise great idea into a miserable experience. CSR Racing certainly appears to be an example, although there are plenty of others.

But there’s still a simpler way to force apps like that to get better or go away: Don’t use them.

Receipt image via Shutterstock / discpicture
Spy image via Shutterstock / Squid Media

Get our Top Stories delivered to your inbox: