In this chapter, we will cover the following recipes:
- Information disclosure via logcat
- Inspecting the network traffic
- Passive intent sniffing via the activity manager
- Attacking services
- Attacking broadcast receivers
- Enumerating vulnerable content providers
- Extracting data from vulnerable content providers
- Inserting data into content providers
- Enumerating SQL-injection vulnerable content providers
- Exploiting debuggable applications
- Man-in-the-middle attacks on applications
So far, we've covered some of the basic development and security assessment tools, and we even covered some examples of extending and customizing these tools. This chapter will focus on the use of these tools to analyze the Android applications to identify vulnerabilities and develop exploits for them. Although, given the arbitrary nature of application functionality and the almost limitless creativity Android application developers can exercise, it's not hard to see that assessing the security of Android applications must be considered an art. What this means for you as a security auditor, analyst, consultant, or hobbyist is that you can be sure that there will never be a fully autonomous method to analyze the security of the Android application. Almost always, you'd need to rely on your creativity and analysis to deliver a concrete assessment of an Android application's security.
Before we start banging away at some apps, it's important to frame the Android application security problem, define some goals, and enumerate the application attack surface. In the next few sections, we will discuss some of the generic goals of application security and the controls that should be in place to help achieve these goals. The reason discussing application security goals is so important is because it helps to make sure that you've got the right mindset and principles in place when accessing the security of an application. Also, it makes auditing application security as simple as verifying the existence of these controls and then developing ways to exploit either the lack or the inadequacy of the mentioned controls.
So what are the goals of application security?
Applications are often entrusted with very sensitive data related to users, some examples are as follows:
- Passwords
- Authentication tokens
- Contacts
- Communication records
- IP addresses or domain names to sensitive services
Each application's data is cached if it is so inclined, and may often explicitly save the user content in the databases, XML files, or any other disk storage format; they have the freedom to use any file format or storage mechanism they need. It's important to assess the security of these data stores with the same diligence that is applied to assessing and auditing online or cloud-based databases and information storage mechanisms, especially because the information stored in an application can influence the security of websites and other cloud services. For example, if an attacker proliferates authentication credentials to a cloud service from an application, he/she immediately has access to the actual cloud service. Think about online banking apps as well, and the two factor authentication tokens these apps store and how they are stored—the SMS inbox? Really!
Applications need to enforce many of the controls that online databases use independent of those provided by the Android operating system; namely, the controls that ensure the following properties:
- Confidentiality
- Integrity
- Availability
- Nonrepudiation
- Authentication
We will discuss how to ensure these controls in the later chapters. For now, all that you need to concentrate on is understanding the risks which the user incurs when these controls are not enforced.
Applications are protected via the Android sandbox, which is just another way of saying that each application is assigned a user ID and only inherently has access to its own resources. This is the story of application isolation as far as the Linux portion of Android is concerned. Android introduced some of its own protection mechanisms to keep apps from abusing each other's components and data; the most notable being the Android permissions framework, which operates at the application level and is enforced by the application middleware. It exists to translate the Linux access control mechanism to application level and vice versa. Speaking more practically, this means that every time an application is granted a permission, it may mean that the related UID is assigned a corresponding GID. For example, android.permission.INTERNET, which is mapped to the inet group. Any application granted this permission will be placed in the inet group.
Applications often consist of many instances of the classic application components, services, content providers, activities, and broadcast receivers. To protect these components from malicious or any unintentional harmful influence, it's imperative that application developers communicate and mitigate the risk their applications introduce to the user with regard to the services and data they can access. The application developers should also respect the integrity of these resources. These two principles of secure development can be enforced by the permissions framework by ensuring that they only request the necessary permissions and are not overzealous in the permissions they expect to be granted. The key here is making sure that developers practice the principle of least privilege. Protection from malicious apps can be enforced partly by ensuring that the correct permissions are required to access a given application's components and data, and only the necessary services and components are made available to the rest of the system at large, that is, don't export components when you don't need to.
When analyzing the isolation an application enforces for its data and components, it's important to take into context the permissions required to access them. How easy is it to get these permissions granted? Are permissions required to access a given component assigned the correct protection level? A bad example would be an app that facilitates searching and retrieving a user's bank statements with only the android.permission.SEARCH permission.
It's not enough that application developers protect the data their applications store, they also need to be mindful of the way this information is communicated. For instance, consider an application that stores a user's data securely but allows it to be communicated to unauthorized parties. All the data storage security in the world means nothing if communication isn't done securely!
Communication can be done in the following ways:
- Inter-component communication: Applications often need to send information between their respective components, for example, between a broadcast receiver and an activity. Seeing that this communication may be facilitated via intents and intent filters, and given the nonexclusive nature of intent filters, it's possible that unauthorized applications may intercept this communication in various ways.
- Inter-application communication: Data communication between applications should be done in a way that will prevent unauthorized applications from tampering, intercepting, or gaining access to it.
- Extra-device communication: It's possible that apps will make use of NFC, Bluetooth, GMS, or Wi-Fi communication mediums to transmit sensitive data. Application developers must take the proper precautions to ensure the confidentiality, integrity, and non-repudiation of data communicated this way.
So, when auditing an application for communication faults, it's important to look for controls that provide the following:
- Authentication between both the receiving and initiating application
- Access control preventing unauthorized parties/applications from gaining access to the communicated data or controlling the flow of communication
So hopefully, you actually read the introduction and have a good grasp of the controls that are expected from secure applications; because in the next sections, I'll walk through how to verify whether these controls are in place or not, and how to take advantage of the lack of these controls.