This paper covers security issues that a security analyst may look for during vulnerability assessment and penetration testing on case–by-case basis. Issues covered in the paper are generic and can be considered across all the mobile platforms.

1. Generic Threats
to Mobile
Applications
Vikrant Kansal
Information Security Analyst
vikrant.kansal@gmail.com
21/Jan/2013
1Page 0 of 11

2. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
Table of Contents
Abstract………………………………………………………………………………………………………………………………2
Background…………………………………………………………………………………………………………………………2
Fingerprinting………………………………………………………………………………………………………………………2
Authentication and Authorization……………………………………………………………………………………….3
Data & Information Management……………………………………………………………………………………….4
Input Validation…………………………………………………………………………………………………………………..6
Information Leakage in Transit………………………………………………………………………………………….6
Session Management Issues………………………………………………………………………………………………7
Secure Coding & Development Practices……………………………………………………………………………8
Known Vulnerability & Patch Issues……………………………………………………………………………………8
System Privilege Issues………………………………………………………………………………………………………9
Weak Cryptography…………………………………………………………………………………………………………….9
Cross Site Scripting……………………………………………………………………………………………………………..9
Cross Site Request Forgery……………………………………………………………………………………………....9
3rd Party Application Integration Issues…………………………………………………………………………….9
About The Author……………………………………………………………………………………………………………….10
References………………………………………………………………………………………………………………………….10
1 21 Jan 2013 | Vikrant Kansal

3. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
Abstract
As we all know that "Mobile/Smart Phone" usage is increasing day by day, people are switching
from their Laptop/PC to mobile phone to get connected to the Web World.
Mobile applications for social networking, corporate e-mailing, financial transactions, monitoring
and reporting are very common amongst Mobile/ Smart phone users.
We have also observed that as the usage of Mobile phone is increasing, the cases of mobile
security issues are also increasing. Attackers are now targeting Mobile/Smart phone users to get
sensitive information like credit card details, confidential documents, contact information to name
a few.
This paper covers security threats to mobile applications and helps security analysts during
vulnerability assessment.
Background
This paper covers security issues that a security analyst may look for during vulnerability
assessment and penetration testing on case–by-case basis. Issues covered in the paper are
generic and can be considered across all the mobile platforms.
Security issues are covered under the below mentioned points
 Fingerprinting
 Authentication & Authorization
 Data & Information Management
 Input Validation
 Information Leakage in Transit
 Session Management Issues
 Secure Coding & Development Practices
 Known Vulnerability & Patch Issues
 System Privilege Issues
 Weak Cryptography
 Cross Site Scripting
 Cross Site Request Forgery
 3rd Party Application Integration Issues
1. Fingerprinting
While identifying security threats in an application, it is recommended to start with fingerprinting.
Fingerprinting helps security professionals to gather information that is available without putting
much effort. What we can look for is covered as below:
1.1 Mobile Application Port Scanning
Perform port scanning after installing the application and look for opened/listening ports. Any
opened port may allow the attacker to attack. Make sure that all the opened/listening ports have a
purpose in application functioning.
2 21 Jan 2013 | Vikrant Kansal

4. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
1.2 Mobile Application Banner Grabbing
Banner grabbing can help to identify initial level threats to the application. Easy availability of
application version, contact information and any other important information helps the attacker to
plan the attack in the respective application. Attacker can exploit a known vulnerability in an
unpatched application version. Ensure that banner should not reveal any sensitive information
about application that helps the attacker.
2. Authentication & Authorization
2.1 Default Login Credentials
Application that allows some default login credentials is prone to unauthorized access to
information. Confirm that no default login credentials are allowed.
2.2 Clear Text Password
Confirm that an application does not show password in clear-text. It allows an attacker to grab the
user’s password easily which can further provide access to unauthorized information.
2.3 Simple Username, Password or Username/Password combinations
Make sure that authentication credentials are strong enough and cannot be guessed. Weak
username and password lead to unauthorized application access.
Avoid using swipe based passwords as they are unsafe and prone to smudge-attacks.
2.4 Repeat/Consecutive Failed Password Handling
Identify whether application has proper handling for repeated password failure or not. If
application does not have any challenge question, Captcha or locking mechanism then application
is prone to brute force attack.
2.5 Multiple factor authentication
It is good that application use multiple factor authentications to access sensitive information, like
performing financial transactions.
If application has 2-factor authentication in place and is using one time password (OTP) technique
then check for any flaw in OTP implementation. If possible avoid sending OTP using SMS. Attacker
may install the SMS receiver on device to get the SMS and can further access the user account.
2.6 Unique Identification Key Generation issue
Check whether unique identification key used for validation and authentication is strong or not.
Weak algorithm, that uses common identifier like IMEI number as key, can be spoofed by any
attacker. “OAuth” based token implementation can be helpful to avoid such attacks.
2.7 Same password for all purposes
Many applications have multiple services. Especially in case of financial applications a user can
perform multiple transactions. So make sure that the same password should not be used for
multiple purposes. If possible, use a separate password for critical transactions.
2.8 Captcha Support
Check for Captcha implementation within application. Weak Captcha implementation can be
vulnerable to brute force attack.
3 21 Jan 2013 | Vikrant Kansal

5. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
2.9 Invalid Certificate Handling
Invalid certificates should be rejected by application. If application does not handle invalid
certificate like expired certificate then an attacker can craft a certificate and use it during
authentication.
2.10 Access to highly sensitive data should be PIN or password protected
Check whether application asks for a PIN or password while accessing highly sensitive data.
If highly sensitive data is not protected by a PIN or password, attacker might get access to the
application or user data.
2.11 Consent of user for any cost implications - behavior of application
Check for any warning or acceptance windows during any cost based transaction.
User should be informed before deducting any money. If user consent is not implemented, then in
case of application compromise, user will lose money.
2.12 Provision to update/renew password and unique identification token
Application should have functionality to expire password /token. It should also provide feature to
update/renew password or identification token after the expiry period.
2.13 Check for application user permission
Mobile application provides different permissions using the configuration files, like in case of
Android platform configuration file “AndroidManifest.xml” file includes permissions details. Drop
any unwanted permission that is not used or required by application.
2.14 Phishing Attack
Confirm that how application safeguards itself against phishing attacks. Check for any flaw in the
technique used.
3. Data & Information Management
3.1 Store sensitive data on server side
It is always good to store sensitive data on a server such as authentication credentials, tokens and
application license details. If authentication credentials are available within application binary then
attacker can reverse engineer the application to get the sensitive data.
3.2 Encrypt or Hash the sensitive data or file stored on device.
Any sensitive information like password, unique token, session information, account number or
any file ,log file, backup file stored on device should be encrypted or hashed using standard API
provided by a platform or any trusted party and stored on a restricted storage area.
Encrypting the file or information makes the attacker’s life difficult in getting the sensitive
information. Also in case of device loss, the sensitive information encrypted is not revealed to the
other person.
3.3 Avoid use of removable media to store information
Confidential data should not be stored on removable media like SD card. Also avoid storing the
application data in standard folders provided by mobile phone, as these folders are shared among
other applications.
4 21 Jan 2013 | Vikrant Kansal

6. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
3.4 Weak Permissions –Application Data in Shared Memory
In case application needs to share data with other applications using shared memory then check
the permissions of application data in shared memory. It should be read-only. Always try to get
and disclose minimum information, which is desired for application/s to work properly. Any failure
in handling, leads to corruption or leakage of data.
3.5 Weak Error Message handling
Error handling should be done properly and should not include any sensitive information.
Some error handling code reveals the sensitive information that can be used by the attacker.
3.6 No backup, caching and logging of sensitive data
Check no sensitive data is stored in backup or log files. Also, ensure that the cache is clear.
Failure leads to data leakage attack.
3.7 Remote data wipe
Check whether remote data wipe feature is provided by application or not as it is important in case
of device loss or theft. If remote data wipe is unavailable then in case of device loss or theft,
someone can easily access the application or corporate data.
3.8 Weak File Permissions
Check application’s file permissions are in place. Improper file permissions may allow an attacker
to modify/corrupt/delete the file.
3.9 Deletion of sensitive data from database on application exit
Check that the sensitive data is flushed from database when a user exits from application. Failure
leads to data leakage attack.
3.10 Data deletion practices
Delete data/information when not required. Do not keep historical data of location information for
long. Keep the data as per data retention policy in place. Refer NIST-800-88 for more on this
issue.
3.11 Certificate and Key Management
Check that the Certificate and Key are not disclosed to any other program. Disclosure of key and
certificate leads to unauthorized access
3.12 Deletion of Keystroke and Screen Snapshot cache
Delete all Keystroke and Screen Snapshot cache files. Failure leads to data leakage attack.
3.13 Sharing of user data with other applications
Many applications share the user personal information with other applications or websites like
social networking, advertising, etc. In such cases, user consent is important otherwise it leads to
privacy policy violation.
Always check that user gives his consent whenever personal information is stored or shared.
5 21 Jan 2013 | Vikrant Kansal

7. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
3.14 Maintain data and transaction Logs on server side for Audit purpose
Data and transactions logging should be done on server so that in case of any incident, auditor can
refer the log files especially in case of financial transactions and user consent. Logging on device
is under user control and can be tampered with.
3.15 Limited access based on contextual information
Access to sensitive information can be restricted based on the geographical location and distance.
Example: - Enterprise data is not accessible using mobile application if device is outside office
premises.
4. Input Validation
4.1 Input Fuzzing
Check application and its components for handling fuzz data. If application crashes then it can be
exploited.
4.2 Buffer Weakness
Check the buffer length used in application. Invalid buffer size can lead to buffer overflow or
underflow attack.
4.3 Input Injection Flaws
Attacker can exploit the application and run executable code or script. Therefore, validate input
values provided by users.
4.4 Mobile Client Format String Input Flaws
Failure to handle format string issues can lead to application corruption.
4.5 Runtime interpretation
Validate the 3rd party inputs at runtime like payment gateways. Runtime interpreter’s validation
failure leads to arbitrary code execution.
4.6 DOS vulnerability-Employment of rate limit and throttling
Verify the throttle values, the limit on user inputs and user request handled by the application. No
throttle and limit check can lead to Denial of service attack
4.7 Validation of data received from non-trusted 3rd party
Validate data received from any untrusted source before processing. No validation can lead to
arbitrary code execution attack.
5. Information Leakage in Transit
5.1 Encryption of sensitive data
Information transferred over wireless or air (edge, 3G/4G) can be intercepted by the attacker. So
use end-to-end encryption of sensitive data transfer over network. Clear data transfer lead to
credentials compromise, sensitive data leakage etc.
6 21 Jan 2013 | Vikrant Kansal

8. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
5.2 SSL weakness
Check for known SSL weakness or vulnerability in implemented SSL version. Known vulnerabilities
can be exploited by the attacker to get access to sensitive data.
5.3 Handling of request redirection from HTTPS to HTTP
Many applications switched from HTTPS to HTTP to reduce encryption overhead when no sensitive
data is transferred. So as security analyst we need to check for any flaw in redirection from HTTPS
to HTTP. Failure leads to data leakage attack.
5.4 Sensitive data transfer within file metadata
Many applications share information in metadata for SEO purposes. Make sure that no sensitive
information should be transferred as Metadata.
5.5 Trusted CA and SSL chain validation issue
It is recommended to use the SSL certificates issued by trusted CA instead of self-signed
certificate. Also check application does not ignore SSL chain validation during end to end
communication.
5.6 SSL establishment with the end points having the trusted certificates in key chain
Secure connection between application and server should only be established after verifying the
identity of the remote server. To ensure this check that SSL is only established with end-points
having the trusted certificates in the key chain. Failure leads to man-in-middle (SSL proxy) attack
5.7 SMS, MMS or notifications having sensitive data or information issue
Check no SMS, MMS is used by application for notification which includes sensitive data. Failure
leads to data leakage attack.
5.8 Web Services/SOAP/REST-Security issues
Ensure that information is available only after authentication and user can access the information
that is allowed as per privilege policies. Check for best security practices. Failure leads to data
leakage attack.
5.9 Data transfer using mobile Wallet, NFC communication, In-App Billing
Information used during NFC communication is highly confidential so make sure for any possible
flaws in it. Information used by Wallet, in-app billing and NFC should not be in plain text. Also
check for any known issue in technology.
6. Session Management Issues
6.1 Weak Session Identifier
Session identifier should be unpredictable and should be unique per session. Weak Identifiers like
IMEI number or UDID can be predicted by the attacker and help in conducting session hijacking
attack.
6.2 Session Fixation
Application should invalidate all old session identifier, cookies etc.
7 21 Jan 2013 | Vikrant Kansal

9. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
6.3 Session Timeout Feature
Application should have a session timeout feature. In case of sensitive transactions, session time
out value should be small.
6.4 Session Timeout Handling
All the session data and session cache should be deleted after logout. Failure leads to data leakage
attack.
7. Secure Coding & Development Practices
7.1 Test Code within release version of application
Look for any source code which was added during testing phase.
7.2 Backdoor entry code
Look for any source code which was added by developer for backdoor entries. This code may lead
to unauthorized access to application.
7.3 Encoding and escaping of output data
Check for escaping and encoding before representing/processing and transferring the output data.
Data escaping failure leads to execution of code. No encoding leads to data leakage.
7.4 Usage of Weak API and Functions
Identify use of weak API or functions as per security guidelines. Weak API or functions leads to
application compromise.
7.5 Disabling privileges granted by default API
Check the source code whether developer programmatically disabled the weak privileges of API
which were granted by default or not. Default privileges of API are always known and failure to
disable some weak privileges leads to application access attack.
7.6 Using OS communication mechanism instead of opening Socket
Check the implementation of communication channel. Always prefer to use the OS provided
communication mechanism instead of opening a socket.
Attacker can get the open port information via performing port scanning on the device and then
conduct DOS attack
7.7 Super user privilege within code
Check the source code for granting super user privilege. Avoid granting super user privilege, but if
required then no other program can access this piece of code.
7.8 Obfuscate application code
Obfuscate application code so that it is difficult to reverse engineer. Development platforms
provide some basic level of obscuration. For e.g. On Android platform, ProGraud can be used for
basic level obfuscation.
8 21 Jan 2013 | Vikrant Kansal

10. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
8. Known Vulnerability & Patch Issues
8.1 Check for Identified Vulnerability Issues in Native language
Check for any identified vulnerability in native language. Known vulnerability can be easily
exploited by attacker
8.2 Check for third party library/API known Security Issues
Check for any identified vulnerability of third-party API or library used by application.
8.3 Check for Identified SDK/API version specific Vulnerabilities
Check for any identified vulnerability of SDK/API version that application supporting. Known
vulnerability can be easily exploited by an attacker.
9. System Privilege Issues
9.1 System Privileged Command Execution
Check the source code if it executes any system level privileged command or not. If code
implementation has some flaw then it can be exploited by the attacker to execute the command.
9.2 System Privileged Device Settings
Check the source code if it can change the system settings of privilege code. If code
implementation has some flaw then it can be exploited by the attacker to change the device
settings.
10. Weak Cryptography
10.1 Weak Cryptographic Algorithm
Check no weak cryptographic algorithm, hash function, encryption key length is used or supported
by application.
11. Cross Site Scripting
11.1 Input validation for any scripting code
Check all possible XSS vector. Failure leads to XSS attack. Please refer OWASP guidelines to know
more about this attack.
12. Cross Site Request Forgery
Look for possible CSRF vector. Failure leads to CSRF attack. Please refer OWASP guidelines to
know more about this attack.
13. 3rd Party Application Integration Issues
13.1 Sensitive data leakage
Check for any data leakage during integration of 3rd party application.
9 21 Jan 2013 | Vikrant Kansal

11. January 21,
2013 GENERIC THREATS TO MOBILE APPLICATIONS
13.2 Insecure data connection
Check for insecure data connection between application and 3rd party application. Insecure
transfer leads to data leakage.
13.3 Session Validation
Check for any session hijacking issues during data transfer between application and third party.
Failure leads to Session hijacking.
About The Author
Vikrant Kansal is an Information Security Analyst based out of India. Vikrant has over 8 years of
industry experience in the Security domain. He is a graduate in Computer Science & Engineering
and having experience in vulnerability analysis and assessment, mobile and web application
analysis, penetration testing and secure code review.
References
[MacAfee] http://www.mcafee.com/in/resources/white-papers/foundstone/wp-pen-testing-iphone-ipad-
apps.pdf
[Google] http://developer.android.com/training/articles/security-tips.html
[OWASP] https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-
_Top_Ten_Mobile_Controls
[MacAfee] http://www.mcafee.com/in/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf
[Apple] http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
10 21 Jan 2013 | Vikrant Kansal