- Posted by Sergei Frankoff 12 Mar
- 0 Comments
So back when iOS 8 beta 2 was released there was a lot of hype over the fact that Apple had finally blocked automatic redirects to the App Store from ads in Safari . So much hype, in fact, that noted security-talking-head Dan Kaminsky decided to offer up a $5,000 bounty for a bypass.
BTW, I <3 Bug Bounties now, so @WhiteOps is offering $5K to the first to bypass Apple's Safari->AppStore block in iOS8 (beta).
— Dan Kaminsky (@dakami) August 9, 2014
Now that iOS 8 is well out of beta and on version 8.2 it is not clear if this feature even made it into the full release. We couldn’t find anything in the release notes but there do seem to be less annoying redirects… less, not none. Maybe this is a result of some new restrictions in Safari on calling the app store via the “itmss” (or “itms-appss”) handler from inside an iframe or maybe it’s just ad-exchanges restricting these types of calls in the creatives (ads) they distribute. Either way there seem to have been some controls introduced to manage this problem.
Here at Sentrant we are continuously monitoring ad delivery as part of our real-time fraud detection platform. In addition to deterministic fraud detection signatures we also have the capability of deploying behavioural correlation signatures. We generally use the behavioural signatures when we want to research an emerging trend in ad-fraud as they have the added benefit of recording the full end-to-end ad transaction. Recently we were researching an (unrelated) case of mobile app fraud where one of the behaviours we wanted to identify was the infamous automatic App Store redirect. We developed a proof of concept (POC) of how we would implement the redirect (based on iframe busting) and then developed a behaviour signature based on the POC. Within a short period of deploying our signature, we detected the following automatic redirect.
We dug into the data and quickly identified the culprit; we were even lucky enough to be able to re-target an iPad, visit the site that was serving the ads, and capture the whole thing on video.While this is not ad-fraud, it is an interesting example of advertisers circumventing ad controls and we think it is useful to expose how this was accomplished. The details of how the ad eventually delivered the App Store redirect are complicated and obscure how the redirect was accomplished. In order to clarify, we have pulled out the relevant parts and described them below. If you are interested in the full details of the redirect we observed in the wild please contact us and we will be happy to share.
Components of the Redirect
Protocol handler for itmss (or “itms-appss”)
The itmss:// protocol is used to indicate the protocol handler required in the iTunes app. What this means is when Safari encounters a link with the protocol itmss:// it knows to open the link using the iTunes app (this also redirects to the App Store on iOS). Traditionally if you wanted to add a link on your website that would take the user to your app in the App Store you could use this protocol. Unfortunately since Safari automatically loaded these links in the App Store and there were no iframe restrictions on the protocol, advertisers began adding these links into their ads so when the ad loaded in Safari (on iOS) the user would be automatically redirected to the App Store. The itms-appss:// protocol operates in a similar way, the distinctions between these protocols are not relevant for this article. By restricting the use of these protocols inside an iframe, either with Safari or at the ad-exchange, this frustrating experience can be minimized.
Loading itmss Protocol From Iframe (Frame Busting)
Now that we know a way to get the itmss protocol handler instantiated and redirect the user to the App Store, we just need a way to do this from within an iframe (ads are loaded in iframes). Instead of trying to load the protocol inside the iframe let’s try loading it from the parent window.
Redirect Delivery Chain
When we load the Slate.com page there is an iframe at the top of the page that loads an ad for a Zynga app called “Wizard of Oz Slots Free Casino”.
As the ad is loading in the iframe the following sequence occurs; Slate.com loads an iframe from AppNexus.
The AppNexus iframe loads a second iframe from Clove Network:
The Clove Network iframe loads the following html document:
The ads.glispa.com URL follows a series of 302 redirects (not shown here) and finally redirects to itms-appss://itunes.apple.com/app/wizard-of-oz-slots-free-casino/id916869395 using the protocol handler for iTunes which will automatically open the App Store and display the Zynga app (id916869395).
Summing it All Up
It is a novel effort on Apple’s part and the ad-exchanges to try and put an end to this unpleasant experience but given the nature of the problem this is going to continue to be a cat-and-mouse game where advertisers find new ways to circumvent the restrictions. This particular redirect is currently being used in the wild by Zynga to redirect users to their apps in the App Store from their ads.
We notified AppNexus and they have pulled the offending ad and are looking into permanently preventing this.