Quantcast

Apple vs. Google 3: iPad Hack via Cross-Site Scripting

Felix ‘FX’ Lindner talks here about how iPad owners might get their devices exposed to third-party access while using the AppStore client, due to JavaScript implementation drawbacks and cross-site scripting.

Architectural essentials of Apple AppStore

Architectural essentials of Apple AppStore

Now, to the more fun part. What does the AppStore client actually look like? What is it architectural-wise? Essentially, it’s WebKit – well, fair enough; a lot of JavaScript; a whitelist of domains that can install stuff on your device; a little bit signed stuff like signed PLIST/XML – entitlements, widgets, it’s covering all that.

AppStore and iTunes security flaws

AppStore and iTunes security flaws

So let’s concentrate on the main thing. If you build a custom JavaScript library around WebKit, you essentially build a browser. The security model of the browser heavily depends on the fact that the user has a browser UI, so you can actually see if the site that you’re surfing at actually says HTTPS and not HTTP. It depends on you seeing that there is a pop-up coming from JavaScript and not from the browser. Well, that’s not the case if you are building an AppStore application and just, you know, bake in standard web security stuff and think this is going to work. But that’s exactly what Apple did.

MITM attack workflow and consequences

MITM attack workflow and consequences

So if someone sits, let’s say, at Starbucks and doesn’t realize that he’s just paying $4 for 80% hot water, and he’s surfing around with his Apple device, you can just man-in-the-middle his connections. And anytime he hits Apple.com or other Apple pages, you can just inject JavaScript like iTunes.buyAction(…) which, as you would suspect, can be used to buy shit in the AppStore. So there’s a CSRF Token which is there to prevent you from doing that stuff, however it’s so ‘nicely’ coded that whatever you inject, the requests that come out afterwards will actually auto fill in this token for you.

Browser dialog simulation using JavaScript

So the programmer of the AppStore JavaScript doesn’t have to remember that there is a token to be passed. That’s pretty hard to fix actually, because that’s the client side and the server side being broken at the same time. So you can do simple things like this. This looks pretty normal on an iPad – so “Please give me your Apple ID”, the difference being that because that’s not a browser, it doesn’t tell you that this was actually produced by a little piece of JavaScript that you just injected. Note there’s going to be a difference on a real browser; Windows would say: “This is a JavaScript message box”. Here, it just looks the same as the legitimate one.

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

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

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

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

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!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *


5 + 8 =

Comment via Facebook: