Posted by david b.
on August 31, 2012
Architectural essentials of Apple AppStore
AppStore and iTunes security flaws
MITM attack workflow and consequences
The Search field on Apple.com domain’s front page actually had cross-site scripting.
Non-customized vanilla for iOS appliance has security flaws as well
Even the standard web security wasn’t really done right, they have insecure cookies that get leaked over HTTP when you surf, so it’s not strictly HTTPS only. You can take over simply sessions because the tokens are not solid. You have cross-site scripting all over the place. And there’s this whitelist that says: “Those domains can install software on your device, and those domains can actually charge you”. This whitelist, of course, includes HTTP-only sites, and from anywhere in the world, from any web page in the world, you can just redirect the browser to itms-apps://xss.url, and that essentially fires the AppStore app. So first of all, you can start this AppStore app. Now, the only thing you need is control over something that’s in the whitelist. What do we call that in security terms? Cross-site scripting
. So what did we do? We looked for XSS on Apple.com domain, we went as far as the first front page because the Search field actually had cross-site scripting.
Arbitrary app installation using XSS
So, XSS in the Search field – are you kiddin’ me? Yes, that’s the way it is. And then, on a same regular browser now you would have the issue of injecting all the code that is needed to download, buy and install an application. A regular browser just ignores stuff that’s in a data:URL. And in data:URI you can actually encode the content right in the URI; the same browser does not use that as a source for an iFrame for example.
Search field on Apple.com exploited with cross-site scripting
Now, the thing is the AppStore app isn’t the same browser, so what you can actually do is you can create a very long data:URL that you put into this cross-site scripting, and encode all the stuff that is needed to buy, download, install and run an application. This is how that looks (see image to the right)
. You build a regular link, it could be auto-forwarding or whatever; and then you base64 encode everything in here, and that actually buys and installs an application. Now, when we told Apple about this, guess how they fixed it. They fixed the cross-site scripting. So if you want to use that same attack today, you need to find a cross-site scripting
anywhere on Apple.com – and you’re good. They only fixed the XSS in the Search field and were done with it. Okay, well, that’s a way to go.
Pitfalls of using Apple devices
What that means is, obviously, Apple has a lot of power about your devices, and if you’re using those devices – fine, but keep in mind that because there’s someone controlling the content and the availability of applications, they control your view of reality on that client platform. So unless you have another computer (real computer), that is actually a lot of control of your reality view. For the attacker, it just means physical access is always gonna be a bitch, like there’s no damn way that Apple in a foreseeable future will secure the devices against physical access. And also, don’t be surprised if you have more applications installed after you visited Starbucks than you had before. It’s just too easy to do.
Read previous: Apple vs. Google Client Platforms 2: Apple iPad Security Architecture
Read next: Apple vs. Google 4: Chromebook Security and Integrity Protection
Like This Article? Let Others Know!
Comment via Facebook: