Mobile Application Security

Overview
Security leaks and confidential data disclosure from web and mobile apps are
quite common today. With the increasing number of technologically rich mobile
applications hitting the market, mobile phones have become the new target for
hackers.

Android is one of the most popular mobile phone operating systems and is
claimed to hold more than 36% of the market share. Due to its popularity,
Android is more prone to attacks.

Objective
This white paper elucidates the necessity of security testing mobile
applications, the major threats that mobile applications are susceptible to,
methodologies and tools used for mobile application security testing, best
practices to create a robust mobile app, and some important guidelines for
users and developers.

Audience
 Testers who want to specialize in mobile application security testing.
 Developers can refer to this white paper to develop secure applications.
 Mobile phone users can understand threats and learn how to
protect themselves from attacks.

Scope
The report covers security testing of Android applications. It does not include
mobile application development, application installation or similar areas.
What is Mobile Application Security
Testing?
Mobile phone usage is growing by the day. Unlike the situation a decade ago,
today, people feel handicapped and uncomfortable without their mobile device
close at hand. There have been great advances in mobile computing. People can
download apps that help them socialize, keep fit, get directions, transact, shop,
and much more. There are millions of mobile applications available in app stores
that make our simple life simpler.

Amidst all the great things that have been accomplished in the mobility space,
there is a global community of hackers who have been watching the mobile
space closely. They use newer and bolder techniques to break into mobiles
and applications, so app developers need to be cautious.

Mobile applications security testing is the process of reviewing the application

characteristics and the code for vulnerabilities. It is a combination of static
analysis, code review, and penetration testing.

Applications Become Prone to Attacks When:

1. Security flaws originate at the development stage.
2. An application is cloned with extra functions that run in the background
and perform malicious actions.

In both cases, the application can compromise sensitive information contained

in user devices. Security testing involves analysis to find out if the application
is vulnerable. The application is dissected into component code and assets.
The code is checked for flaws and penetration testing is done to determine
whether unauthorized access is possible.
Owasp
The Open Web Application Security Project (OWASP) is a worldwide nonprofit
charitable organization focused on improving the security of software. OWASP
is involved in detecting and combating leaks in application security and
techniques. They provide testers and developers guidelines to create secure
applications.

OWASP Top Ten

The OWASP Top Ten is a list of vulnerabilities determined by identifying some
of the most critical risks faced by mobile platforms. The OWASP Top 10 is
referenced by many standards, books, tools, and organizations such as MITRE,
PCI DSS, DISA, FTC, and others.

OWASP Mobile Top 10 Vulnerabilities

Based upon survey and feedback collected from the worldwide community, the
Open Web Application Security Project foundation gave us the OWASP mobile
security risks for the first time in 2011. After that, they released new lists in 2014
and 2016 — the latter being the latest and most current OWASP mobile top 10
list.

While there’s one exact carry-over from the 2014 top 10 mobile risks list,
the 2016 top 10 mobile risks list is mainly different in terms of the categories
break down. For example, in the 2016 list, one of the items from the 2014 list
was removed and two new risks were added. They also split some categories in
half to address them separately.

A side-by-side comparison of OWASP 2014 and 2016 mobile risks.

 M1. Improper Platform Usage

The latest OWASP mobile top 10 list ranks improper platform usage as the
leading mobile security vulnerability. Whether you’re an Android user or an iOS
customer, each of these platforms are expected to adhere to certain
developmental guidelines for security purposes. However, apps may
unintentionally violate these published guidelines, best practices, or goof up in
their implementation process. That is what this first mobile security risk talks
about.

This threat refers to the misuse of any platform feature of the Android or iOS
operating system or failure to incorporate platform security controls. This
includes issues concerning improper use of security controls and platform
features that are a part of the mobile operating system, such as:

 Misuse of the iOS Touch ID feature, which can result in unauthorized access to
the device.
 Incorrect use of the iOS Keychain for instance by storing session keys in the app
local storage,
 Requesting excessive or wrong platform permissions,
 Android intents (used to request an action from another app component) that
are marked public may reveal sensitive information or permit unauthorized
execution.

Remediation Measures for This Vulnerability:

This OWASP mobile security risk is something that you must address on the
server side of things. Alongside following platform development guidelines, using
secure coding practices and applying the right configuration settings on the
server-side helps to minimize risks. Additional mitigation strategies to reduce
platforms from being used improperly include the following:

 Restricting apps from communicating with each other, limit access, implement
