Hacker News Reader

Comment by 0x0 | Hacker News Reader

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.

View on HN

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

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.

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?

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.

Reply on news.ycombinator.com