Android Security: Attacks and Defenses

by Abhishek Dubey and Anmol Misra

CRC Press. (c) 2013. Copying Prohibited.

Reprinted for Yasser Bousleh, Orange Groups

[email protected]

Reprinted with permission as a subscription benefit of Skillport,

All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms
without written permission is prohibited.
Android Security: Attacks and Defenses

Chapter 5: Pen Testing Android

Overview
In this chapter, we focus on pen testing the Android platform and applications. We start by covering penetration methodology,
discussing how to obtain details on the Android operating system. We then turn to pen testing Android applications and discuss
security for Android applications. Towards the end, we talk about relatively newer issues (including storage on clouds) and
patching. Finally, we showcase recent security issues for Android applications.

The reader should now be familiar with Android architecture (covered in Chapter 2), Android application basics (building
blocks, frameworks; covered in Chapter 3), and Android permissions and security models (covered in Chapter 4).

5.1 Penetration Testing Methodology

A penetration test (also pen test) is a method of evaluating the security of systems by simulating an attack from malicious
insiders or outsiders. The goal is to discover issues before they are discovered by attackers with malicious intents and to fix
them. Testing often happens just before a product is released, to ensure security, or after it has been out, and to ensure that no
vulnerabilities have been introduced. Source code review or static analysis compliments a pen test. A static analysis ideally
should be performed before a pen test and should be a component of the Software Development Life Cycle (SDLC) cycle. If a
static analysis is performed before the pen test and findings from it are remedied before product development is complete, a
pen test will result in relatively fewer findings. This allows for a relatively cleaner pen test report that can be shared with
customers, if needed, thereby providing them with an assurance of security for the product.

Pen tests can be classified into two categories—internal and external—depending on the vantage point of the simulated tests.
Below are overviews of internal and external pen tests, guidelines for conducting pen tests, a static analysis, and steps to
follow in pen testing an Android OS and devices.

5.1.1 External Penetration Test

External pen tests are performed by security professionals outside the network who are only provided with limited information.
Enterprise networks are protected by a multitude of firewalls with Access Control Lists (ACL) that block off most of the ports
that can be accessed from the outside. In an external pen test, the only information security professionals are given are URLs
or IP addresses. Many of the tools/techniques used by security professionals for external pen tests will encounter firewalls, and
these firewalls will usually prevent them from probing the internal networks. This prevents them from identifying vulnerabilities
that exist but are protected by firewalls or other defenses.

For example, a rooted Android device is running a service on port 850. Firewalls are usually configured so as not to allow
probes to this port (and thus protects services running on this port). Thus, a pen test from the outside will not detect a service
running on this port. However, if a rooted Android device is an running httpd server on port 80, it is more likely to be discovered
by an external pen test, since port 80 is usually accessible through a firewall.

5.1.2 Internal Penetration Test

Internal pen test are not hindered by firewalls (although they might be, if there is tiered architecture), and it is, therefore, easier
to obtain information on internal systems (systems that have private IPs, etc.).

Continuing our example of a rooted Android device running service on port 850, in an internal pen test, security professionals
are more likely to discover this port (and service), as it probably won't be blocked by a firewall. If a service is communicating
with other devices, it can be probed.

The rule of thumb is that an internal penetration test will highlight more issues compared to an external penetration test.
External penetration tests rely on the fact that attackers can't access devices in the network. However, it does not mean that
issues in internal pen tests are of less severity. Insiders can still exploit these issues. In addition, attackers from the outside
might be able to exploit these issues as part of larger attacks, where they can, in fact, get inside the network.

5.1.3 Penetration Test Methodologies

Peer-reviewed methodologies for performing pen tests step by step exist. NIST 800-115 and OSSTMM are two such
guidelines. The idea is not to follow them every step of the way, but to use them as guidelines and modify them as needed in
conducting a pen test.

Page 2 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

A typical pen test can be broadly divided into the following four stages:

1. Planning: Identify goals for the exercise and obtain approvals and logistics.

2. Discovery: Obtain information on target(s). Information includes IP addresses, contact information, system information (OS
versions), applications, and databases, etc.

3. Attacks: Based on information discovered in Stage 2, identify any systems, applications, and databases that are
vulnerable and validate these vulnerabilities. If necessary, loop back into the discovery phase.

4. Reporting: Based on this assessment, categorize issues by severity—critical, high, medium, and low—and provide this
analysis to management, along with recommendations.

5.1.4 Static Analysis

Although not part of penetration testing, static analysis is an important tool for security professionals. It helps to identify
software code–related issues early in the development cycle (or if the product has been released, later during security
assessments). A static analysis tool is executed against a code base. Tools use algorithms to analyze various code paths and
flow and provide a list of potential security issues. There is often some percentage of false positives. The beauty of the static
analysis is that developers can use it without any outside help and understand/improve their coding practices to prevent such
issues in the future.

As far as Android is concerned, we can analyze security at two different layers (skipping the hardware layers, which is the
focus of another book): operating systems (OS) and applications.

5.1.5 Steps to Pen Test Android OS and Devices

For most Android devices running in an environment, one of the major issues can arise if it is rooted. Rooted devices are more
at risk, since a user would be running with elevated privileges, and attackers can leverage this to compromise the device. In
addition, it is useful to analyze issues in the OS stack itself (although this requires access to the source code of the kernel,
libraries, etc.). A mix of black box and white box testing is usually the best approach, wherein security professionals have
access to devices on the network and they can probe further if they sense suspicious activities on the device.

1. Obtain the IP address of the Android device(s).

2. Run an NMAP scan to see the services that are running on those devices.

3. For suspicious devices (e.g., rooted devices), capture and analyze packets through Wireshark.

4. If device is deemed compromised, use utilities like busybox to explore device internals (which processes are running, etc.)
and for forensics.

5. Perform a static analysis of the source code of the libraries and OS. Specifically look for codes contributed by vendors
such as HTC. Code should be reviewed for the following type of issues: resource leaks, null pointer references, illegal
access operations, and control flow issues, which can potentially bypass security checks.

6. Review configuration files and code for plain text passwords and other sensitive data that is being stored without
appropriate security considerations.

5.2 Tools for Penetration Testing Android

Android comes with limited shell, and there might be times when security professionals need access to more information than
provided by the Android OS (by design). There are different tools that can be leveraged for this purpose. Nmap—network
scanner; Wireshark—network sniffer; and BusyBox—a collection of command line tools (e.g., ifconfig) are among some of the
most useful tools.

5.2.1 Nmap

Assuming you don't have access to the device itself, but are looking on the network for Android devices, Nmap scans can help.
The Nmap scan launches a SYN (synchronize) scan against the IP and looks for OS fingerprinting and version detection (see
Figure 5.1). Our scan results showed no open ports (services) and, therefore, did not provide very useful information regarding
the Android device. If any of the ports were open, we might have wanted to explore it a bit further.

Page 3 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.1: Nmap SYN Scan against an Android Device

5.2.2 BusyBox

Android comes with limited shell utilities. The BusyBox package provides many commonly found UNIX utilities for Android.
These can become handy during learning, exploring, pen testing, and forensics on an Android device. Since it runs on Android,
utilities might not support all options, such as the ones on desktop versions.

Below are instructions for installing and running BusyBox on an emulator (see Figure 5.2). For an Android device, you will need
to root it to be able to install this package and make it run successfully.

Page 4 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.2: ifconfig Command After Installing BusyBox

From the terminal inside the Linux system, launch adb shell and perform the following (assuming you have binary handy):

adb shell mkdir /data/busybox

adb shell push busybox /data/busybox
adb shell
chmod 755 /data/busybox
/data/busybox -install

At this point, utilities should be found in the /data/busybox directory. Change that directory (or update the PATH variable), and
you can start using common UNIX commands.

As is visible from the output of the ifconfig command (Figure 5.2), the emulator's IP address is 10.0.2.15—a special IP address
reserved for the emulator. If your device was on a network, you might see something like 192.168.0.104 IP. 10.0.2.2 IP is the
alias for the 127.0.0.1 loop back address on the development system (i.e., the system running the emulator). 10.0.2.1 is the
router/gateway, and 10.0.2.3 is the first DNS server.

As can be seen from the screenshots (Figures 5.3 and 5.4), port 80 is open (httpd was running on the device). On a typical
Android device, this would require further exploration.

Figure 5.3: netstat Command After Installing BusyBox

