Mobile Code Security

Improve the Security of Your Mobile Applications

Increasing smartphone adoption rates coupled with the resultant rapid growth in smartphone applications have created a scenario wherein private and sensitive information is being pushed to the new device perimeter at an alarming rate. Given the rapid pace of development in the industry, the security of the application software used is becoming more and more important.

There are three main categories of mobile code security risks: malicious applications, vulnerabilities in legitimate applications, and social engineering.

Malicious Applications

Malicious applications are those that are created with the specific intent of violating the confidentiality, integrity, or ability of a user’s device or data. Malicious applications can take various forms. The most common type is spyware, such as spy pixels in email attachments or Trojans, which consist of malicious code embedded in an otherwise legitimate vehicle. Users who install Trojans believe that they are installing a game or a utility app, but instead, they download hidden spyware, phishing UIs, or unauthorized premium dialing.

The following are common attack patterns performed by mobile applications:

Activity monitoring and data retrieval
Unauthorized dialing, SMS, and payments
Unauthorized network connectivity (exfiltration or command and control)
UI impersonation
System modification (rootkit, APN proxy config)
Logic or time bomb

Vulnerabilities in Legitimate Applications

The category of mobile security vulnerabilities consists of design or implementation flaws that allow for the infiltration and execution of malicious code (exploits) in otherwise legitimate applications, often without the knowledge of the legitimate parties involved.

Common vulnerability categories include:

Sensitive data leakage (inadvertent or side channel)
Unsafe sensitive data storage
Unsafe sensitive data transmission
Hardcoded password/keys
Outdated hashing algorithms
Cookie theft
Exposure to buffer overflows
Storage of sensitive information in version control systems such as GitHub

Social Engineering

Even in those applications that adhere to industry standards and best practices in all matters of security, there is always a risk that the user will be tricked into willingly revealing sensitive information to an attacker, especially in mobile applications that handle highly sensitive or valuable data such as banking or health care.

Common social engineering techniques include:

Phishing or spear-phishing
Impersonation

The Mobile Security Stack

The mobile security stack can be divided into four distinct layers. The lowest layer is the infrastructure layer, followed by the hardware, operating system, and application layers. Each layer defines a separate section of the security model of a smartphone or mobile device and is responsible solely for the security of its defined components.

The upper layers of the stack rely upon the lower layers to ensure that their components remain safe. Lower layers, however, have no knowledge of the structure or functionality of the layers above. In addition to modularity, such a security model ensures separation of concerns by design.

Mobile Security - Infrastructure Layer

The infrastructure layer is the lowest and thus serves as the foundation of the mobile code security stack. While the majority of the functional components in this layer are owned and operated by a mobile carrier or an infrastructure provider, individual devices must interface with it to maintain their connectivity with their respective networks. These include both traditional mobile carrier networks and the infrastructure underpinning the internet.

The security of components at the infrastructure level is typically delegated to the protocols in use by the carriers and infrastructure providers themselves. Examples of such protocols include the code division multiple access protocol (CDMA), the global system for mobile communications (GSM), the global positioning system (GPS), short messaging systems (SMS), and multimedia messaging systems (MMS).

As the demand for mobile bandwidth has increased, many mobile carrier networks have switched to peered Ethernet networks and have thus acquired commonalities with the internet backbone. Due to the low-level nature of this security tier, flaws or vulnerabilities discovered here generally affect multiple platforms, carriers, and handset providers. However, given their widespread usage, such vulnerabilities are much rarer.

Mobile Security - Hardware Layer

The second tier of the mobile security stack consists of a physical unit that is typically under the direct control of the end user. The hardware layer is identified by the individual end user’s mobile device and is usually controlled by on-chip programs built into the components by the original equipment manufacturer (OEM). This hardware is called the “firmware” and is sometimes upgradeable by the OEM, although it is occasionally delivered by proxy through the phone carrier.

Security flaws or vulnerabilities discovered at this layer typically affect all end users of a particular device or hardware component. If a hardware flaw is discovered in a single manufacturer’s device, it is more than likely that all hardware revisions using a similar architecture and/or chip will be affected as well.

Mobile Security - Operating System Layer

The third tier in the mobile code security stack is the operating system (OS) layer. This layer corresponds to the software running on a device that allows communications between the hardware and the application tiers via a rigidly defined interface and is periodically updated with feature enhancements, patches, and security fixes. The OS itself is divided into two logical units, the kernel and the user space, which ensure a separation of concerns and prevent applications from directly accessing hardware resources.

All of the applications an end user interacts with are confined to the user space and access the hardware resources through a kernel-provided programming interface. Given this uniformity of adoption, the kernel forms a natural security bottleneck and is thus simultaneously the most common location where security flaws are discovered and the most rapidly fixed.

Mobile Security - Application Layer

Identified by running processes that utilize application programming interfaces provided by the operating system layer as an entry point into the rest of the stack, the application is the tier with which the end user interfaces directly. Application layer security flaws generally result from coding flaws, outdated dependencies, or bad development processes (such as credential storage in version control systems).

Developers have the greatest control over security risks in the application layer and should therefore maximize their efforts to curtail these risks. Attack types include buffer overflows, insecure storage of sensitive data, improper cryptographic algorithms, SQL injection, and reliance on dependencies where security flaws have already been discovered. Given the myriad ways in which application software interacts with the layers beneath it, the outcomes of the exploitation of application layer security vulnerabilities vary greatly, including everything from elevated operating system privilege to exfiltration of sensitive data.

How to Test for Mobile Code Security

When analyzing an individual device for security implications, take into account each of the layers of the mobile code security stack to determine the effectiveness of the security mechanisms that are in place. For each layer, determine what, if any, security mechanisms and mitigations the manufacturer has implemented and whether those mechanisms are sufficient for the type of data you plan to store and access on the device. The threat analysis must be repeated under different threat models (i.e., what parts of the system are compromised by the attacker).

Vulnerabilities may occur at various points in the application’s lifecycle. Vulnerabilities that occur during the development stage may be addressed by unit testing and code linting. For vulnerabilities that occur during the end of the development sprint, you must conduct a pull test review. For vulnerabilities occurring during the application lifecycle, a code review/audit is in order. Finally, after application development, you may deal with vulnerabilities that occur via penetration testing.

More FREE Security Threat Guides from Veracode