restrictive file permissions, etc.
 Applying the most restrictive protection class for iOS keychains and adopt best
practices to avoid weak implementation of any controls.
 M2. Insecure Data Storage
Next on the OWASP mobile top 10 list is insecure data storage. Your mobile
device may get lost or stolen and land in the hands of an adversary. Or a piece of
malware, acting on the attacker’s behalf, may execute on the device, and the
attacker might be able to exploit vulnerabilities that leak personal information
and gain access to sensitive data.

While it isn’t always feasible to have apps that don’t store data, it is crucial to
store that data securely in a place that won’t be accessible to another app or an
individual jailbreak or rooting a mobile device is sufficient to dodge encryption
protection, and dev teams must never assume that attackers won’t have access
to filesystems if they’re easily accessible.

Remediation Measures for This Vulnerability:

Threat model the app to understand what information assets are processed by
the application and how the APIs handle the data. Doing this helps you to:

 Assess whether encryption is applied effectively and how the encryption keys are
protected.
 Implement technologies to harden the code against tampering by using
obfuscation, protection against buffer overflows and so on,
 Avoid storing/caching data where feasible, and
 Deploy sound authentication and authorization checks.

M3. Insecure Communication

Insecure communication ranks third in 2016 OWASP mobile top 10 list. If the
data travels unencrypted in cleartext, anyone monitoring the network can
capture and read all the information being sent over the wire.

Mobile apps commonly exchange data in a client-server model, and it must be

transmitted over the device’s carrier network and the internet securely. The
traffic can be intercepted by proxies, cell towers, or an adversary compromises
your Wi-Fi or installs malware on your device. So, what can you do it mitigate
vulnerabilities associated with these types of data exchanges.
 Remediation Measures for This Vulnerability:
To avoid data from being stolen as it travels across the network, rely on industry-
standard encryption protocols and other general best practices.

 Deploy SSL/TLS certificates from trusted certificate authorities (CA) to secure all
communication channels.
 Alert users if an invalid SSL/TLS certificate is detected or if the certificate chain
verification process fails.

M4. Insecure Authentication

Insecure authentication comes next on the OWASP mobile security
vulnerabilities list. Before granting access, mobile apps need to verify the identity
of the user. An authentication bypass is often executed by leveraging existing
vulnerabilities, such as improper validation of service requests done by the
mobile app’s backend server. Mobile apps need to verify and maintain user
identity, especially during the transmission of confidential data such as financial
information.

Remediation Measures for This Vulnerability:

Weaknesses in the authentication mechanism for mobile apps can be exploited
by an attacker. Capitalizing on those weaknesses allows them to bypass
password requirements or gain additional permissions leading to data theft and
other damages.

So, what can you do to stop it?

 Avoid local authentication methods. Instead, shift this responsibility to the

server-side and download application data only after a successful authentication.
 Refrain from using vulnerable authentication methods (such as device identity),
don’t store passwords locally, implement multi-factor authentication (MFA),
disallow using all four-digit PIN as passwords where feasible, etc.
 M5. Insufficient Cryptography
There are two situations in which a system’s cryptography may get compromised
to reveal sensitive data:

1. The underlying algorithm used for encryption and decryption might be weak, or
2. The cryptographic process itself has implementation flaws.

Broken cryptography in mobile apps can be the result of one of several factors.
This list of potential causes includes:

 Bypassing built-in code encryption algorithms,

 Improperly managing your digital keys, and
 Using custom or deprecated encryption protocols.

Remediation Measures for This Vulnerability:

Insufficient cryptographic controls can lead to the unauthorized retrieval of
sensitive data (such as personal information about the user) from the device.

 Apply strong cryptographic standards as recommended by the National Institute

of Standards and Technology (NIST).
 Avoid storing any sensitive data on the device whenever possible.

M6. Insecure Authorization

Not all users are created equal! Some users may be regular users, while others
may require additional permissions and privileges, such as admin users. Poor
authorization schemes fail to verify not who the user is but whether the user is
sanctioned to access the resources they’re requesting. Failure to properly
enforce identity as well as the permissions given to the users allows hackers to
log in as legitimate users and perform privilege escalation attacks.

Remediation Measures for This Vulnerability