Page 5 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.4: Open Ports through pscan

5.2.3 Wireshark

If you would like to analyze traffic from an Android device, you will probably need to root the device (to use something like
Wireshark on the device) or you will need access to a router. In our case, we are running tcpdump (installed on a Linux system)
and capturing traffic in an emulator. We can then open the file in Wireshark, as shown in Figure 5.5.

Figure 5.5: tcpdump Output in Wireshark

To launch tcpdump and capture traffic from the emulator on a development machine, you can use: emulator –tcpdump <output
file> -avd <avd device name>

The traffic shown in Figure 5.5 was captured during a web browser request to open www.google.com. As can be seen from the
Wireshark listing, the DNS server is 10.0.2.3 and the router/gateway is 10.0.2.2. The source 10.0.2.15 (emulator) sends a
HTTP GET request to www.google.com (see Figure 5.6).

Page 6 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.6: HTTP GET Request in Wireshark

5.2.4 Vulnerabilities in the Android OS

The Android OS is based on the Linux OS, which is at its core. It is open source, and, thus, people are free to develop and
contribute/re-use code. Google has an official Android team that is responsible for the Vanilla Android OS. However, since it is
open source and free, everyone is free to check out code, modify, and ship the software. Different vendors—HTC, Samsung,
etc.—seem to modify the OS per their needs, although the device is still said to run "Android."

Before we explore the types of issues that can be found in the Android OS, it might be worthwhile to wonder who is ultimately
responsible for these issues? Is it Google (since they are ones who have ownership of Android official releases) or is it the
vendors, such as HTC, who take the Vanilla OS and make modifications?

We can even go beyond this. Android OS leverages drivers contributed to Linux. These drivers might be used without any
consideration for their security implications. In addition, many drivers might have old code, with new code being added on top
of it. Security issues at any of the lower layers lacks clear accountability.

Typical issues found in C/C++ code and potentially found in the Android OS would be in resource leaks, memory corruption,
control flow issues, data-access violations, and pointer references. Often, dead code (code written but not used by any code
flow path) will be encountered, and it should be pointed out to the users.

5.3 Penetration Testing—Android Applications

Most of the pen testing efforts described on Android will be focused on applications—both built in (e.g., browser, maps) and
third-party applications (found on the Android Market).

5.3.1 Android Applications

Penetration testing for an Android application is like testing any other software on a platform. Things to consider while pen

Page 7 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

testing an Android application include attack surface, interactions with other components (internally and externally),
communications, and storage.

Attack Surface: Every pen test focuses at the core on the functionality of an application. Depending on the functions and
features provided by an application, the efforts of the pen tester are on items that are relevant and critical (e.g.,
authentication, data, etc.), and tests are performed on relevant underlying components. Local components not handling
critical data should be tested differently (and less time should be spent on them, compared to components interacting with
outside applications/systems).

Interactions with Other Components: An application interacts with other Android applications and outside servers through
various Interprocess Communication (IPC) mechanisms. These include socket-based communications, Remote Procedure
Calls (RPC), passing/receiving broadcasts, Intents, and other Android-specific IPC interactions. Many of these
communications are possible through permissions, and, thus, it is paramount to look at the following:

Permissions and application requests

Functionality that an application exposes to other Android applications

The reader should be familiar with Android permissions (covered in Chapter 4). Permissions are defined in the
Manifest.xml file. A tester will need to decompile the APK file to access this file and review it. Steps for decompiling the
APK file and obtaining the Manifest.XML file are shown Figures 5.7 and 5.8.

APK files are bundles of various files. These include META-INF, res, AndroidManifes.XML, classes.dex, and
resources.arsc files/directories. Apktool can be used to extract the AndroidManifest.XML from an apk file. Usage: apktool
decode <apkname> <directory>

For Android-specific components (Intents, Broadcast Receivers), the tester needs to at least ensure the following:

1. Sensitive data is not being passed for IPC communications (e.g., in Intents, broadcasts, etc.).

2. Intent filters are not being used for security purposes. Although Intent filters can control which Intents are processed
by an application, this only applies to implicit Intents. An application can always force the processing of an Intent by
creating an explicit Intent.

3. Sticky broadcasts are not being used when sensitive data is transmitted, since the application cannot control who
receives these broadcasts.

