Figure 1-1 A typical mobile threat graph produced by industry
Mobile malware, BYOD, lions, tigers, and bears, oh my. Where to start with mobile security? Is mobile an entirely new paradigm that should cause us to reevaluate everything we’ve tried before? Or just a more aggressive flavor of client-server computing? Naturally inclined to fear, uncertainty, and doubt (FUD)—and to selling you more products—the technology industry won’t provide a compelling answer. Neither will its distant cousin, the security industry. We’ll try to disentangle the lies and videotape in this chapter.
A famous line from Aladdin, one of our favorite movies is: “Phenomenal cosmic power—itty bitty living space.” This describes the mobile ecosystem exactly. Perhaps at no other time in the history of computing have we crammed so much into such a small form factor: powerful processors, portability, features (cameras, GPS), email/web, apps, all hyperconnected to ubiquitous over-the-air (OTA) communications networks (both wide area networks like cellular, and close-in networks like Bluetooth). The ad copy is true: mobile is a game-changer in many ways. Let’s take a look at some of the key elements of the phenomenon.
We’re awash in statistics about the scale of the mobile phenomenon. Here’s a handful of example stats from the mobile marketing site mobithinking.com:
• >300,000 Mobile apps developed in three years (2007–2010)
• $1 billion Mobile startup Instagram’s value within 18 months
• 1.1 billion Mobile banking (m-banking) customers by 2015
• 1.2 billion Mobile broadband users in 2011
• 1.7 billion Devices shipped in 2012 (an increase of 1.2 percent over 2011)
• 6 billion Mobile subscriptions worldwide (China and India account for 30 percent)
• $35 billion Estimated value of app downloads in 2014
• 76.9 billion Estimated number of app downloads in 2014
• $1 trillion Mobile payments (m-payments) estimated in 2015
• 8 trillion Estimated number of SMS messages sent in 2011
Judging by the sheer numbers, mobile is a tidal wave that is flooding into every aspect of our lives. But you don’t need cold, dry statistics to prove this—you almost certainly own a mobile device and probably several. And you rely on it heavily each day, for things ranging from the critical to the sublime: emergency phone calls, important communications (voice, text, email), getting to appointments on time using calendar and location services, keeping up relationships through Facebook and Twitter, playing games like Angry Birds, watching movies and TV, reading newspapers and magazines—we do nearly everything on mobile devices today, and it’s hard to imagine how we could live without them.
We could go on, of course, but there are plenty of other sources for exploration of the mobile phenomenon in general, and we’re here for a more limited purpose: to talk about the security implications of all this seemingly good stuff.
OK, so it looks like this mobile thing is pretty important. It is arguably one of the most important developments in technology since the Internet. Unfortunately, as with the Internet, security seems to have been an afterthought.
Every day you are probably bombarded with information that overwhelms and frightens you. Here are some examples:
• McAfee’s quarterly Threats Report indicated that mobile malware exploded 1,200 percent in the first quarter of 2012 over the last, or fourth, quarter of 2011.
• Trend Micro predicted 60 percent month-on-month malware growth on Android in 2012.
• IBM X-Force predicted that in 2011 “exploits targeting vulnerabilities that affect mobile operating systems will more than double from 2010.”
• Apple’s iOS had a greater than sixfold increase in “Code Execution” vulnerabilities, as tracked by CVE number, from 2011 to September 2012 (nearly 85 percent of the 2012 vulnerabilities were related to the WebKit open source web browser engine used by Apple’s Safari browser).
These sorts of “sky is falling” trend reports are expected when technological change occurs at the scale of mobile, of course. We’ve come to appreciate them and have drawn our own stereotypical replica in Figure 1-1.
Figure 1-1 A typical mobile threat graph produced by industry
Lions, and tigers, and bears, oh my! How can these pesky mobile devices be so darn popular if the security is so bad? Let’s pop the hood and take a look at the mechanics of the mobile risk ecosystem.
OK, so far we’ve established that
• Mobile is huge.
• Mobile seems really insecure.
What do we do now?!?
Here’s what may be a shocking answer: the same thing we’ve done before! Despite all the hype, we submit that mobile is “the same problem, different day.” Fundamentally, we are still talking about a client-server architecture:
OK, we may have exaggerated a bit, but not much. Let’s enhance this over-simplified view with a bit more detail. Consider, from the client’s perspective, the classic 3-tier architecture that we used throughout the ’90 s and ’00s modified to be a mobile architecture, as shown in the next illustration:
The diagram highlights the differences, numbered and described here:
1. Native code Native applications may be written in languages that execute without the benefit of a virtual machine or rigorous sandbox. These applications may be written in unsafe languages (for instance, Objective-C) and have increased access to other apps and resources as compared to browser-based apps. Even when mobile platforms implement app sandboxing, the user is quickly coerced into granting broad and powerful permissions that easily bypass much of the platform-provided controls.
2. OS access Software running in a browser has limited access to the underlying OS, its libraries, file system access, interprocess communication, and its system calls.
3. Internet access Whereas home PCs, and to an extent laptops, often connect from a home network, mobile devices commonly use their mobile carrier’s network and public WiFi to connect to the Internet. These means of access may provide increased opportunity for man-in-the-middle (MiTM) attacks.
As you’ll see throughout this book, most threats against mobile apps are variations on MiTM, whether it be MiTB (browser), MiTOS (operating system), or good old-fashioned MiTM (network) as we’ve noted. This is a natural consequence of the mobile model from the app perspective—it’s surrounded by hostile (or at least semitrusted) software.
We must start by reusing the many lessons we’ve learned to date about securing distributed computing systems. Not that we’ve really implemented them well (take the continued widespread use of the lowly password as one example), but that doesn’t mean we should throw the baby out with the bathwater. We’ll apply what we learned in securing previous architectures while pointing out the specific differences of architectures involving mobile devices.
One might call this approach sticking to the fundamentals. The fundamentals are the things that previous generations have learned that have stood the test of time and persist to this day because they tend to work better than other approaches.
One our favorite fundamentals is that security begins with understanding the risk model. We’ll look at mobile threat modeling in more depth in Chapter 8 and expand on these themes later in this chapter, but here’s a short preview.
Understanding the risk model means first asking the question: Who are the stakeholders? This is another key realm in which mobile platforms introduce new considerations. Numerous stakeholders are vying for control of the itty-bitty living space on the typical mobile device, including:
• Mobile network operators (MNOs, aka carriers, telcos, and the #$%&* companies who drop our calls all the time)
• Device manufacturers (aka OEMs, hardware manufacturers, and so on)
• Mobile operating system (OS) vendors like Apple and Google
• Application Store curators (for example, Apple, Google, Amazon, and so on)
• Organizational IT (for example, corporate security’s mobile device management software)
• Mobile application developers
• End users
This list shows various stakeholders interested in a single user device. For iPhones, Apple serves as the curator, manufacturer, and OS author. Devices running Android often possess more stakeholders.
Once we understand who possesses a stake, our next question is, What items are valuable to these stakeholders? (We call these assets.) Interestingly, each stakeholder places different values on assets within the mobile device. For instance, the OS manufacturer looks at all applications as a threat. The phone’s user is a threat to the OS as well; they may try to jailbreak the phone as soon as they get it home. To the phone’s user, however, the OS may be a threat, violating their privacy by capturing data and exporting it for “statistical purposes.” Applications preloaded by the MNO could be perceived similarly.
Threats attack each stakeholder’s assets by interacting with attack surfaces. Browser-based Internet applications mostly confine the attack surface to the Internet connection itself, a server’s data stores, or a browser’s rendering and scripting engines (also remember that most mobile development frameworks define mechanisms for displaying web views just like a browser, embedded relatively seamlessly within native apps). Applications built for mobile devices share these surfaces but add a few special ones, as shown in the next illustration:
This illustration contains some attack surfaces specific to mobile devices:
• Physical theft allows access to the user interface, physical storage, the IO bus, and the radios. The opportunity for a threat to gain access to a physical device probably represents the singular largest difference between mobile devices and other client endpoints.
• App publication allows the threat to distribute either a Trojan horse application or other malware centrally with an appearance of legitimacy based on the curator’s endorsement. And, as we already mentioned, the threat’s app may have relaxed access to OS resources, interprocess communication, and an unsandboxed environment with which to attack its victim, depending on the state of the mobile platform (jailbroken/rooted), weak app permission configuration, end-users’ over-permissive settings, and so on).
Given the available surfaces, we ask a third fundamental question to complete our risk model: what risks are relevant to these assets from each stakeholder’s perspective? Only from these fundamental premises can you adapt your design and development process to mitigate these risks.
You may have different names for this process: risk modeling, design review, architecture risk analysis, threat modeling. We’re not going to quibble with terminology here, only seek to illustrate the fundamental role of risk in the security conversation.
Once you’ve established the risk model, you can design against it and more rationally adapt downstream processes (for example, check implementation using things like code review and penetration testing). You also need to learn from the process and ensure people are trained so they don’t keep making the same mistakes. This starts to look like a “security in the development lifecycle”–type process at some point, as illustrated in Figure 1-2.
Figure 1-2 The key to security is first understanding the risk model—from there, you can more rationally adapt downstream security processes.
Because the risk model is the most important thing, let’s take a high-level overview of the mobile risk environment. What are some of the things we can say about the mobile risk model in general?
Even though we believe things have not fundamentally changed, some things are different on mobile. Clearly, the client-side threat model is much more aggressive, given the promiscuous exposure to communications (wide area and close-in), physical access, plus the usual software attack and exfiltration vectors like email, mobile web, and apps.
And the impact of compromise is much more “personal”: location, camera/photos, instant messaging—there are plenty of embarrassed public figures who can attest to this. Can Weiner have been a more unfortunate surname? (Sorry, we couldn’t resist.)
Phenomenal cosmic power … itty bitty living space.
But once again, this does not mean that the task of securing mobile is fundamentally different. It just means you have to understand the changes to the risk model and be able to communicate them clearly to stakeholders, with practical mitigations in hand. Same ol’ job, different day for you old security pros out there. We’ve already taken a high-level overview of the mobile threat model, so let’s take a deeper look at some more specific differences.
Figure 1-3 shows our idealized mobile application ecosystem. Of course, any “real” risk model is going to be customized for the given scenario. This is a generic model to highlight some of the things we’ve observed in our consulting and research. Let’s talk about some of these areas of risk in greater detail next.
Figure 1-3 A simplified mobile risk model, highlighting key areas of risk, each containing discrete mobile risks
Risk Area #1 in Figure 1-3 illustrates one truth we continue to relearn as an industry: physical access to the device is impossible to defend against for very long. The whole rooting/jailbreaking phenomenon proves this in spades. Neither Google nor Apple (two very successful companies) have yet to prevent this because it is very hard and probably impossible. In our consulting and research, we have yet to find a mobile app that we could not defeat given physical access, including many rudimentary “anti-rooting” mechanisms and even mobile device management (MDM) software. If your mobile risk model assumes that information can be securely stored indefinitely on a mobile device, you are probably starting from faulty assumptions and will have to relearn this painful lesson the hard way if there is ever a breach. This entire book is infused with the basic assumption that physical compromise is a high-probability outcome, and you will see each of the chapters reflect this immutable fact.
We hold these truths to be self-evident: Immutable Laws of Computer Security #3 states “If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore,” technet.microsoft.com/en-us/library/cc722487.aspx.
Back in Figure 1-3, physical attack is represented by the cable attached to the bottom of the phone, representing the stereotypical “debug” connection that we’ll talk about often throughout this book, illustrating time and again that such intimate access to the device and the software on it usually means “game over” for the owner of the device and any sensitive data stored on it.
One often overlooked corollary of this principle is that close proximity to a mobile device is effectively the equivalent of a physical attack. In other words, if an adversary can get close enough to you with a rogue cellular base station, your phone will join his rogue cellular network, and he owns your device at a very low layer (probably completely). There is nothing you can do about this today, other than put your device in Airplane Mode and use it like an expensive, unconnected brick. In Figure 1-3, we represent this risk as #4, next to the “Baseband” stack of radio chip hardware and firmware, driving everything from cellular network connectivity to WiFi to Bluetooth, GPS, Near Field Communication (NFC), and so on. We’ll discuss the rogue cellular base station attack more in Chapter 2.
Moving on to Risk Area #2 in Figure 1-3, where does the next major area of risk arise in the mobile ecosystem? Not where you might expect…
Naturally, most of the attention on mobile focuses on the mobile device and associated client-side software. Contrary to this focus, we actually observe more problems on the server side in our consulting and research. For example, on a recent long-term consulting engagement, ~65 percent of bugs were service-side versus ~25 percent on the mobile client.
Of course, most of the code/logic is on the server side also, so this is not unexpected. Also, if you’ve designed things correctly, that’s where the valuable data resides anyway. Attackers go “where the money is” à la Willie Sutton, the notorious bank robber who is rumored to have answered “because that’s where the money is” when asked why he robbed banks. We’ve highlighted generic service-side risk as #8 in Figure 1-3.
Another often overlooked aspect of modern Internet-based applications is customer support. This oversight is unfortunate because a modern Willie Sutton probably would’ve gone after it with a vengeance: by design, support helps people regain access to their valuable stuff—a hacker’s dream come true! Some of the most devastating vulnerabilities we’ve seen in over 20 years of experience has resulted from support-related issues like customer self-help password reset; if you make a mistake here, the consequences can have a huge impact. Imagine a flaw that allowed anonymous attackers to reset account passwords via the self-help web portal—get the picture? In the consulting engagement referenced previously, about 12 percent of bugs were in support-related components. However, these tended to be the highest risk: customer password reset vulnerabilities similar to the one we just mentioned. We’ve numbered this risk #9 in Figure 1-3, right next to the smiling, ever-so-helpful customer support agent.
For a real-world example of what can go wrong with these interrelationships, see Wired reporter Mat Honan’s nightmare story about how hackers from Lulz leveraged customer-support trickery to social engineer their way into his Gmail account and then pivoted through his Amazon data; remotely erased all of the data on his iPhone, iPad, and MacBook; and hijacked his Twitter account (see wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/).
This is such a recurring and important problem, we’re doubling down: for another real-world example of a horrible customer support vulnerability, see The Verge’s (theverge.com) March 2013 report on a serious vulnerability in Apple’s iForgot self-help password reset tool that allowed anyone with your email address and date of birth to reset your password. Ouch.
If there is a silver lining on the service-side, the good ol’ security gateway still performs well to protect Internet-facing services. In particular, we have seen products like the Vordel Application Gateway (vordel.com) effectively protect mobile service XML endpoints from skilled penetration testers. You should definitely consider products like Vordel as part of your mobile application security architecture.
Last but not least in our ranking of mobile risks, we come to the real interface of rubber and road: mobile apps.
Applications (interacting with platform features) are the primary attack surface on the mobile client. After all, the apps and the mobile OS are the primary touch points for end users and other software, so this is where all the trouble occurs.
The centrality of applications in today’s mobile risk model in some ways mirrors the evolution of security on other platforms like the desktop PC: early attacks focused on the network layer and then migrated to the OS (and especially the most popular ones, for example, Microsoft Windows). More recently, we’ve seen larger numbers of published exploits in desktop applications, like web browsers, Adobe Acrobat, and Microsoft Office. At the pinnacle of this evolution, we see attacks against “Layer 8,” in other words, the human beings operating the technology. Socially driven attacks like phishing represent this trend.
With mobile, the relative scarcity of lower-layer published exploits indicates vendors are reusing what they’ve learned about network and OS security. However, the Layer 7 and 8 problems continue to be difficult to conquer, even on mobile. Perhaps even especially on mobile, given the closer intimacy between users and applications than in the desktop example. One obvious consequence of always-on network connectivity is that it connects everyone—to your phone. This is not always a desirable thing, as one possible definition of “everyone” could include the character in Figure 1-4.
Figure 1-4 The Internet connects everyone—to your phone. This is not always a Good Thing™.
In fact, so many people are constantly reaching into your mobile phone, that it’s probably hard to tell which ones are friendly, even if they told you right up front. Should you allow Google Maps to track your location? Do you want Cisco’s WebEx mobile app to load when you click a link in a calendar invite? Should you click the link in that SMS from AT&T telling you your mobile bill is ready?
One would hope for a straightforward solution to sort all this out in a way that results in a safe mobile experience. Fat chance—because mobile is moving so fast and because there are such large numbers at stake (see the stats at the beginning of this chapter), no one in the industry is really taking the necessary time to do that. Let’s take a look at some common mobile application security issues as examples.
One security fundamental we’ve learned over the years is that quickly patching vulnerable systems usually reduces risk from easy compromise by folks trolling the Internet with home-grown malware that exploits unpatched, well-known vulnerabilities. Unfortunately, patching your mobile software is challenging owing to one of the key features of the current market: fragmentation.
Fragmentation results from one of the age-old debates in the technology industry: open versus closed platforms. We are seeing this play out again in the mobile device space between today’s two biggest competitors, Google and Apple.
At the time of this writing, even folks like renowned mobile hacker Charlie Miller are admitting that Apple iOS is much tougher to victimize because of the rigid controls built into the platform: code must be signed by Apple in order to run, address space layout randomization (ASLR), better code sandbox, no shell, and so on. On Android, by contrast, the need to develop custom OS versions for each device manufacturer creates fragmentation that leads to negative security consequences. For example, upgrading to the newest version of Android depends on collaboration between the device’s hardware vendor and the mobile network operator (MNO), which limits access to new security features like ASLR and makes distributing security patches and other important updates that much harder.
The “closed” Apple platform carved out an early lead in overall smartphone market share. Possibly by design, arguably as a side effect, the security record of Apple devices remains good. By contrast, the security record of the open Android platform is poor, but it has nevertheless quickly become the leader in market share probably because it has the mathematical advantage of numbers (Google, Motorola, Samsung, HTC, LG, and so on, versus lonely Apple).
We’ve seen this movie before. Microsoft came to dominate the personal computing market by licensing its operating system to multiple hardware vendors, even though it suffered from a very poor security reputation. Apple ended up marginalized despite a reputation for high-quality, well-integrated hardware and software design.
We are watching a market mature all over again—consumers today tend to be more accepting of bleeding-edge features and faults, and security is an afterthought. The fact that many Android and iOS users root/jailbreak their phones is a prime example of the immaturity that persists in the market. Microsoft just culminated a decade-long effort to drive PC users not to log in with high-powered administrative accounts. Many variables are different today, but the comparison is interesting…(and we are certainly not the first ones to make it). As the market matures will the ultimate winner be the higher quality, more controlled, secure experience?
One thing is somewhat different from the past: app marketplaces like the Apple App Store and Google Play. These centralized app delivery mechanisms are, once again, driven not by security, but by the desire to control the user experience, attract developers with simple distribution models, and monetize software downloads to devices. But whatever the motivation, the result is that there is a central app-patching “channel” through which (disciplined) developers can easily send regular updates to their code, including security patches. Not even the PC has achieved this sort of centralized catalog of third-party software.
Figure 1-5 Closed versus open—which do you choose? Does it affect security?
Of course, having a channel still doesn’t ensure that patches are created. As alluded to earlier, developers still need to be disciplined in obtaining information about security vulnerabilities (Microsoft’s Windows Error Reporting, aka “Dr. Watson,” is a great example of one way to do this), crafting good security patches, and making them available.
There are also side channels that subvert the standard app marketplaces. The most popular, of course, is using the mobile device’s web browser to download and install the app directly, so-called side-loading. There are also third-party marketplaces for apps that can be installed in parallel with the standard ones.
One other difference between today’s fragmented mobile software market and yesteryear’s battle between Microsoft and Apple is the numerous mobile device manufacturers still dominant today and the diverse Android customizations as a result. This diversity can introduce vulnerabilities to specific devices that cannot be fixed centrally by Google. For example, Samsung’s TouchWiz interface overlay for Android was found to be vulnerable to a single line of code in a malicious web page that could wipe the device without user interaction in their Galaxy mobile devices (see androidcentral.com/major-security-vulnerability-samsung-phones-could-trigger-factory-reset-web-browser). Customers had to wait for Samsung to issue new firmware, and many older devices are probably still left vulnerable.
Sensitive data leakage is one of the biggest risks on mobile because all data is inherently at greater risk while on a mobile device. Unfortunately, many mechanisms are designed to squirrel data away in various nooks on mobile devices. In our work, we’ve seen things like the following:
• Authentication PINs to Google system logs in debug builds
• Session identifiers and credentials cached in WebView
• Inappropriate data stored in local SQLite databases
• iOS application snapshots recording screens with sensitive data when the app is suspended
• Sensitive credentials like application PINs being logged to the iOS keyboard cache
A published example includes US-CERT’s Vulnerability Note VU#251635 “Samsung and HTC android phone information disclosure vulnerability” that describes how certain Samsung and HTC Android phones store certain user-inputted information in device driver logs (the so-called dmesg buffer) that can be accessed by a malicious application. Certain manufacturers misconfigured the UNIX file permissions on their ROMs and made the dmesg executable available to any application on the mobile device.
Also, remember the “transitive” nature of app sandboxing (aka permission redelegation), which occurs when an application with permissions performs a privileged task for an application without permissions. For example, if Good App X has permissions to read the Android system logs, Bad App Y may ask X to call the log API on its behalf (without user interaction) and thus may be able to see things the developer of X did not expect. The Carrier IQ – HTC keystroke logging incident of late 2011 is a great example and stirred things to such a fevered pitch that a US Senator got involved. This is an interesting read and deserves consideration from several perspectives:
• Trevor Eckhart, the Android security researcher who originally posted on the issue and called Carrier IQ a “rootkit,” at androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/.
• Counterpoints to some assertions were made by security researcher Dan Rosenberg and published on his personal blog, “Carrier IQ: The Real Story (vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/).
• Carrier IQ published a detailed report, based on Trevor’s and Dan’s research, which explains how its software is designed and used by network operators (carrieriq.com/company/PR.20111212.pdf).
Moving aside the hype stirred up initially, the Carrier IQ incident illustrates that complex ecosystems like mobile create built-in obstacles for quickly addressing issues discovered on millions of deployed devices worldwide. In the end, we’re not sure if anybody really learned anything useful, and the jury remains out on how Carrier IQ might be abused in the future, even if through no fault of their own.
Some time after the Carrier IQ incident and others like it, the US Federal Trade Commission issued a complaint against HTC regarding its security practices, specifically citing among other things the “permission re-delegation” issue.
This raises another problem we see routinely, which is a classic: application input validation. If an app does not handle input carefully, it can be used to attack other apps. For example, we catalog in the chapters in this book many attacks based on this flaw, including: classic JavaScript eval function abuse, inappropriate execution of native code through JavaScript bridges, sending maliciously crafted intents to execute arbitrary JavaScript code, and using URL query strings to execute application functionality.
Continuing our list of key mobile application risks, as we’ve noted several times already, thinking secrets can be stored safely in mobile software is deeply flawed. We’ve pulled everything from hardcoded passwords to AES keys out of software on mobile devices. This is not to say “don’t do it,” but you have to align the value of the data with the risk. The risk is high on the device because (let’s all sing along now) attacker physical access = high probability = game over.
Of course, some applications do need to store high-value data on the device. For example, mobile payments applications need some way to store payment instruments to enable scenarios like “tap to purchase.” We have a few key pieces of advice for mobile app developers thinking along these lines.
Don’t do it. If there is a way to not store sensitive data on the device, your app will be more secure by design. It will take significant, intelligent effort to do it right (see the next two guidelines), and you probably don’t have the budget.
Use existing secure storage facilities; don’t roll your own. For example, Apple’s iOS KeyChain is provided in the platform for secure storage for sensitive user data that should be protected even if an attacker has physical access to the device. Although not perfect, by using iOS 5 and later, and by following a few best practices (primarily, setting a six-character alphanumeric screen lock passcode), the KeyChain offers protection much better than typical developers writing their own security routines. See sit4.me/ioskeychain-faq for more details on the strengths and weaknesses of the iOS KeyChain.
Use specially designed hardware to store secrets. A secure element (SE) is a tamper-resistant chip (microcontroller) that can be embedded in the device hardware or on a SIM or SD card. SEs are becoming increasingly available thanks to intense competition in the mobile payments space, primarily among Google’s Wallet (on Sprint) and Isis’s Wallet (backed by Verizon, AT&T, and T-Mobile). Communication with the chip is via existing smartcard standards, such as ISO 7816 (contact) and ISO 14443 (contactless). Implemented properly, it is difficult to attack. “Properly” means not exposing the secret data to the wrong interface. These are not trivial scenarios for developers to code, and we have on a few occasions found mistakes that allowed us to access data on the SE inappropriately. We’ve even moved SEs between devices and accessed data using apps on the recipient device (poor integrity checking), and we’ve accessed SEs directly via malicious apps on rooted phones.
Weak authentication is a classic application security problem in general, and the situation is no better on mobile. In particular, we find a tendency to assume that tokens on the mobile device are “secret,” for example, the mobile device number (MDN). We once saw a password reset service that required only the MDN in order to reset the account password (not including the secret question, which was required for other reset operations). How many people know your MDN? How many apps can access it via permissions on your phone?
Chapter 6 goes into more detail about mobile service authentication using popular standards like OAuth and SAML, including known attacks and countermeasures.
We also see a lot of problems that could have been prevented if specifications had been implemented properly. In one example, a WS-Security header used a cleartext username/password rather than a hashed value. Take another simple (and unfortunately, very common) example: debug mode doesn’t get reset in production, resulting in critical things like SSL/TLS certificate validation being disabled, which is really critical to mobile devices exposed to man-in-the-middle attacks via the local Starbucks and similar venues.
You can’t escape the fundamental fact that better developers write better code, which tends to be more secure code. This is at odds with the typical desire for speed in the mobile development space that we see frequently. Additionally, we see a lot of outsourced development when it comes to mobile. Even companies with large in-house application development groups may not have the ability to ramp up on mobile development quickly enough to suit a fast-moving business initiative, so the typical reaction is to outsource to one of the many third-party app development shops that specialize in mobile. Be prepared to spend more time with mobile projects because of this—you will need to be more vigilant.
The Bring Your Own Device (BYOD) phenomenon gets a lot of hype, but we don’t see this as anything particularly new when it comes to the endless struggles of IT departments for and against end users. We survived the PC revolution fine, and it was pretty messy when it came to data and apps living on end-user devices with very poor security hygiene. Rather, think of BYOD as an opportunity to take yet another bite at data governance—and maybe even with teeth this time. The serious risks posed by sensitive data on mobile devices that potentially veer into hostile environments should at least cause management to pause and think a bit. You have options: online only/virtual machine for high-security data, or across the spectrum to totally client-side, bypassable controls for nonsensitive stuff. Let the stakeholders choose, and hold them accountable.
Mobile device management (MDM) is frequently considered a Band-Aid for the mobile security problem. It works as well as a Band-Aid in most instances, which is to say for paper-cut-class vulnerabilities only. During testing of one of the major MDM vendors, attaching a debugger to the mobile device allowed us to trivially bypass screen lock. Again, defending against physical attacks is very hard, and you should not expect MDM to “solve” the problem, only alleviate some of the symptoms. We’re not saying “don’t use it,” but make sure to evaluate solutions carefully and map them to your organizational threat model realistically. Don’t over-sell MDM as a panacea.
But don’t under-sell them either. MDM and related technologies like mobile application management (MAM) and app integrity protection (for example, anti-debugging and obfuscation) can contribute substantively to an overall mobile security posture if designed and deployed thoughtfully. We explore the potential and pitfalls of this evolving space further in Chapter 7.
OK, you’ve heard our high-level perspective on the context for mobile security. Now what?
Our agenda for the remainder of book is to explore each component of the mobile risk ecosystem, including attacks and countermeasures in the traditional Hacking Exposed style. We’ll look at the problem from different perspectives, including the usual suspects mentioned previously:
• Mobile network operators (MNOs)
• Device manufacturers (aka OEMs, hardware manufacturers, and so on)
• Mobile operating system (OS) vendors like Apple and Google
• Organizational IT (for example, corporate security’s mobile device management software)
• Mobile application developers
• End users
Based on this list of players, and our perspectives on the mobile risk ecosystem, we’ll cover topics including the following.
A lot of combined experience from some of the top mobile security consultants in the world is packed into these pages—how will you use it?
Well, what are you waiting for—turn the page!
In many ways, mobile presents the same security challenges as client-server computing, with which we’ve been struggling for many years. Rather than reinvent the wheel, we should continue to focus on the fundamentals, including many of the concepts we’ve covered in this chapter:
• First, understand what you are trying to protect:
• Data in display
• Data in transit
• Data at rest
• Develop a risk model encompassing these assets, as well as relevant threats and controls.
• Design your mobile solution to address the risk model.
• Integrate security into the development process using processes like code review and penetration testing to ensure that abuse scenarios are tested and implementation flaws are discovered.
• Rinse, patch, and repeat.
For mobile application developers, turn the page to see a summary of key countermeasures to consider.
• Architecture and design Align your architecture with the value of assets in play, for example, “remote control/no client-side data” versus “all data cached client-side.”
• Input/output validation Injection attacks remain the bane of application security; take control of what’s coming and going.
• Cache-ing and Logging Understand the mobile platforms you develop for and the many ways in which they can record snippets of your valuable data; disable and/or mitigate these as appropriate according to the sensitivity of data you are handling.
• Error handling Mobile scenarios may have lower tolerance for “fail closed” design, but that doesn’t mean it’s impossible if you can create a compelling recovery story.
• Device loss or capture Make sure your design incorporates last-resort controls: remote wipe of your data.
• Server-side strength Server-side data and processing remain the central-most valuable assets in modern, cloud-centric threat models. Implement strong controls here, including application-level protections, and pay strict attention to often-abused support interfaces like self-help password reset.