The impact of insecure authorization is similar to insecure authentication. They
both may lead to data theft, reputational damage, and even noncompliance fines
and penalties.
 Ensure that for each request, backend processes verify that incoming identifiers
associated with an identity match up and actually belong to the identity.
 Validate the roles and permissions of an authenticated user using the
information on backend systems and not based upon the information supplied
by the mobile device.

M7. Client Code Quality

This category on the list of OWASP mobile security risks is a bit of a catch-all for
mobile client issues relating to faulty code implementations.

An attacker may pass crafted inputs to function calls made within an app in an
attempt to execute them or observe the application’s behaviour. It may lead to
degradation of performance, increased memory usage, etc. Note that the
mistakes in code need to be fixed in a localized way since they arise on the
mobile client and are different from server-side coding errors. There could be
code-level mistakes in mobile apps that may lead to issues such as:

 Format-string vulnerabilities,
 Buffer overflows,
 Integration with insecure third-party libraries,
 Remote code execution

Several apps rely on third-party libraries to build their applications, which often
contain bugs and are not well tested. These issues are outside the control of the
app developer since they don’t own the code. More often than not with code-
level bugs, the solution is to rewrite some of the code running on the device. But
what else can you do?

Remediation Measures for This Vulnerability:

Poor code quality issues may lead to remote code execution and other
vulnerabilities and issues that we’ve already mentioned. Thankfully, there are a
few things you can do to help mitigate these issues:

 Test for buffer overflows, memory leaks, etc. using automated tools, rely on
source code reviews, and write code that’s easy to understand and well
documented.
 Use consistent coding patterns across the organization.
 M8. Code Tampering
App stores sometimes contain tampered versions of mobile apps. An example of
a modified app is where a hacker modifies the app’s binary to include malicious
content, install a backdoor, etc. Attackers can re-sign these counterfeit apps and
publish the modified version onto third-party app stores. They can also deliver
them to a victim directly via a phishing attack to trick them into downloading the
app.

Remediation Measures for This Vulnerability:

Tampering with the code can lead to revenue loss, identity theft, reputational
and other damages.

 The app must be able to identify any code integrity violation (if additional code
has been added or modified) and react suitably to it at runtime. Using something
like a code signing certificate could help to let users know about the code
alterations.
 Implement anti-tamper techniques that prevent illicit apps from executing via
implementation of checksums, digital signatures, code hardening, and other
validation methods.

M9. Reverse Engineering

Attackers may reverse engineer the app and decompile it to perform some code
analysis. This is particularly dangerous since the attacker can understand,
inspect, and modify the code to include harmful functionality or transmit
undesired advertisements. Once they understand how the app operates, they
can modify it using tools such as IDA Pro, Hopper, and other binary inspection
tools. Once they get the app to behave in the desired way, they can recompile
and run the app.

Remediation Measures for This Vulnerability:

In order to prevent reverse engineering, the attacker must be unable to de-
obfuscate the code using tools like IDA Pro and Hopper.
 M10. Extraneous Functionality
Sometimes developers may unintentionally leave backdoors or additional
functionalities in mobile apps that aren’t apparent to end users via the interface.
These products may get released into the production environment with a feature
not intended to be made available, creating security risks.

These weaknesses can typically be exploited by hackers from their systems

directly without requiring any participation from regular users. They may
examine configuration files, analyse the binary, etc. to discover functionalities in
the back-end system that cybercriminals can leverage to perform an attack.

Remediation Measures for This Vulnerability:

One of the most effective ways to prevent these types of mobile app
vulnerabilities is to perform manual secure code review. What this does is allow
you to:

 Examine the mobile app’s configuration settings to detect any hidden switches.
 Ensure that the logs don’t hold exceedingly descriptive statements about
backend systems.

Types of Mobile Application Security

Testing

We Can Divide Mobile Application Testing into Three Parts:

1. Dynamic analysis
2. Black box security testing
3. Static analysis & code review
Dynamic Analysis
In dynamic analysis, the behavior of an application is analyzed after installing it
on various versions of compatible and non-compatible devices. This method of
testing helps testers understand possible flaws. The behavior of the
application is observed and test cases are created based on observations.

Black Box Security Testing