4. Permissions requested by the applications are not more than ones needed for application functionality—that is, the
principle of least privilege is being applied.

Communications: It is important to determine if communications of the application with outside systems/servers is over a
secure channel. Connections should be encrypted. It is also important to review how servers/systems are chosen for
communication.

Data: At the core of every application assessment is the data handled by that application. Typical applications can
read/write data in the form of files or databases. Both of these can be made readable by the application only or by the
outside world. When sensitive data is being handled by an application, it is prudent to review its file and database
operations for permissions. A tester should also review the application logs and shared preferences to see if there is data
being inadvertently exposed. Most of the applications communicate with the external environment (or the Web), and a lot
of data is stored on remote servers/databases. The tester should review data being transmitted and stored on offsite
servers/applications. Another thing to review is how sensitive parameters are being passed/stored (e.g., credentials).

Proper Use of Cryptography: The tester should look at the standard cryptographic practices of an application. For
example, is the application checking preapproved public keys during the certificate check process? How does the
application validate certificates? Does the application do strict certificate checks?

Passing Information (including parameters) to Browsers: The tester should see if the application is opening a browser
application, and, if so, how it is passing the necessary parameters (i.e., through GET or POST requests).

Miscellaneous: Applications can be reviewed for services running in the background to see their impact on resources.
There are a few additional steps that are needed as part of pen testing an Android application. Since Android applications
are coded in Java, it is essential to review Java code for typical vulnerabilities. If an application is relying on underlying
native code or libraries, it would be prudent to validate vulnerabilities in the native code, as well. Finally, it is important to

Page 8 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

review how an application is handling storage (covered later).

Figure 5.7: Extracting Manifest Permissions Files through apktool

Figure 5.8: Example of a Manifest Permission File Extracted from apk

To review an application's communication with the outside world, you will need to set up a proxy to intercept traffic between the
application and the Web. This can be done as follows:

Intercepting Traffic for Browser (HTTP) Applications:

1. Download and install proxy (e.g., Burp Suite) on the host/development system. Turn on the "intercept" option.

2. Set up a proxy from the Android phone/emulator (see Figure 5.9). In our example, we are using an emulator. Thus, we will
need to use a "10.0.2.2" IP address as the proxy.

3. Open the browser on Android and type a URL.

4. Review captured traffic through the Burp Suite (see Figures 5.10 and 5.11).

Page 9 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Intercepting Traffic for Other Applications:

1. Start the application (in our case, we chose the Internet Relay Chat (IRC) application Yaaic) (see Figure 5.12).

2. Capture traffic through Wireshark and filter by the phone's IP address (in our case, 192.168.0.107).

