

Apple’s in-app purchasing process circumvented by Russian hacker - reidmain
http://9to5mac.com/2012/07/13/apples-in-app-purchasing-process-circumvented-by-russian-hacker/

======
pilif
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
As long as your browser does not pin certificates.

~~~
pilif
Which safari on iOS doesn't do. Nor does the AppStore app. Obviously.
Otherwise, this site wouldn't work

~~~
dfc
I was referring to the browser sniffing webmail. Is the appstore a browser? I
thought it was an application.

~~~
ary
Applications outside of browsers use SSL.

------
carson
Apple has a way of validating receipts for in app purchases, see:
[http://developer.apple.com/library/ios/#documentation/Networ...](http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html)

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.

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

------
pooriaazimi
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...](http://corte.si/posts/code/mitmproxy/tute-
gamecenter/index.html) , 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
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.

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

~~~
eli
Can we just skip the debate over the definition of stealing? It's tedious and
pedantic, and I don't think it's very enlightening for anyone.

~~~
sigkill
I agree. I think a lot more of us would be on the same page if we accepted
that the developer is being deprived of a sale.

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

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

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

~~~
sigkill
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."

~~~
mikeash
Yes, they weren't entitled to use it. Yet they do use it. So what to do? It's
_not_ a lost sale just because they're not entitled to use it.

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

------
0x0
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
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/Networ...](http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1)

~~~
0x0
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
"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.

~~~
0x0
Sounds plausible.

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?

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

------
darkestkhan
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
How is this not censorship?

~~~
linker3000
Maybe Apple have their own video showing how to game their site and this other
one is a bit too similar?

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

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

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

~~~
schiffern
…not to mention installing an alternate root CA.

------
danso
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
It is confusing, I agree. It means "The method doesn't always work because
some people have reported it doesn't."

------
gcb

       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