Black box testing involves treating the application like a black box that produces
output to input stimuli. The tester feeds the application with inputs and
observes the response. The input strings for the application are crafted based
on the results of dynamic analysis and the OWASP testing methodology. The
application is tested thoroughly with several well-crafted attacks to make sure
the application can defend itself.

Static Analysis & Code Review

Static analysis and code review covers the analysis of the application code and
coding defects. The code of the application is analyzed using static analyzers.
The code is reviewed manually and checked for vulnerabilities that may arise
due to poor coding practices.

With static analysis, the business logic and the security of the application are
covered. The code reviewer tests the application for each taint location in the
application.

Identifying and Protecting Data in

Mobile Devices

Identification and protection of sensitive data on a mobile device is an

important aspect of mobile application development. Mobile devices are
expected to replace desktop computers in the near future. With
improvements in technology, mobile devices have managed to scale up to
match the complex computing capabilities of a desktop computer. From
management of email account credentials to control of automobiles, mobile
phones can do it all today.

Hackers attack an application with the intention to derive certain value. The
more valuable the target is, the more prone it is to attacks. For developers, the
data contained in the application is valuable. Every piece of data that the
application handles is significant and developers must handle it with care.
Protection of data should be one of the primary goals of a mobile developer.

The close interaction with an operating system allows the application on

devices to access more data than a browser on a computer. This helps to build
innovative features into the application. The data is vulnerable when the entire
application is not developed by the same team. There may be APIs and code
from other sources; some applications tend to be interconnected. These
possibilities cause the data in the application to leak. Additionally, third-party
services such as advertising are gaining ground. If these services are not
integrated carefully, it can lead to disclosure of significant amounts of personal
data.

Mobile users are ignorant about the technical functionality of an application

and assume that application data is secure. Users usually install applications
without verifying source and remain clueless about how the application
processes data. Users remain unaware even when the application makes an
external connection to the internet to process the data. Hackers take
advantage of user ignorance to exploit data on the devices.

How to Identify Sensitive Data?

Every piece of data is sensitive. Data cannot be classified as sensitive and non-
sensitive. Users enter data into an application under the assumption that
security will not be compromised. Considering the importance users give to
data, applications should be designed to treat every little piece of user data as
sensitive.
Examples of Personal Data Users Prefer to Keep Private:
 Their location
 Contacts
 Unique device and customer identifiers (such as IMEI, IMSI, UDID and
phone number)
 Identity of the data subject
 Identity of the phone (make of the phone)
 Email
 Browsing History
 Credit card and payment data
 Phone call logs, SMS or instant messaging

Protecting Data—Things to Remember

 The data handled by an application should be protected from storage to
transit
 Access to data being stored in another field is to be taken into
consideration while handling data
 An important location where data leak can occur is the side channel data
leakage
 Data should be logged or shown in error logs
 Each piece of code that handles data needs to be crafted carefully
 User data should be encrypted using smart algorithms before being stored
on the device
 The encryption method should use a strong key
 The data stored on the device should be accessible only to the
application that stores the data
 The data should not be given global read privileges leading to other
applications residing on the device
 Whenever the data is transferred to other locations, such as a server,
the application should use https
Security Testing Tools

Qasat
Qasat is an Android static analyzer. The application helps code reviewers
decompose an Android Package File (APK) and understand the application
better. The analyzer decomposes an APK file into its components. The assets in
the applications are enumerated as lists. Qasat also enumerates code
fragments that are considered sensitive. Qasat allows the user to save the
code into a location of their choice. This helps the code reviewer to review the
code.

Mobile Security Framework

Mobile Security Framework (MobSF) is an automated, all-in-one mobile
application (Android/iOS/Windows) pen-testing, malware analysis and security
assessment framework capable of performing static and dynamic analysis.
MobSF supports mobile app binaries (APK, XAPK, IPA & APPX) along with
zipped source code and provides REST APIs for seamless integration with your
CI/CD or DevSecOps pipeline.The Dynamic Analyzer helps you to perform
runtime security assessment and interactive instrumented testing.

Android Emulator
Android Emulator is an application that emulates and tests virtual android
devices. Applications can be installed on virtual machines and used as if they
are installed on a real device. Emulator is free to download and easy to install.
The emulator is also included in the Android SDK.

Other Penetration Testing Tools

There are lot of other penetration testing tools (Fuzzers, Crawlers, Spiders and
others) and scripts that are used to attack applications.
Thank You