14 ms·

Apple’s in-app purchasing process circumvented by Russian hacker

112 points by reidmain 14y ago

carson 14y ago
Apple has a way of validating receipts for in app purchases, see: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html http://developer.apple.com/library/ios/#documentation/Networ... 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 https://github.com/carsonmcdonald/iap-validator for an example.
- adjwilli 14y ago
  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.
  - thoughtsimple 14y ago
    >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.
  - conradev 14y ago
    This has already been done in the form of a tweak for jailbroken devices. This only brings it to unjailbroken devices.
- thoughtsimple 14y ago
  I wonder what popular iOS Frameworks don't validate in app purchase receipts :)
  - adjwilli 14y ago
    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.
    - jen_h 14y ago
      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-suffers-in-app-purchase-outage/ 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.
      - flatline3 14y ago
        You're also dependent on Apple's purchasing servers to buy the content to begin with, so I'm not sure I see the point.
    - stock_toaster 14y ago
      I wonder if Apple will start using certificate pinning[1] (like chrome does for google certs). [1]: http://www.imperialviolet.org/2011/05/04/pinning.html http://www.imperialviolet.org/2011/05/04/pinning.html
    - flatline3 14y ago
      Why do you say it's a pain to implement? It's an HTTP+JSON API, and there's only one error code you have to care about: If the value of the status key is 0, this is a valid receipt. If the value is anything other than 0, this receipt is invalid. http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html http://developer.apple.com/library/ios/#documentation/Networ...
- gcb 14y ago
  How this affect things like buying offline maps for gps? Also that page has an invalid ssl cert :)
danso 14y ago
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.
- MaxGabriel 14y ago
  It is confusing, I agree. It means "The method doesn't always work because some people have reported it doesn't."
- mikecane 14y ago
  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.
- deleted 14y ago
  [deleted]
pdenya 14y ago
I love how they look down on the developer >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.
- Jacqued 14y ago
  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.
  - danso 14y ago
    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?
    - taligent 14y ago
      No. Because you are assuming that the person would have made a purchase had it not been free.
      - coryl 14y ago
        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.
      - jahewson 14y ago
nthitz 14y ago
I'm sure the developers intentions are genuine and that using his DNS records will have no negative effects for users whatsoever.
- schiffern 14y ago
  …not to mention installing an alternate root CA.
deleted 14y ago
[deleted]
mjschultz 14y ago
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.
pilif 14y ago
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.
- dfc 14y ago
  As long as your browser does not pin certificates.
  - pilif 14y ago
    Which safari on iOS doesn't do. Nor does the AppStore app. Obviously. Otherwise, this site wouldn't work
    - dfc 14y ago
      I was referring to the browser sniffing webmail. Is the appstore a browser? I thought it was an application.
      - ary 14y ago
        Applications outside of browsers use SSL.
0x0 14y ago
I'm curious about the anatomy of this hack. 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.
- reidmain 14y ago
  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. Here is Apple's docs on how to verify a receipt http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1 http://developer.apple.com/library/ios/#documentation/Networ...
  - 0x0 14y ago
    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?
    - reidmain 14y ago
      "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.
necrecious 14y ago
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.
- idunno246 14y ago
  Different thing. com.uris requires a jailbreak. Theres a few others out there, as well. I see a number of different styles of invalid ids
xsmasher 14y ago
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.
pooriaazimi 14y ago
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.html 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).
- nulluk 14y ago
  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.
gcb 14y ago
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
thechut 14y ago
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...
darkestkhan 14y ago
Copyright at its finest: ""In-Appstore.com Get in-app ..." This video is no longer available due to a copyright claim by Apple, Inc.."
- verroq 14y ago
  How is this not censorship?
  - linker3000 14y ago
    Maybe Apple have their own video showing how to game their site and this other one is a bit too similar?
  - darkestkhan 14y ago
    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])

112 points by reidmain 14y ago

Apple has a way of validating receipts for in app purchases, see: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html http://developer.apple.com/library/ios/#documentation/Networ... 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 https://github.com/carsonmcdonald/iap-validator for an example.

adjwilli 14y ago
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.
- thoughtsimple 14y ago
  >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.
- conradev 14y ago
  This has already been done in the form of a tweak for jailbroken devices. This only brings it to unjailbroken devices.
thoughtsimple 14y ago
I wonder what popular iOS Frameworks don't validate in app purchase receipts :)
- adjwilli 14y ago
  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.
  - jen_h 14y ago
    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-suffers-in-app-purchase-outage/ 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.
    - flatline3 14y ago
      You're also dependent on Apple's purchasing servers to buy the content to begin with, so I'm not sure I see the point.
  - stock_toaster 14y ago
    I wonder if Apple will start using certificate pinning[1] (like chrome does for google certs). [1]: http://www.imperialviolet.org/2011/05/04/pinning.html http://www.imperialviolet.org/2011/05/04/pinning.html
  - flatline3 14y ago
    Why do you say it's a pain to implement? It's an HTTP+JSON API, and there's only one error code you have to care about: If the value of the status key is 0, this is a valid receipt. If the value is anything other than 0, this receipt is invalid. http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html http://developer.apple.com/library/ios/#documentation/Networ...
gcb 14y ago
How this affect things like buying offline maps for gps? Also that page has an invalid ssl cert :)

danso 14y ago

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.

MaxGabriel 14y ago
It is confusing, I agree. It means "The method doesn't always work because some people have reported it doesn't."
mikecane 14y ago
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.
deleted 14y ago
[deleted]

pdenya 14y ago

I love how they look down on the developer >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.

Jacqued 14y ago
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.
- danso 14y ago
  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?
  - taligent 14y ago
    No. Because you are assuming that the person would have made a purchase had it not been free.
    - coryl 14y ago
      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.
    - jahewson 14y ago

nthitz 14y ago

I'm sure the developers intentions are genuine and that using his DNS records will have no negative effects for users whatsoever.

schiffern 14y ago
…not to mention installing an alternate root CA.

deleted 14y ago

[deleted]

mjschultz 14y ago

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.

pilif 14y ago

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.

dfc 14y ago
As long as your browser does not pin certificates.
- pilif 14y ago
  Which safari on iOS doesn't do. Nor does the AppStore app. Obviously. Otherwise, this site wouldn't work
  - dfc 14y ago
    I was referring to the browser sniffing webmail. Is the appstore a browser? I thought it was an application.
    - ary 14y ago
      Applications outside of browsers use SSL.

0x0 14y ago

I'm curious about the anatomy of this hack. 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.

reidmain 14y ago
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. Here is Apple's docs on how to verify a receipt http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1 http://developer.apple.com/library/ios/#documentation/Networ...
- 0x0 14y ago
  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?
  - reidmain 14y ago
    "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.

necrecious 14y ago

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.

idunno246 14y ago
Different thing. com.uris requires a jailbreak. Theres a few others out there, as well. I see a number of different styles of invalid ids

xsmasher 14y ago

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.

pooriaazimi 14y ago

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.html 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).

nulluk 14y ago
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.

gcb 14y ago

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

thechut 14y ago

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...

darkestkhan 14y ago

Copyright at its finest: ""In-Appstore.com Get in-app ..." This video is no longer available due to a copyright claim by Apple, Inc.."

verroq 14y ago
How is this not censorship?
- linker3000 14y ago
  Maybe Apple have their own video showing how to game their site and this other one is a bit too similar?
- darkestkhan 14y ago
  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])