The thing is, though, it's been my experience that many times the very people who write the apps themselves fail to sufficiently understand and internalize just how the attacks will happen. Sure, we've all read about various hacks, but to many people, those are nothing more than abstract thoughts. When it comes to understanding how someone will attack your work, however, it becomes real. So let's consider that a bit.
Which of the following do you think are likely to happen to your app:
- Do you think your attacker will install and run your app to try to learn how it works? Sure, that's a given, right?
- Do you think your attacker will work his/her way through all the views and data fields in your app, and perhaps try various dictionaries of the big bad boys (e.g., SQL Injection, Cross-Site Scripting (XSS)) and so on? Sure, that too is a given, right? Even if those attacks aren't in any way relevant to the technologies in your app, they're going to try them anyway.
- Do you think your attacker will look through all the files in your app's sandbox (e.g., its ~/Documents folder), looking for potentially damning information like a user ID, password, or session token in a .plist file? Yup. Plenty of tools make that one real easy too.
- Do you think your attacker will configure a network proxy to intercept all of your app's communications to/from its server(s), looking for login credentials, session tokens, etc.? Oh yeah, still well in the realm of feasibility here.
- Do you think your attacker will use that same network proxy to try to get your app to connect to a server that he configures -- perhaps with a self-signed SSL certificate, or with a signed certificate where the root CA has been installed as a profile on the attacker's iOS device? Ruh roh! (Now I'm starting to hear "They can do that?!")
- Do you think your attacker will examine your app's executable file, doing surface analysis of it to look for strings, symbols, and other telltale info in the binary executable itself? Of course. But executables in the App Store are encrypted, you say? On a jailbroken device, an attacker can use a debugger to access the unencrypted executable commands just fine. (They have to execute, after all...)
- For that matter, do you think an attacker will load your app on a jailbroken device, put it into a debugger, and single step through it, looking for crypto keys and other sensitive data? Ruh roh, indeed!
- Do you think an attacker will try to tamper with the Objective C runtime by intercepting messages to/from the various objects in your app?
- Do you think an attacker will attempt to inject messages into your app in that debugging session, and get your app to misbehave?
That list can continue on and on for quite some time. I wrote it in order of increasing attack complexity and difficulty, but every one of these things is achievable today using tools and techniques available to any attacker. This list isn't science fiction or "Hollywood" in any way.
The question you should be asking is whether an attacker would go to this level of difficulty to attack your application. Well, that depends on the potential gain and the likelihood of being caught, among other things.
And on the point of getting caught, your attacker has all the advantages and you all the disadvantages. Every one of these attacks can be done in the safety and comfort of the attacker's "laboratory", with pretty much zero chance of being caught.
What you're left with then is what is the potential gain to the attacker, and that's not something I can answer for you.
What can you do about it? I'll address that in Part 2 of this blog entry within the next few days. And, of course, Gunnar (@OneRaindrop) and I (@KRvW) will be talking about issues like this at our Mobile App Security Triathlon in November.
Cheers,
Ken van Wyk
No comments:
Post a Comment