Mobile: Different or same sh*t different day?

Is 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:

• New threats
• Consumer (threats) jailbreaking
• Access to a physical attack surface
• Native code
• New tools for identity
• Disconnected operation
• The myth of “low power” and “limited battery”

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:

• You can’t trust the client
• Server / WebAppSec

New threats

I’ve already covered new threats in a previous entry. 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 other’s 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.

Native code

Native applications represent another key technology difference. The browser and its tech stack confine web-based applications to languages like JavaScript and suffer limited access to the underlying OS. This means mobile applications can interact with the network stack, file system, and other OS services (calendar, address book, etc.) directly. Yes, apps need permission to conduct these operations, but it’s been widely shown that consumers gleefully and ignorantly grant this permission. It’s also been shown that apps request overly broad permissions, increasing the impact of luring attacks.

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 metadata. 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. Though these controls aren’t unique to the mobile platform, the dramatically shorter product life cycle (compared to Windows XP) makes availability of these controls greater than in the desktop-based world.

Identity

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 endpoint 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–1,000 factors towards endpoint identification!!!”

How many new factors are these toolkits providing? The old stalwarts are:

• Something you are
• Something you have
• Something you know

Maybe we’ll see effective:

• Somewhere you are
• Some ways in which you typically behave

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

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 five to seven 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.

Sameness

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. 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.

WebAppSec hygiene

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.

Summary

Acquiring organizations and mobile development shops must adapt to address the differences in security posture of mobile platforms. Likewise, remembering and applying the lessons learned during the WebAppSec and client-server eras is equally important.