3. Review captured traffic through various options in Wireshark (see Figures 5.13 (a) and (b).

Figure 5.9: Setting up a Proxy on an Android Device

Page 10 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.10: Intercept of Android Browser Communication through Burp

Page 11 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.11: Credentials in Plain Text (URL) Captured through Burp

Page 12 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.12: Yaaic Application on Android

Page 13 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Page 14 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Figure 5.13: (a) Packet Capture of Yaaic Communication through Wireshark; (b) Analysis of Packets Captured through
Wireshark

5.3.2 Application Security

We covered pen-testing steps for Android-specific issues. In addition to these, any Android application needs to be analyzed
(and code reviewed) for usual security flaws in the code and the design. These issues can be broadly classified, as shown in
Table 5.1:

Table 5.1: Application Security Issues

Security Issue Description
Authentication Issues related to user identification
Access Control Issues related to user rights after authentication
Auditing and Logging Issues related to logs and auditing
Cryptography Issues related to encryption and securing communications
Credential Handling Issues related to the handling of user passwords and other credentials
Data Handling Issues related to the handling of data vis-à-vis its sensitivity
Data Leakage Issues related to accidental or unintended leakage of information
Error Checking Issues related to reporting errors without providing too much data
Input Validation Issues related to validating untrusted user input
Session Management Issues related to best practices for user session management
Resource Handling Issues related to the handling of resources, including memory
Patching Issues related to timely patching/upgrade of software

Page 15 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

Issues need to be mapped by severity (critical, high, medium, and low) and level of difficulty in exploiting them (high, medium,
and low). The following is a summary of some of the classification categories outlined in Table 5.1:

1. Authentication Issues: Validates that user credentials are not being transmitted over unencrypted channel and if
authentication mechanisms are in alignment with standard practices.

2. Access Controls: Validates that authenticated users can only access resources and functionality in line with their
credentials and that they are not able to bypass access controls.

3. Logs: Validates that logs do not contain sensitive information, and that logs are not accessible by unnecessary
applications and that they have appropriate permissions.

4. Cryptography: Validates that sensitive communications occur only over secure channels and that strong ciphers are used
for this communication. Validate that there are no propriety cryptographic protocols being used in the application.

5. Data Leakage: Validates that the application is not accidently exposing data that otherwise should not be available to
other applications through logs, IPC calls, URL calls, files, and so forth.

6. Data Validation: Validates that the application does not use input from untrusted sources directly into SQL queries and
other sensitive operations.

7. Error Reporting: Validates that when an application throws an error, it does not log and report the entire stack track and
does not contain sensitive information.

8. Session Management: Validates that the application follows best practices for session management, including time out,
session identifiers, token use, and so forth.

9. URL Parameters: Ensures that the application does not pass sensitive parameters to URLs in plain text.

10. Predictable Resources: Validates that an application is not generating tokens/identifiers that can be easily guessed.

Pen Testing Should Provide an Application Benchmark Against the Following Best Practices:

1. Timely patching libraries and applications as vulnerabilities are identified.

2. Sensitive information (e.g., SSN) is not passed as a parameter through a URL. Information in a URL is accessed through
the GET request, and this can be logged at multiple places. A POST request solves this problem. However, although
information through a POST request is not visible in a URL, a POST request can still reveal this information in the
request-header. For truly sensitive information, one should always use an HTTPS connection.

3. Brute force attacks are not possible due to a limited number of attempts to authenticate.

4. A Secure Sockets Layer (SSL) is used pervasively to request resources.

5. Session identifiers are not sent in URLs.

6. Tokens are not easily guessable.

7. Password complexity is enforced.

8. Log files do not contain sensitive information and are protected appropriately.

9. Files are encrypted on local and external storage.

10. Proper data validation is performed to prevent XSS, SQLi, command injection, etc.

Code Review of an Android Application Can Identify the Following Issues:

1. Command Injection: Attacker can influence which command is executed or the environment in which it is executed, thus
bypassing security controls. Typical examples include user input being used in SQL query constructed to query SQLite
DBs.

Page 16 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited
Android Security: Attacks and Defenses

2. Resource Leaks: Application does not relinquish resources after being used (e.g., file handling, etc.). This can result in
performance issues but can also be available for malicious users/applications.

3. Error Handling: An application does not take in to account structure/flow on a particular error and thus does not perform
all housekeeping/access control checks needed if a particular code path is executed.

4. Unsafe Java Native Interface (JNI) Calls: Since Android applications can call native code written in C through JNI, this
exposes applications to underlying issues in the native code.

5.4 Miscellaneous Issues

5.4.1 Data Storage on Internal, External, and Cloud

There are various locations available for Android application data storage, including files, databases, preferences, and cache.
Data can be stored in the internal memory or on an external card. If data is stored in plain text and the device is compromised
or stolen, data will be exposed. It is usually a best practice to encrypt data that is being stored. The application needs to
ensure that a strong encryption algorithm is being used to do this. In-house encryption is usually is the weakest compared to
publicly available encryption tools.

A pen tester needs to review the following locations for data storage—local: files, SQLite DBs, cache, and preferences; and
external: files, cloud.

Code review can help identify places where file/data storage occurs. Typical operations that need to be reviewed include the
opening/creating of files, accessing the directory and its contents, accessing cache/preferences, opening/creating a database,
and so forth.

5.5 Summary
This chapter introduced the reader to penetration testing on Android. We covered how to pen test the Android OS. We also
discussed application security, pen testing Android applications, and static analysis. We analyzed recent security issues with
Android applications.

We suggest that the reader download a few open-source applications for Android or write one and then try out the techniques
described in this chapter. The authors also have an application on their website that the user can experiment with.

Page 17 of 17
Reprinted for W15UW/6aau200e, Orange Groups CRC Press, Taylor & Francis Group, LLC (c) 2013, Copying Prohibited