Posted by John Steven on April 30, 2013
Mobile security the ‘same problem’ as web application security? Is it just ‘different day’? I’ve watched organizations and mobile thought leaders argue perspectives on this question back and forth for years. The answer is, of course: both. Mobile security inherits previous problems and solutions while bringing its own unique ones. Let’s get specific about what’s different and why. I’ll break things down as usual: threats, attack surfaces, vectors, impacts, and then controls. Summarizing:
It’s important to tackle the aspects of mobile platform that remain surprisingly similar to previous architectures. Ignoring their majority, we’ll cover those that continue to surprise organizations:
I’ve already covered new threats in a previous entry, find it here: New Mobile Threats. Remember, threats are people/organizations (or malware) executing on behalf of those agents. And, yes whole new threats exist. Summarizing two key classes: first, thieves. Whereas it would have been challenging for bad actors to yank someone’s desktop sitting in their home office, there are many vectors through which mobile devices can be stolen. Second, several owners share stakes a single mobile device: handset manufacturers, carriers, app-store curators, consumers, and sometimes organizations for which the consumer works. These different stakeholders see mobile assets and their security very differently from each other and can be at odds with each others security and especially privacy goals. As such, they act against each other at times.
Application publishers face their own consumers as threats. An alarming number of these consumers jailbreak their own device, disabling or disrupting the effectiveness of the security controls on which application depend.
[New Attack Surfaces]
Attack surfaces have changed too. Software written for web services and browsers don’t have to worry as much about threats gaining physical access to a client’s device underneath their (often browser-based) software.
There’s oodles of attack surfaces available to mobile attackers not available to threats targeting a victim’s browser as well. Various Radios (carrier, 802.11, BT) and USB interfaces allow threats with physical access to the device to tunnel beneath applications and either leverage (or exploit) the underlying OS. Browser and desktop OS exploits, of course, allowed this as well but mitigating factors, such as the lack of physical access, made this more difficult.
Yes, sandboxing exists, as it does in browsers. However, increased access to the underlying runtime/OS, poor programming practice in other apps, and permissive policy can easily thwart the sandbox’s intended purpose.
Two sidebars: First, though it hasn’t been exploited to the extent possible, the popular platforms’ binary formats provide a really interesting set of attack vectors associated with annotations and meta-data. Second, cross-platform mobile development toolkits and platforms seem to be gaining prevalence in a way similar browser-based tools did not. I predict that, ultimately, organizations will realize that the “write once test everywhere” they suffered with Java is nothing compared to that they’ll experience with these toolkits–so I won’t cover the unique issues this approach introduces here.
On the other hand, controls such as ASLR and DEP provide protection against weaponization of key vulnerabilities that might result from native apps on the IOS platform. Those these controls aren’t unique to the mobile platform, the dramatically shorter product life cycle (compared to Windows XP) make availability of these controls greater than in the desktop-based world.
The next key difference is the opportunity mobile provides identity. Many years ago, forward-thinking providers of web-based applications sought ways to better-identify their clients beyond UN/PW. Organizations and vendors tried a variety of approaches. The best approaches required installation of native browser plugins (such as ActiveX) and access to the underlying OS. In addition to the dangers this introduced, users roundly rejected this approach. We were then left with browser fingerprinting–a decidedly disappointing approach. Our consultants have been able to successfully circumvent this control in an overwhelming majority (if not all) systems we’ve assessed.
The previous difference, native application code, allows organizations and vendors, such as InAuth, to take another run at a high-quality end-point fingerprint. This is not a panacea though. I predict these vendors’ approaches will devolve into a cat-and-mouse game with Threats and I desperately hope that organizations don’t put undue faith in identity resolved solely from these tools. We’re already seeing a ridiculous “factors” arms race: “We provide NINE (9) factors towards endpoint identification!!!” “Oh yeah? We provide 500-1000 factors towards endpoint identification!!!”.
How many new factors are these toolkits providing? The old stalwarts are:
Maybe we’ll see effective:
I mused to a former colleague of mine that I’m holding out for “Something I ate” but there are obvious drawbacks to this factor. In the meantime, we’re left with marketing buzz that equates duplicate application of one of the above factors to a ‘new’ factor.
Back to business: organizations will have to figure out how to effectively use identity products effectively and as part (not the entirety) of their security design.
Disconnected operations is the final difference I’ll cover (but it by no means finishes this as an exhaustive list). An expectation (perhaps more perceived than actual) for disconnected app/service operation has driven organizations to export far more data and functionality to their mobile clients than they felt comfortable doing for their web apps. This surprises me given the work that these same organizations put into data sensitivity classification and entitlements over the last 5-7 years.
Because the mobile client remains untrusted, just as the browser, this poses difficult (and impossible) challenges to app/service design. Two major design problems have emerged at the forefront. First, mobile architects are beginning to realize that keeping services safe means providing a separate access point and facade for mobile services from their SOA for middleware and web-based clients. Second, architects have begun to build a toolkit of secure storage for mobile devices. We’re helping organizations combine use of the tools within this kit as appropriate to the data/functionality being protected.
One unique aspect of mobile development seems to have faded from view: “low power CPUs and short battery life”. Five years ago organizations complained bitterly about support for feature-phones and an inability to conduct high-quality authentication or encryption operations on-device.
Yet, despite the differences outlined above, many similarities between the mobile platform and web-based (or client-server) architectures exist. Too many similarities exist to enumerate. Let’s cover some those that surprise organizations.
[You can’t trust the client]
No, you can not trust the client. No. *pause* No. Gary wrote up our “brain in the vat” conversation and he’s right. Both applications and services must account for the fact that information they receive from a mobile device may be incorrect or malicious. This means mobile app development must build “trusted on busted”.
Container solutions (such as MDM), app deployment toolkits (such as those that apply obfuscation/encryption), and mobile device agents all back-out to a cat-and-mouse game with threats. They can (and will) be defeated.
This does not mean that these tools are useless. Applying these controls, especially in a network of reinforcing controls (as Arxan’s toolkit allows) may significantly raise the bar against a variety of threat classes.
It continues to amaze me how many classic WebAppSec vulnerabilities our consultants find when assessing mobile apps and their backing services. I suppose this shouldn’t surprise me: we moved onto mobile development without having eradicated web services’ problems. Please, please: when you build and deploy a mobile application make sure you’ve done everything you would have done as part of your secure SDLC for a web application.
Acquiring organizations and mobile development shops must adapt to address the differences in security posture of mobile platforms. Likewise, failure to remember and apply the lessons learned during the web-app-sec and client-server eras is equally important.
Get the latest Software Integrity news, thought leadership, and more.