Chapter 1. Introduction
Welcome, developer! This book is for you: software developers that write for the Android mobile platform. Here you will learn what you need to know about the world of application security, and the interaction between software development and information security. In today’s world, application security knowledge is one thing that can differentiate developers.
Like it or not, you will be releasing applications into a high-threat environment. Although the Android platform is still pretty new and offers lots of great opportunities, it is also routinely targeted by malicious hackers who want to compromise mobile applications—your mobile applications—for their own gain (note that this is not to say that Android is targeted any more than other systems, such as web browsers, document formats, and so on; any platform with a decent number of users is a target nowadays, and Android sure has that). This book will teach you the basics of how to design and implement secure, robust, and rugged applications on the Android platform. It will also teach you how malicious hackers may view your application and how they may choose to attack it, information you can put to good use when designing and implementing your app.
As noted, this book is targeted to developers who are already developing for the Android mobile platform, or plan to. It assumes you have a decent knowledge of the Android environment, including how to design, build, and deploy applications. It does not, however, assume any background in application security, cryptography, or secure software development. What you, as a developer, need to know about these topics is exactly what this book aims to provide. This book exists to give you the information you need—no more, no less—to effectively develop in this environment.
Finally, before we get started—thanks. Thank you for taking an interest in application security and making the effort to increase your knowledge of how to create secure, robust, and rugged applications. The only way the current state of vulnerable, constantly exploited applications will change is for developers to see the need for more secure development practices and knowledge, and by their gaining that knowledge. Welcome to that journey.
Application Security: Why You Should Care
Security…why should you, as a developer, care? Security, in the context of information technology, refers to things like firewalls, intrusion detection systems, antivirus programs, and things like that. Surely someone who writes general purpose applications like games, calendaring apps, and photo manipulation tools does not need to worry about security, right? Wrong!
Imagine that you write apps to help busy people manage their schedules, and that you take advantage of cloud services to make that information available to your customers on their Android smartphones and tablets anywhere they go. This is a very useful service and many of the people who take advantage of it will be those who are very busy: financial services executives, for example. Your app takes off and sees widespread adoption. Then a busy executive is chatting with a friend from another firm at a conference and lets it slip that his firm has been reading the executive’s calendar. They have been able to see whom this executive was meeting with, what potential deals the firm was working on, and other confidential information! After some investigation, the executive learns that your calendaring app is vulnerable to what the application security field calls a command injection vulnerability, and that an unscrupulous engineer at his firm’s competitor has discovered this and was using it to target the competition’s mobile devices to grab sensitive information.
Let’s consider another situation: you write a really cool app that allows people to access many of their social media accounts all from one place. Users are able to see updates from their connections on Facebook, Google+, Twitter, and whatever other networks and services will emerge in the near future, all in one place. Users love this tool and use it all the time. Things are going great until you get an email one morning from a user who complains that all of her social media account details, including her passwords, have been published on a site hosted in eastern Europe. You check out the site and sure enough, details for thousands of users are posted. Looking through your accounting records, they are all users of your integration app. The next email you receive confirms your fears. It is from the hacker who stole this data. He reveals that he snuck a bit of code into an Android app that he released that looked, for unsecured database instances, like the one your app used, and grabbed all that data. Now, if you do not want him to release all of that information publicly, a large “protection fee” will be required.
Whose fault are these situations? Yours! You did not fully appreciate the environment that mobile applications run in. Gone are the days when you could deploy insecure, poorly developed code and no one cared. Now you are releasing your code to what we call a high-threat environment, more commonly known as the Internet. Your software is running on a device that has an always-on Internet connection and runs your code along with hundreds of other apps, all of which are from different authors, some of whom are anonymous. You failed to account for unexpected data to arrive over the network in the first example, and you failed to properly secure the sensitive data you were storing from other apps on the device in the second.
Note
Pure developer anonymity is not entirely possible, as anyone uploading applications into the Android Market is required to supply a valid credit card and corresponding identity information as part of the registration process. So there is some degree of assurance there. However, since it is possible—pretty easy in fact—to allow installation of applications from other sources (and there are a lot of third-party applications stores out there) on Android devices, this identity property only applies to applications obtained from the official source, the Android Market.
So, who needs to worry about properly coding their applications to resist such threats? Easy: anyone who is coding any application at all. Every single developer needs to have a basic understanding of application security. You need to understand why it is important to restrict access to certain components of your application, such as your database. You need to understand what cryptography is and how you can use different cryptographic functions to provide appropriate protections to the data your app is storing and processing. You need to understand how the Android environment works and how apps can be written that are secure, robust, and rugged. Luckily for you, all of these topics will be discussed in this book. We will get you up to speed with what you need to know as a developer. Your code, and the protection you are offering to your customers’ data, will be much better off for it.
The Current State of Mobile Application Security on Android
As of late 2011, the Android ecosystem has an awful lot going for it. Android phones are extremely popular and new models seem to come out every couple of days. There are thousands upon thousands of apps in the Android Market and the Java-based development model is appealing to lots of developers. Google continues to innovate on this platform at a rapid pace; indeed, Android 4.0, Ice Cream Sandwich, should be available by the time this book is published. This should resolve the current incompatibilities between phone and tablet versions.
However, all is not well in the world of Android. Recent analysis by outside firms has found multiple types of malware embedded in apps released on the Android Market. A lot more malware has been found in other, non-Google application stores. Tricking the user into installing the app by posing as a useful tool or game, the software then steals data from the phone and sends it out to unknown people with unknown motivations.
Some examples of malicious Android apps, discovered and removed from the Market, are:
Super Guitar Solo
Photo Editor
Advanced Currency Converter
Spider Man
Hot Sexy Videos
People will try all sorts of things, making their malicious code look like all varieties of legitimate apps, in order to get unsuspecting users to install and run them. All of these examples were available on the Android Market and downloaded by many users before they were pulled. Indeed, this spoofing of legitimate applications and legitimate functions is not unique to Android Market either; it is a trait of any large scale system.
Android was designed from the ground up with a strong security model, so has that model been effective in mitigating this type of threat? The fact that this malware exists indicates that it has not, nor could anything really ever be, a panacea for platform security. And while this threat does continue to exist, the sandbox/permissions approach has provided some key wins. First, it does reduce the scope of functionality for most applications (reducing the attack surface for the malware if it does get to run on a device). The permissions model also provides users with better information about the real behavior of the applications they are installing, and combined with user reviews and feedback through the Android Market (and other sources), users can research to detect malicious applications. Finally, the malware that has been seen is more limited in its scope than that which exists for other platforms (although some malware actually exploits vulnerabilities in the Android system itself to obtain root-level access and do really nasty things). So, while the threat of malware on Android is real and will continue to be so, the security model, composed of the permissions capability and other constructs, does provide some real benefits and protection for the users.
In addition to these Android platform-specific troubles, it seems that every day brings news of a compromise of private data, with hacker groups releasing stolen files and large security firms announcing that they have discovered massive penetrations of huge numbers of corporations with industrial espionage (the stealing of corporate secrets) as the goal. Now, let’s note that these actions have occurred against computer systems in general; large-scale compromise of data like this has not been seen from Android platforms. Though the computer security industry has come a very long way in its short lifetime, things are clearly not working very well and the need for developers to release software that is less vulnerable is easily apparent.
Security: Risk = Vulnerability + Threat + Consequences
Security is all about managing risk. You will never ever have a perfectly secure system. The most honest statements ever made about being 100% sure that your information is secure is known as Richards’ Law of Computer Security, which dates from 1992[1]. The first law: don’t buy a computer. The second law: if you do buy a computer, don’t turn it on. That is very useful and practical advice, no? Seriously, application security is all about tradeoffs. Think back to the example discussed in the previous section, centered on a social media integration app. If we need perfect assurance, a 100% guarantee, that the user’s usernames and passwords would not be compromised, the only way to accomplish this would be to not store them at all. However, this would make the entire concept of our application infeasible. We need to take on some risk in order to provide any useful services.
Compare this to a real-world example. Credit cards can be stolen, and if your card is stolen and used by the thief, you may need to go through some time-consuming and annoying processes to recover. When you hand your credit card to your waiter at a restaurant to settle your bill, there is a chance that he will run that card through a skimming device back in the kitchen that would allow him to clone that card and use it fraudulently. The only way to prevent this attack from occurring, with 100% certainty, is to not ever use your credit cards in any manner where they leave your sight (indeed, this is how things are handled in Europe, where waiters bring the card processing machine to your table…but could you spot a card skimmer attached to such a machine?). You incur some risk when you hand that card over. However, you also incur a benefit in that you do not need to carry cash to pay for your meal, you obtain some rewards points from your card company, and you obtain a useful itemized statement of all your purchases every month. In modern society, most people have decided that these rewards outweigh the risk and are willing to hand over their credit card.
How is this decision made? How do we know whether the reward is worth the risk? The first thing we need to understand is what risk is. There are three primary components of risk: vulnerability, threat, and consequences. Let’s look at each of these three to see where risk comes from.
A vulnerability is something that allows an unintended and undesirable action to take place. In our credit card example, the vulnerability is that our credit card leaves our sight and we have no control over what happens to it at that point (one may also note that having a universally authenticated identification method, like a credit card number, is also a vulnerability in this scenario; why is the knowledge of a credit card number accepted as sufficient proof that you are whomever that card number belongs to?). The widespread availability of card skimmers is also a component of the vulnerability; if the card could not be duplicated in so quick and easy of a manner, the situation would be less concerning.
A threat is the second component of risk. A threat is something, or someone, that can take advantage of a vulnerability. In this case, the threat is a waiter who does take the card and clone it, using it to make fraudulent purchases. Here, we can judge that the threat is probably somewhat low. Most waiters are honest, hardworking people, so the threat in this case is much lower than what it may be if we were using that card to pay for stolen electronics instead of a meal, as an individual selling stolen goods is much more likely to steal our card information as well. So while the vulnerability in this situation may be severe, the threat is not particularly high.
The third component of risk is consequence. This refers to what would happen if whatever bad things we are considering were to actually happen. If we hand over our credit card to the waiter and he skims it and clones the card, what are the consequences? If no mitigations were in place (more about that in a second), the attacker could quickly purchase thousands of dollars worth of goods that we could then be charged for, potentially ruining our credit and requiring many hours of painful work to get resolved. The consequences of having our credit card cloned, through a successful exploitation of the vulnerability by the threat, could be severe.
What do we have here with regard to risk? The current system has a pretty serious vulnerability in it, as the card leaves our sight and can be easily cloned with the right device (which is widely available to anyone that wants one). The threat is probably pretty low, as most waiters are not out to steal our card information. The consequences of such a successful exploitation, however, could be pretty high. Consider all of these factors together and we can get a decent idea of what the risk of paying for our meal with a credit card is, and it is not a particularly positive outcome. This is basic definition of risk; it is a function of vulnerability, threat, and consequences.
So why are people are willing to hand over their cards on a regular basis? The risk is not at the level we have just calculated. The parties that are involved have implemented mitigations to reduce that risk. As we have seen, risk is a function of vulnerability, threat, and consequences. If the severity of any of these three can be reduced, the overall risk will go down. In our example, credit card companies have done a lot to mitigate the consequences to the consumer. In the United States, liability (what you are responsible for paying) for charges made on a compromised card is capped at $50 and many card companies set that value to zero. So if a customer were to charge their meal and the card were cloned and used fraudulently, the customer would not be responsible for the charge and such occurrences would not negatively impact the customer’s credit rating. The credit card companies take on that risk themselves because they need to reduce the consequences of credit card compromise in order to bring the risk (to the consumer) associated with using the cards down to an acceptable level. Because the actual consequences of a compromise are very slight, customers do not hesitate to use their cards, as the level of risk is greatly reduced due to this mitigation.
Think about the credit card example a bit—what other mitigations could be applied to this example to reduce the vulnerability, threat, or consequences? You can probably come up with quite a few.
Evolution of Information Security: Why Applications Matter the Most
One who practices security has to worry about a great number of things. The fundamental field generally focuses on providing three services: confidentiality, integrity, and availability (CIA). Confidentiality refers to making sure that only those people (or devices, or systems, etc.) that are supposed to have access to certain information have it. For example, in the social media integration app example we have been discussing, the stored usernames and passwords should be available only to that one app and the respective service the users belong to. Integrity refers to making sure that data is not altered by anyone who should not be doing so. In the calendaring app we have discussed, a bit of hidden code in a game installed on a phone should not be able to change the user’s appointment schedule, causing him to miss important meetings. Availability refers to ensuring that services are functioning as they should; for example, an attacker sending lots and lots of bogus requests to a server should not be able to disrupt that service for legitimate users.This CIA triad is a very general and very simplistic model for what applications need to protect.
Application security is a big deal nowadays. Fifteen years ago, the main subject of interest was the operating system. In the late 1990s, attackers constantly discovered and exploited conditions known as buffer overflows in Unix-based systems and services (we will discuss buffer overflows in general a bit later). In the early 2000s, the target switched to desktop operating systems, specifically Windows XP, where a large amount of vulnerabilities were found that allowed attackers full access to systems, including the ability to read, change, or destroy the data contained within. Indeed, even as Windows Vista was being developed at the same time Windows XP was being exploited so rapidly, Microsoft put a freeze in place on Vista development to focus efforts on fixing XP’s security. It took them a long time, but Microsoft has come a very long way to producing solid, secure, robust, rugged code. Modern Windows operating systems are much less exploitable than previous versions.
This success in strengthening the operating system causes attackers to move on to other targets. For a while, network devices such as switches and routers were the preferred targets, and then applications. If the operating system that an application runs on was much harder to exploit, what about the application itself? It had access to the data on the system and a whole lot more people write applications than operating systems. So the expertise that operating system developers gained writing code with fewer vulnerabilities, and the mitigation against the consequences of a successful exploit, was in far less supply at the application level. Due to these factors, applications are targeted all of the time now. Attackers have moved from the once vulnerability-filled environment of the operating system to the still vulnerability-filled environment of the application. You, as an application developer, need to be ready for them.
Your Role: Protect the Data
You write the apps. The apps need to process some data. Attackers want to do bad things—steal, alter, or block access to—that data. When a user chooses to use your app, they trust you with all of the data they supply. They also trust that your application is written correctly so that none of the other data stored on their device will be compromised by letting your app run on it as well. If you write apps and you want people to use them, you need to do your best to safeguard your customers. Your job is simple: write your applications so that they do what their users expect them to do, no more and no less. Carrying out that job is less simple.
The first order of business is for you to understand how Android works. If you are writing apps to run on this platform, you need to understand how your apps will, or will not, interact with other apps on the device and with the system itself. You need to understand how you can store data within Android’s SQLite datastore and how to secure that data so that only your app can access it. If it is sensitive data, such as passwords, email, or other things that your customers would not want to be compromised, you need to understand why you may need to protect it more fully (such as utilizing cryptography) and how you would do so using Android’s built-in capabilities. You also need to understand the permissions model and how you can let a user know what permissions your app will need, and then make an informed decision as to whether they will allow it to do so (why does this game I just downloaded need full access to my SMS messages, anyway?). And the list goes on and on.
Now you may be saying at this point, “This is a lot of things to learn…I just want to write some apps!” and you would be right. Application security is an involved topic and requires a good amount of practice to master. But it is also an area where a little knowledge goes a long way. Once you understand the basics, you will pick up on more and more, faster and faster. Once you start thinking about security, you will do so more and more, growing into a certain mindset where you are evaluating risk, and designing and implementing mitigations, before you even realize what you are doing. You will identify and resolve potential vulnerabilities before you even code them up. You will protect the data.
Secure Software Development Techniques
As Microsoft learned many years ago when dealing with a large amount of exploitations against Windows XP, it can be quite hard to build secure code. With some exceptions, developers are not taught to think of security as part of their formal training. As the need for this type of information and training has become more and more evident, companies have developed application security training for their in-house developers, organizations such as the Open Web Application Security Project (OWASP) have emerged to develop open source training, and universities have begun offering application security courses in their computer science curriculums. Books, such as the very one you are reading, provide great information so that developers can quickly get up to speed on creating more secure applications. However, developer education only goes so far. Security is not something that you can learn about, apply to writing better code, and then forget about. Security is a process and is part of an application’s entire development lifecycle.
Many large software development firms have formal Secure Software Development Life Cycles (SSDLCs), where security engineers work with developers through the entire process. All developers are trained to think about security concepts and engineers who specialize in application security add even more experience to the process. Security personnel participate in the requirements and planning phases, review source code as it is developed and submitted, perform penetration testing against the application before it is released, and analyze and repair security issues that are reported post-release.
Recent development techniques such as agile development, pair programming, and extreme programming have proven that developers work better and generate fewer errors when they work in pairs or small groups. Having multiple pairs of eyeballs on code, looking for flaws, is a great way to catch security issues that a single developer might miss, which is why those trained in secure coding (as you will be!) often perform source code analysis to find problems before those who might attack the software.
Penetration testing is a standard technique that some choose to deploy against their software, especially those that have a high degree of risk.[2] During such testing, the testers act in the role of attackers and attempt to study and compromise the application, much as a malicious hacker would, which is why penetration testing is sometimes known as ethical hacking. The combination of source code and design review with penetration testing has proven to be very successful in finding and correcting security issues with applications.
As you can see, producing a secure application can be very time-consuming and can require a lot of education, careful consideration, and a variety of testing techniques. This really comes down to one simple observation: programming is hard! Programming code that does not have errors is pretty much impossible. Programming code that does not have errors that can be exploited by malicious hackers to compromise that application, a subset of the problem, has proven to be quite hard by itself. The extent of these techniques that you may need to employ for your applications is all a matter of risk management; the amount of work taken to secure your application must be appropriate based on the risk. If you are developing a standalone mobile game that will not process or store any data or use any protected Android APIs like network communications, both the threat against your app and the consequences of a successful exploitation are probably pretty low. In such a case, you may judge that the small risk that your game is exposed to is acceptable, an appropriate risk acceptance. On the other hand, if you are writing the social media integration app we have talked about, there is a high threat targeting your app because social media credentials are sought after by malicious hackers. The consequences are somewhat high because the compromise of your users’ credentials would be a very negative thing for you. Therefore, you may choose to employ many of the secure development techniques we have just discussed to find and fix as many vulnerabilities in your app as you can to mitigate some of that risk.
Remember, security is all about risk management and acceptance of the residual risk (the level that still exists after you have mitigated the risk as far as you can). You can never be sure you’re building a 100% secure app, at least not one that does anything useful.
Unique Characteristics of Android
Android is a very interesting platform with some traits that clearly separate it from other mobile platforms.
One of the most representative features of the Android ecosystem is the open development model. Google allows any developer to put their apps on the Android Market, after they have registered as an Android developer. This requires the developer to pay a small fee with a credit card so there is some assurance that a real person is at the other end of the chain, and there is some accountability for that person. Contrary to some popular belief, Google does scan and conduct analysis of apps throughout their Android Market lifecycle looking for malicious activity. In addition, it does find and remove applications that do bad things. When something does escape this process undetected (for example, malware that misrepresents itself and includes functionality that is not always bad but only bad in this context—think a game that also attempts to read your SMS messages and send them off to somewhere over the Internet), this is where the Android permissions system comes in to play. Every Android app must declare which restricted system APIs it uses and that list of permissions is presented to the user when they install the app. As a developer, the app permissions system is very important for you to understand, and as someone interested in security, it is even more important. This system can also be used to allow other apps access to certain parts of your app, whether interactive portions, background services, or databases. How this system works, the weaknesses of it, and how you as a developer will utilize it, will be discussed in great detail in later chapters.
Android devices also have the capability to be rooted. As you will see in Chapter 2, the underlying base of Android is the Linux kernel. This design prevents one app from accessing data held by another app. The Android platform also enforces the permission system that prevents one app from accessing resources, such as files and databases, of other apps. However, if a user (or someone who has stolen a phone and has access to it) wants to, full access to the device can be readily obtained (with some level of effort, which depends on a number of things). If you have a Linux background, you know that the root user can access anything on the system.
Note that there are complexities involved in rooting an Android device that are more complex than this brief treatment can fully cover. While a user can obtain root-level access if they desire, they must have access to the device (stealing a device without being able to access/unlock it, for example, would make this process quite difficult). I do not mean to imply that one can simply grab a locked Android device, connect it to something, and obtain a root shell on it. And while Android makes this process somewhat easier than other, more closed platforms, the same things can be done with those other platforms, such as jailbreaking an iOS device. While some users do root their devices, most users do not and assuming those users properly protect their device using lockscreens and strong passwords, this risk is largely mitigated.
Moving On
With mobile platforms growing at an unbelievable rate and the accelerating adoption of cloud services, where data will live on servers and be accessed from anywhere, the apps that run on these mobile devices must be secure, robust, and rugged. They must resist attacks as history has shown that attackers follow where the data is and they go where they can get at it. That line of battle is shifting to mobile platforms. You, as an Android developer, will be on the front lines. Your software will be attacked. It’s just a matter of when. To properly defend against this, you need to understand application security and how to properly develop your apps in a secure manner.
Let’s get started.
[2] For example, an application that allows individuals to trade stocks they own has a high risk. Why do you think that is: does such an application have high vulnerability, threat, and/or consequences associated with it?
Get Application Security for the Android Platform now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
