comp.org.uk

Networking | Programming | Security | Linux | Computer Science | About

Mobile Application Security

Mobile applications are affected by a range of security vulnerabilities, many of which are inherited from traditional attacks against web and desktop applica- tions. However, several other classes of attack are specific to the mobile area and arise due to the way in which mobile applications are used and the relatively unique entry points and the attack surfaces that these apps create. Consider the possible attack surfaces for a mobile application that developers should be aware of and look to defend against:

Mobile applications can derive input from a large number of possible sources, which creates a significant number of possible entry points. For example, seeing applications accept data from one or many of the following is not uncommon: near field communication (NFC), Bluetooth, camera, microphone, short message service (SMS), and universal serial bus (USB) or quick response (QR) codes to name but a few.

The most serious attacks against mobile applications are those that expose sen- sitive data or facilitate a compromise of the host device. These vulnerabilities are more often than not limited to the mobile end user’s data and device as opposed to all users of the service. Although server‐side vulnerabilities pose the greatest risk to mobile application deployments as a whole because they can expose unrestricted access to back end systems, these issues are well documented and understood. Server‐side vulnerabilities in mobile applications are not covered in the context of this book; however, I highly recommend The Web Application Hacker’s Handbook if you would like to know more about this attack category.

Mobile application security is still somewhat misunderstood and has not fully matured as an area of focus; indeed, the m ajority of mobile applications are still considered insecure. Here are some of the most popular forms of mobile vulnerabilities:

Common Mobile Vulnerabilities

Insecure data storage

This category of vulnerability incorporates the various defects that lead to an application’s storing data on the mobile device in either cleartext, an obfuscated format, using a hard-coded key, or any other means that can be trivially reversed by an attacker.

Insecure transmission of data

This involves any instance whereby an application does not use transport layer encryption to protect data in transit. It also includes cases where transport layer encryption is used but has been implemented in an insecure manner.

Lack of binary protections

This flaw means that an application does not employ any form of protection mechanism to complicate reverse engineering, malicious tampering, or debugging.

Client‐side injection

This category of vulnerability describes scenarios where untrusted data is sent to an application and handled in an unsafe manner. Typical origins of injection include other applications on the device and input populated into the application from the server.

Hard‐coded passwords/keys

This flaw arises when a developer embeds a sensitive piece of information such as a password or an encryp- tion key into the application.

Leakage of sensitive data

This involves cases where an application unintentionally leaks sensitive data through a side channel. This specifically includes data leakages that arise through use of a framework or OS and occur without the developer’s knowledge.

Key Problem Factors

The core security problems in mobile applications arise due to a number of fac- tors; however, vulnerabilities typically occur when an application must handle or protect sensitive data or process data that has originated from an untrusted source. However, several other factors have combined to intensify the problem.

Underdeveloped Security Awareness

Unlike most web applications where the attack surface is limited to user‐derived input, mobile application developers have a number of different scenarios to con- sider and protect against. Mobile application development is fairly unique when compared to the development of other applications in that developers cannot trust the host operating system or even their own application. Awareness of the many attack surfaces and defensive protections is limited and not well understood within the mobile development communities. Widespread confusion and misconceptions still exist about many of the core concepts involved in mobile security. A prime example is that many developers believe that they don’t need to encrypt or protect data that is persistently stored on the device because it is encrypted through the data-at-rest encryption that comes standard with many devices. As you will discover, this assumption is not accurate and can expose sensitive user content.

Ever‐Changing Attack Surfaces

Research into mobile device and application security is a continually evolving area in which ideas are regularly challenged and new threats and concepts discovered. Particularly on the device side, discovering new vulnerabilities that may undermine the accepted defenses that an application employs is common. A prime example of this was the discovery of Apple’s “goto fail” vulnerability, which undermined the integrity of what was previously believed to be a secure communications channel. In this instance even recommended protections such as certificate pinning could be bypassed, which lead to many developers and security professionals researching and implementing secondary encryption schemes to protect data inside the SSL/TLS channel. These types of vulnerabilities demonstrate how on‐going research can affect or change the threat profile for an application even partway through a development project. A development team that begins a project with a comprehensive understanding of the current threats may have lost this status and have to adapt accordingly before the application is completed and deployed.

Economic and Time Constraints

Most application development projects are governed by strict resource and time constraints, and mobile application development is no exception. The economics of an application development project often mean that having permanent security expertise throughout the development process is infeasible for companies, par- ticularly in smaller organizations that on the whole tend to leave security testing until late in a project’s lifecycle. Indeed, smaller organizations typically have much smaller budgets, which means they are often less willing to pay for expensive security consulting. A short time‐constrained penetration test is likely to find the low‐hanging fruit, but it is likely to miss more subtle and complex issues that require time and patience to identify. Even in projects with a permanent security presence, strict time constraints may mean that adequately reviewing every release can prove a challenging task. Development methods such as Agile, in which there are many iterations in a short space of time, can often intensify this challenge.

Custom Development

Mobile applications are typically developed by either in‐house developers or third‐party development teams, or in some cases a combination of the two. In general, when organizations are regularly developing multiple applications, components that have been thoroughly tested will find themselves being reused across projects; this often promotes more robust and secure code. However, even when applications reuse established components from other projects, seeing libraries or frameworks bolted on to the project that may not have been developed by the project team is not uncommon. In these cases, the main project developers may not have full awareness of the code and misuse could lead to the introduc- tion of security defects. Furthermore, in some cases the libraries may contain vulnerabilities themselves if they have not been thoroughly security tested. An example of this is the addJavascriptInterface vulnerability that affected the Android Webview component and when exploited resulted in a remote com- promise of the device. Research found that this vulnerability was bundled with the libraries used to provide ad integration and potentially affected a significant number of applications.


Published on Wed 04 December 2013 by Randy Nugent in Security with tag(s): mobile security