Industry analysts’ findings reveal that in 2011, the number of
users to access banking services from their smartphones was a gigantic 300
million, which is further expected to rise to a whopping 530 million by 2013!The
exponential growth of smart phones and their widespread usage have brought to
the fore the criticality of mobile app security from an enterprise safety
standpoint.The
rapid adoption of mobile devices and mobile apps has led to a significant and
unbounded security risk for any enterprise. The mobile app threat is escalating
rapidly – spanning simple “premium SMS and call” attacks that are directly
monetized by running up a victim’s bill, to hampering
full-scale mobile functionality.
The need for enterprises to equip their mobile workforce with
productive, meaningful applications is more critical than ever. Such
applications need to ensure the security of sensitive data on the device as
well as internal networks. Enterprise mobile applications extend corporate
networks beyond the perimeter devices, thus potentially exposing these
organizations to new types of security threats.
As smartphones are natural devices for data management,
they are easy sources of sensitive data like credit card numbers,
authentication information, private information, activity logs (calendar, call
logs) and the like. The graphic below shows the relevant statistics about types
of information stored by users in mobile devices.
Survey
carried out by ESET Latin America(Trends for 2013)
Three prime target components for
attackers are – Data, Identity and Availability.
Android platform remains the prime target for both
mobile malware and spyware miscreants. According to one of McAfee’s recent findings,
there are very few mobile threats that are not directed at Android phones!After
an apparent but slight decline earlier in the year, Android malware has
rebounded and has almost doubled.
McAfee
Threats Report: Third Quarter 2012
Here's peek into 10 key inhibitors for enterprise apps -
Most mobile applications
have a need to store sensitive information, either in its local storage or on SD
card. The information might be passwords, account records, or proprietary
information.
Frequently, encryption
techniques are used to protect this sensitive information. While encryption has
become relatively easy to implement and use, developers still frequently make
mistakes while integrating it. Developers may overestimate the protection
gained by using encryption and not be as careful in securing other aspects of
the mobile application.
A few areas where
mistakes are commonly made include:
•
Sensitive data left unprotected.
•
Weak or global permissions
- Insecure
storage of keys, certificates, and passwords
- Improper
storage of secrets in memory
- Poor
sources of randomness
- Poor
choice of algorithm
- Attempting
to invent a new encryption algorithm
- Failure
to include support for encryption key changes and other required
maintenance procedures
The impact of these
weaknesses can be devastating to the security of a mobile.
Prevention
Tips –
•
Store ONLY what is absolutely required
•
Never use public storage areas (i.e. SD
card)
•
Leverage secure containers and platform
provided file encryption APIs.
•
Do not grant files world readable or
world writable permissions
•
Do not store historical GPS/tracking or
other sensitive information on the device beyond the period required by the
application
•
There is currently no standard secure
deletion procedure for flash memory (unless wiping the entire medium/card).
Therefore data encryption and secure key management are especially important.
Weak
server controls applies on backend systems causing loss of data via cloud
storage. The majority of mobile applications interact with the backend APIs
using REST/Web Services or proprietary protocols. Insecure implementation of
backend APIs or services, and not keeping the back-end platform
hardened/patched will allow attackers to compromise data on the mobile device
when transferred to the backend, or to attack the backend through the mobile
application.
These
are:
•
Not mobile specific, but essential to
get right
•
Applicable to backend service
Prevention
Tips –
•
Carry out a specific check of your code
for sensitive data unintentionally transferred, any data transferred between the
mobile device and web-server back- ends and other external interfaces - (e.g.
is location or other information included within file metadata).
•
Ensure that the backend platform
(server) is running with a hardened configuration with the latest security patches
applied to the OS, Web Server and other application components.
•
All backend services (Web Services/REST)
for mobile apps should be tested for vulnerabilities periodically, e.g. using
static code analyzer tools for testing and finding security flaws.
•
Ensure adequate logs are retained on the
backend in order to detect and respond to incidents and perform forensics
(within the limits of data protection law).
•
Understand the additional risks mobile
apps introduce into existing architecture.
Network
spoofing attacks, surveillance. The majority of smart phones are capable of
using multiple network mechanisms including Wi-Fi, provider network (3G, GSM,
CDMA and others), Bluetooth etc. Sensitive data passing through insecure
channels could be intercepted.
These
can be due to:
•
Complete lack of encryption for
transmitted data
•
Weakly encrypted data in transit
•
Authorization header sent over HTTP
•
Strong encryption, but ignoring security
warnings
•
Ignoring certificate validation errors
•
Falling back to plain text after
failures
Prevention
Tips –
•
Assume that the provider network layer
is not secure. Modern network layer attacks can decrypt provider network
encryption, and there is no guarantee that the Wi-Fi network will be appropriately
encrypted.
•
Applications should enforce the use of
an end-to-end secure channel (such as SSL/TLS) when sending sensitive
information over the wire/air (e.g. using Strict Transport Security - STS).This
includes passing user credentials, or other authentication equivalents. This
provides confidentiality and integrity protection.
•
Use strong and well-known encryption
algorithms and appropriate key lengths.
•
Be very cautious in allowing self-
signed certificates. Do not disable or ignore SSL chain validation.
•
SMS, MMS or notifications should not be
used to send sensitive data to or from mobile end-points.
•
When security exceptions are thrown, it’s
generally for a reason… DO NOT ignore them!
This type of
attack exploits buffer overflow vulnerability in targeted client software
through injection of malicious content from a custom-built hostile service.
The server may
look like a valid server, but in reality it may be a hostile server aimed at
fooling the client software. For instance the server can use honey pots and get
the client to download malicious code.
The hostile
server may also attempt to install and run malicious code on the client
software. That malicious code can be used to scan the client software for
buffer overflow.
Attack Execution Flow:
•
The attacker creates a custom
hostile service
•
The attacker acquires
information about the kind of client attaching to her hostile service to
determine if it contains exploitable buffer overflow vulnerability.
•
The attacker intentionally
feeds malicious data to the client to exploit the buffer overflow vulnerability
that she has uncovered.
•
The attacker leverages the
exploit to execute arbitrary code or to cause a denial of service.
These
attacks generally occur in apps using browser libraries:
•
Pure web apps
•
Hybrid web/native apps
Also,
mobile attackers can:
•
Abuse phone dialer +SMS
•
Abuse in-app payments
Prevention
Tips –
•
Sanitize/Escape un trusted data before
rendering or executing it
•
Use prepared statements for database
calls
•
Minimize the sensitive native
capabilities tied to hybrid web functionalities
This
is part mobile, part architecture threat. Unauthorized individuals may obtain
access to sensitive data or systems by circumventing authentication systems
(logins).
This
can result in unauthorized access and loss of confidential data.
Prevention
Tips –
•
Implement user
authentication/authorization and session management correctly
•
Use authentication that ties back to the
end user identity (rather than the device identity).
•
Never use device ID or subscriber ID as
sole authenticator.
•
Use context to add security to
authentication - e.g. IP location, etc...
•
Authenticate all API calls
Unauthorized
individuals may obtain access to sensitive data by reusing valid tokens or
cookies.
Mobile
app sessions are generally MUCH longer due to the convenience and reusability.
Apps maintain sessions via:
•
HTTP cookies
•
OAuth
tokens
•
SSO authentication services
In
case of mobile apps it’s always a bad idea to use a device identifier as a
session token. This can lead to unauthorized access and circumvent licensing
and payments.
Prevention
Tips –
•
It is important to ensure that the
session management is handled correctly after the initial authentication, using
appropriate secure protocols. For example, require authentication credentials
or tokens to be passed with any subsequent request (especially those granting
privileged access or modification).
•
Don’t be afraid to make users
re-authenticate every so often
•
Ensure that tokens can be revoked
quickly in the event of a lost/stolen device
•
Utilize high entropy, tested token
generation resources
Data
leakage. Users may install applications that may be malicious and can transmit
personal data (or other sensitive stored data) for malicious purposes. It can
also be leveraged to bypass permissions and security model
resulting in confidentiality loss and unauthorized consumption of paid
resources.
Prevention
Tips –
•
Check caller’s permissions at input
boundaries
•
Vet the security/authenticity of any
third party code/libraries used in your mobile application (e.g. making sure
they come from a reliable source, with maintenance supported, no back-end Trojans)
•
Pay particular attention to validating
all data received from and sent to non-trusted third party apps (e.g. ad
network software) before processing within the application.
•
Track all third party frameworks/APIs
used in the mobile application for security patches. A corresponding security
update must be done for the mobile applications using these third party
APIs/frameworks.
This is
generally a result of mix of not disabling platform features and programmatic
flaws. Generally sensitive data ends up in unintended places like:
•
Web caches
•
Keystroke Logging
•
Screenshots
•
Logs (system, crash)
•
Temp directories
Also, there is a need to understand what 3rd party libraries are doing with
user data (i.e. ad networks, analytics)
Prevention
Tips –
•
Never log credentials, or other
sensitive data to system logs
•
Remove sensitive data before screenshots
are taken, disable keystroke logging per field, and utilize anti-caching
directives for web content
•
Debug your apps before releasing them to
observe files created, written to, or modified in any way
•
Carefully review any third party
libraries you introduce and data they consume
•
Test your applications across as many
platform versions as possible
These are the result of broken
implementations using strong crypto libraries or custom (easily defeated)
crypto implementation.
Always
keep in mind:
•
Encoding != Encryption
•
Serialization != Encryption
Prevention
Tips –
•
Never store key with encrypted data, it
negates everything
•
Leverage battle-tested crypto libraries
vice writing your own
•
Take advantage of what your platform
already provides. Utilize file encryption APIs
•
Leverage secure containers
Unsafe
sensitive data storage, attacks on decommissioned phones unintentional
disclosure: Mobile devices (being mobile) have a higher risk of loss or theft.
Adequate protection should be built in to minimize the loss of sensitive data
on the device.
Commonly found “treasures” are:
•
API keys
•
Passwords
•
Sensitive business logic
Prevention
Tips –
•
In the design phase, classify data
storage according to sensitivity and apply controls accordingly (e.g.
passwords, personal data, location, error logs, etc.). Process, store and use
data according to its classification. Validate the security of API calls
applied to sensitive data.
•
Store sensitive data on the server
instead of the client-end device. This is based on the assumption that secure
network connectivity is sufficiently available and that protection mechanisms
available to server side storage are superior.
•
When storing data on the device, use a
file encryption API provided by the OS or other trusted source. Some platforms
provide file encryption APIs which use a secret key protected by the device
unlock code and deleteable on remote kill. If this is available, it should be
used as it increases the security of the encryption without creating extra
burden on the end-user. It also makes stored data safer in the case of loss or
theft. However, it should be born in mind that even when protected by the
device unlock key, if data is stored on the device, its security is dependent
on the security of the device unlock code if remote deletion of the key is for
any reason not possible.
•
Do not store/cache sensitive data
(including keys) unless they are encrypted and if possible stored in a
tamper-proof area
•
Do not store historical GPS/tracking or
other sensitive information on the device beyond the period required by the application
Alt + 0153..... ™... trademark symbol
Alt + 1.......☺....smiley face
