Installing a custom SSL root certificate feels like such a good idea. Not.
But I guess in order to get something for free, people are willing to go great lengths in compromizing their security. Remember: By installing that guys SSL root certificate, you basically allow them to MITM not just the App store in-app purchasing (and by extension likely sniff your app store password) but also any other SSL protected site like, say, your webmail provider.
If you are using IAP in your app and want to keep this hack from working you should be validating receipts. It isn't hard to do, check out https://github.com/carsonmcdonald/iap-validator for an example.
I totally agree, the best practice is to validate transactions before delivering content.
It wasn't clear from the article if the method could bypass that. It would have to provide valid transaction ids to the app developer's server. That seems a little too sophisticated or impossible, so you're probably right.
I guess we should really just be surprised this wasn't done sooner.
>It wasn't clear from the article if the method could bypass that. It would have to provide valid transaction ids to the app developer's server.
Even if this method does manage to bypass Apple's validation, then it is Apple's problem and they will fix it quickly. But it is much more likely that developers just haven't bothered to validate receipts.
You have to do it on the server. And it's a pain to implement correctly, full of cryptic error codes. I imagine many developers skip it since it's not required by Apple.
The other thing is that you're dependent on the validation server's availability to check the receipts. Apple's got great uptime in this respect (and others), but there have been outages (a big one last September: http://www.ilounge.com/index.php/news/comments/app-store-suf...).
It's a tradeoff, really, that most IAP implementors consider:
Cost of support and loss of goodwill when legitimate customers run into issues vs. loss of revenue from pirates (heretofore only jailbroken phone users) who likely wouldn't have purchased anyway.
It makes fiscal sense for big players with big IAP scale like Zynga to strictly validate. Little players may find it is less critical to the bottom line to be strict about it.
+1
Totally agree, it is actually pretty easy and worth it if you already have to have a server. If you don't already have a server, then it probably isn't worth adding one.
Apple does not require it because its not their job. Its the app developer that's losing money because of this not Apple. They provided a way to do it right.
Probably mostly game apps where the item being sold is purely virtual. It seems to me like the extra cost of validating receipts for that use case wouldn't be worth it.
As a side note, you can do something similar (albeit a thousand times safer, as you (= your computer) issues the certificates, not some unknown hacker) to fool Game Center.
I get maybe 20 Game Center invites from 8 year old kids on a daily basis... The reason is I faked my score on the popular game Jetpack Joyride (I'm #1 out of 16 million players), and also beat Minesweeper's hard map in a few milliseconds (second guy is I think over a minute)...
I did it just for fun and experiment, but apparently there are kids who really take Game Center seriously and I stopped doing it, not wanting to hurt their feelings. The instructions are here: http://corte.si/posts/code/mitmproxy/tute-gamecenter/index.h... , but please don't go crazy, and don't submit ridiculous scores like I did. You may get your account banned (which is not a great thing, if you're a developer).
This is really easy to do and a fun experiment to learn MITM attacks. My boss was gloating he was the best at jetpack joyride and the whole office had a good laugh knowing that I could always beat his best score by a small amount the day after het set it. Apparently that put a downer on his christmas because he spent so much time trying to beat me.
It did cross my mind whilst watching the traffic if you could spoof in app purchases but never took it any further.
>despite warnings from the developer himself to please “not pirate AppStore apps”, he continues to assist users of the hack that report it not working with certain apps.
But they're doing the exact same thing by saying: Don't do this...but if you want to do this here's all the relevant information and if you have trouble the dev is responsive to support requests. They even note that he accepts donations on his site.
Also notice how they talk about "stealing" in-app content. And i thought this term did not apply when only copying stuff without depriving the original owner of it...
I don't know the site but I wonder if they'd say the same if it was for downloading music or movies and not apps.
Note that i'm NOT a tenant of the american strong copyright.
Since that is perhaps the greatest point of contention in the debate, of course it would make the discussion a lot easier if one side simply gave up and accepted the other side's position.
I was trying to, oh well nevermind. My point is that, the developer created it. He demands that for each license that is being used, he expects a sale. And we are denying him that sale by talking about "theft" and "copy" and all that.
Yes, and plenty of other people would disagree, saying that most pirates wouldn't have bought a copy anyway, so it's not denying him a sale. This thing you want everybody to just agree on is the central matter of the debate.
Good point. I agree. But if they wouldn't have bought a copy, then they weren't entitled to using it in the first place correct?
I mean, companies generally prefer you pirate their products than their competitors. But if we're going to be absolutely critical, the company can claim "If you aren't going to pay us, you have no right to use our product. You used our product without paying us."
If an app developer structures their app to be free with an in-app purchase for the full content, you don't think they're being deprived of anything if someone bypasses the full-content-payment?
Beyond that, the answer to "is copying equivalent to stealing?" is "no", because stealing involves depriving a person of their property and thus preventing them from selling it to a party that would pay.
If I steal a snickers bar from a shelf, the store owner has one less snickers bar regardless of whether I might have paid for it were I not able to steal it.
But copying doesn't deprive the owner of their property at all. It simply creates a new copy of it. If I copy an mp3, the record label and artist aren't deprived of anything.
This is, legally, the correct interpretation of the difference between "stealing" and "infringement", at least in the US.
However, the copyright owner is being deprived of their exclusive right to the content. They have the right to control who uses the content and for what (exclusive of fair use).
Sure. And that's why civil and criminal law provide remedies for wronged content owners.
But no-one's arguing that copying isn't wrong or a civil and possibly even criminal act. I'm explaining the distinction between infringement and theft, as it's far more relevant than the ultimately unknowable "whether or not the unjustly enriched party may have bought a license".
Sure. In stealing a snickers and caught, im probably not even arrested. If I am, it's a small charge, maybe a few hundred dollars with the night in lockup.
Copying a single song has punishments up to $150,000 with possible federal jailtime at that?!
And you're assuming that the person would not make the purchase were it to cost money. The fact is that the developer is being deprived a) their exclusive right to their content b) the possibility of making a future sale (which is of some non-zero probabilistic value).
Well that's only correct if the user and app are in isolated environments. If the purchase is currency in a competitive multiplayer game, then the game experience of others suffer. If there are hosted elements like server-side data to run, store and maintain, than the developer takes on those additional costs without compensation as well.
Given the info he's collecting from each device, if he's raided and server(s) confiscated, and that info given to Apple, I wonder if Apple will suspend the App Store accounts of those involved in in-app purchasing theft?
Preventing users who steal content from ever being able to legitimately access content is probably not a shrewd business move. Especially when alternatives exist.
Can't find references quickly, but in the past Apple has banned accounts of fraud victims, after they reported their accounts being hijacked. Victims, not perpetrators. Three fraud/hijack reports -> ban.
This has been out in the wild for a while now. I first noticed it when I added IAP to my application.
My app will call on our server to verify receipt and I was getting bogus receipts that actually caused that part of the code to crash.
Apple's receipts are proper json objects and what I was getting was this string "com.urus.iap.30297356." The last part keeps changing, so I am guessing the developer actually tracks usage.
So the moral is to always verify your receipts and don't deliver content unless the receipt is valid.
But most developers won't have resources to do this and creating a general service for them would be too much custom work. I think SDK platforms should have this capability built in. Pay $10/mo and we'll verify your receipt and return a file based on the IAP product id.
Obviously the fake DNS server intercepts the iphone<->apple's appstore server connections, to deliver a fake receipt. But then what? I would imagine real receipts should be signed with an apple private key. Does iOS also allow user-installed custom CAs to partake in this receipt signature validation? Could this be fixed by "pinning" receipt signature validation to the apple key?
Calls to the developer's server could also be intercepted, if you know which URL endpoints the app uses to "call home", and then they could probably be faked on a per-app basis, if you can wiretap a legit purchase to replicate any asset downloads and handshakes, though.
I haven't looked at this in depth but it sounds like they are pretending to be Apple and are sending a counterfeit response to the device. On the device there is a delegate callback that receives a SKPaymentTransaction object which has a bunch of information. I suspect the apps that are affected are just checking the state of the payment and not taking the transactionReceipt property and checking it with Apple to make sure it is legit.
It seems really strange that the StoreKit framework itself wouldn't perform a signature check (preferably pinned towards whatever built-in Apple CA necessary) before handing it off to the delegate callback, don't you think?
"When Store Kit returns a completed purchase to your payment queue observer, the transaction’s transactionReceipt property contains a signed receipt that records all the critical information for the transaction. Your server can post this receipt to the App Store to verify that the receipt is valid and has not been tampered with."
A double check to be sure nothing is amiss I guess. I do find it strange that they can't guarantee this callback is not trigged by a response from a HTTPS source. Actually maybe they are and this fake cert is what is allowing it so they added this two phase check just in case. But this ability to verify is also kept around if you store these receipts on your server. Before you write them to your DB you can check with Apple to make sure they are legit.
Another curious thing in the video demo is the alert dialog popup box that is triggered during the fake purchase, the one with the "Like" button and "Cancel" in Russian. Perhaps the storekit receipt transmission protocol allows for injecting actions on the device such as opening alert boxes, in addition to just posting a signed JSON receipt?
You have to get the check to a piece of trusted hardware for it to not be permanently bypassable (aka, not the device) by a jailbreak style hack of the storekit libraries.
The check HAS to be done off the phone for the hack to not be global and ever available.
Well, in this case there's no jailbreaks involved, so no code modification or patching. Obviously if you have root access on the device you can do "anything"; the "non-JB-ness" of this hack is what was particularly intriguing.
(also, if the ipa contains all data required for the IAP to work, a jailbroken device stands no chance -- any server checks could simply be NOP'ed out)
You have to NOP each program, as the code to check each program against the server (which is written by the 3rd party developer, which then talks to apple server), which is significantly more effort than if the verification with the apple server occurred on the device.
It does seem like the app store transaction should be forced to use an Apple cert, not just any cert signed by a root CA. Pinning a single cert seems risky, since certificates can be compromised.
Interesting. I may have accidentally stumbled on this hack a few years ago when I was sitting in an airport.
I had downloaded the (I believe) Boingo iOS app, which works by performing an in-app purchase for the amount of time you want to use their wireless network in the airport. I followed the directions exactly as specified, but instead of getting a "Purchase Completed" message I got a "declined" message. Despite not having paid for the wireless network time after that I was still able to connect and use the Internet without problem.
It may be that because un-authorized users are sometimes given walled garden DNS settings, it was causing a bit of confusion within the in-app purchasing system that results in free wifi for me.
(My alternative explanation is that I hadn't updated the expiration date on my credit card, so the purchase was declined but Boingo's app didn't differentiate between success and error from the App Store's system so I got the wifi anyway. I think this explanation is still the likely candidate.)
In any case, I told Boingo about the bug when I found it and after convincing them that it was their job to fix it and not mine. Since this was a few years ago I hope they've fixed the problem.
exactly - it is censorship - the issue is in using copyright infringement as a way of censoring things you don't like.
Needless to say I don't like this (IMHO companies should be obliged to pay for wrongly accusing something of copyright infringement [the same for invalidated patents])
This has been going on for at least a year, probably longer. It only works on apps that don't check the receipt with Apple's servers.
The fix for developers is to have your server check the receipt of the transaction with Apple. If Apple doesn't recognize the receipt, don't save the transaction.
Don't have the client do it, because client code can be easily hacked. Someone could intercept the app's communication with your server but it's not likely to be in a common format, so automated hacks won't work. They'd have to crack your app on a case-by-case basis.
Some of the text is very confusing. What does this mean?
> The method is not allowing users to install content from 100 percent of apps, as some users of the method report it failing for certain in-app purchases in specific regions.
It seems like some apps have regional restrictions on in-app purchases, which makes no sense unless you factor in that some of the apps have probably been pirated to begin with because they weren't available in certain regions.
It's funny how people's definition of stealing versus copying changes when it's their own skin in the game. Or at least when it involves the ecosystem they use...
1 release new api to validate inapp purchases
2 nobody uses it
3 hire Russian hacker to show how to exploit old api. Everyone fears Russian hackers.
4 ???
5 profit
But I guess in order to get something for free, people are willing to go great lengths in compromizing their security. Remember: By installing that guys SSL root certificate, you basically allow them to MITM not just the App store in-app purchasing (and by extension likely sniff your app store password) but also any other SSL protected site like, say, your webmail provider.