To say its early days in Mobile is an understatement. To say its early days in Mobile security is (and I know its only January) an early candidate for understatement of the year. Making sweeping statements about Mobile anything is hard. But there are a number of promising green shoots spring up out of the ground in Mobile security. Will these sprouts grow into mighty oaks or get crushed like so many Orange Books before them? Remains to be seen.
One thing most people agree on, for the moment, is that iOS offers better protection than Android. While Android offers a chance at a more secure environment due to its open platform, this is not always realized in end products. Still there is another dimension to the Android fragmentation problem as it relates to security, which I will get to in a second.
Most mobile projects I have worked on start with excellent developers. The company taps their top devs to tackle and deliver on this new iOS or Android future. However, these developers are usually web gurus. Along the way, they realize things are not quite the same in Mobile. Yes there is HTTP but the client and server implementations work differently. There's additional API rework necessary to build out a Mobile middle tier. And oh did I mention testing?
Let's return to the fragmentation issue I mentioned above in the context of a recent year end review post by Dave Aitel:
You know what didn't pan out? "Mobile attacks" in commercial attack frameworks. The
reasons are a bit non-obvious, but deep down, writing Android exploits
is fairly hard. Not because the exploit itself is hard, but because
testing your exploit on every phone is a nightmare. There's literally
thousands of them, and they're all slightly different. So even if you
know your exploit is solid as a rock, it's hard to say that you tested
it on whatever strange phone your customer happens to have around.
And of course, iOS is its own hard nut to crack. It's a moving
monolithic target, and Apple is highly incentivized by pirates to keep
it secure. So if you have something that works in a commercial package,
Apple will patch it the next day, and all your hard work is mostly wasted.
Just like developers learned, the fragmentation issue is a real one for attackers too. Of course, the rising popularity means this is no long (or even medium) term advantage to the defender, but its an interesting marker along the journey. It does infer an answer to the general question what is the worst position to be in? Perhaps a popular Android device with poorly provisioned security. At least for now.
Of course, that is not the worst security posture. The most dangerous posture, we know from Brian Snow is - to assume you are secure, and act accordingly when in fact you are not secure.
I'm in violent disagreement "that iOS offers better protection than Android" and that "a popular Android device with poorly provisioned security" "is the worst position to be in". Can you cite some sources? My experience as a mobile app assessor is the opposite. My experience with large teams of other mobile app assessors also tells me that iOS is much less secure than Android, as well that iOS apps are much less secure than Android ones. The industry-wide DDTS data also tells the same story.
ReplyDeleteYou don't need to test exploits on every device, nor every version of mobile OS. You may need to test your exploits across OSes. Mobile app exploits will end up in FOSS and commercial exploitation engines, as appetites align. Dave Aitel mentioned support of MOSDEF for Android, and somewhat of a desire to implement it for iOS. Meterpreter works on iOS, as seen in the book, "iOS Hacker's Handbook" in chapter 4, and it doesn't even require a jailbroken device. The volatility framework has Android support -- and plans more OSX and iOS support. There will be many platform-independent/browser-independent exploitation engines such as BeEF to go around, as well.
Fragmentation doesn't really exist, at least not with the Android SDK (including the Emulator) and especially not with AOSP devices. There could be issues of porting NDK or non-official-SDK/framework code to non-standard (e.g. AOSP) devices, but that's not what's typically discussed. If exploit writers used the Android SDK, they could use the Android Support Library to solve fragmentation issues just as legitimate appdevs would. For iOS, it's a matter of trolling the officially supported methods and functions to perform system or library call subversive activity that wouldn't be caught by Apple in the App Store -- although certainly there are other ways to get running code on an iOS device outside of the App Store (via personal certs, jailbreaking, Meterpreter, and potentially many other ways).