Categories: AndroidChecklist

Android Application Penetration Testing – Part 11 – Android Checklist

Mobile platforms provide many different services, from authentication, to secure data storage, to secure network communications. Failing to use some part of the platform correctly, therefore, could expose data, allow connections to untrusted hosts. With Android Application part 11, we summarized the Android Checklist.

M1 – Improper Platform Usage

The defining characteristic of risks in this category is that the platform (iOS, Android, Windows Phone, etc.) provides a feature or a capability that is documented and well understood. The app fails to use that capability or uses it incorrectly.

Also Read Our Complete Mobile penetration Testing Guides

There are several ways that mobile apps can experience this risk.

Violation of published guidelines – Android Checklist

All platforms have development guidelines for security (c.f., ((Android)), ((iOS)), ((Windows Phone))). If an app contradicts the best practices recommended by the manufacturer, it will be exposed to this risk.

Violation of convention or common practice

Not all best practices are codified in manufacturer guidance. In some instances, there are best practices that are common in mobile apps.

Unintentional Misuse – Android Checklist

Some apps intend to do the right thing, but actually get some part of the implementation wrong. This could be a simple bug, like setting the wrong flag on an API call, or it could be a misunderstanding of how the protections work.

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of Touch ID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

Privacy and permissions in mobile apps are also the domain of the platform. Thus, a failure to use the platform’s features could expose the end user to a privacy risk.

Test Name	Description
Excessive port opened at Firewall	Identify opened port at Server-side URL/IP Address
Default credentials on Application Server	Identify default credentials on Backend server (e.g. Tomcat Application server using tomcat/tomcat, admin/tomcat)
Exposure of Webservices through WSDL document	Identify webservices help pages (.asmx) which show methods and structure*
Security Misconfiguration on Webserver	Identify webserver configuration (e.g. Error handling, HTTP response banner)
Input validation on API	Check input validation on API/Web services
Information Exposure through API response message	Identify sensitive information on API response message/header
Touch ID and the Keychain	Check if bypassing LocalAuthentication either via modification of the local check at runtime Check if we can get password or sensitive info from keychain
Insecure File Permissions	Check if the application is Using the ‘world readable’ and ‘world writeable’ file permissions can cause data leaks and expose apps to attackers who are able to overwrite the app’s data.
Intent Sniffing	Check if A malicious Android application can register to receive broadcast or implicit intents from any other app.

M2 – Insecure Data Storage

Insecure data storage and unintended data leakage

Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores.

Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data. Unintended data leakage occurs when a developer inadvertently places sensitive information or data in a location on the mobile device that is easily accessible by other apps on the device.

First, a developer’s code processes sensitive information supplied by the user or the backend. During that processing, a side-effect (that is unknown to the developer) results in that information being placed into an insecure location on the mobile device that other apps on the device may have open access to.

Data being stored insecurely include – Log files, plist files, sd card, XML data stores, databases, binary data stores, cloud synced, OS caches data, images, key-presses, logging, and buffers

Test Name	Description
Hard-coded credentials on source code	Identify sensitive information on sour code
Unrestricted Backup file	Check “android:allowBackup” attribute which should be set to “false”
Unencrypted Database files	Check encryption on database files
Insecure Shared Storage	Identify Sensitive Data on Shared Storage, SD card storage encryption, Shared preferences MODE_WORLD_READABLE
Insecure Application Data Storage	Identify Sensitive Data in application files (application log, Cache file, Cookie)

M3 – Insecure Communication

Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception.

The use of transport security does not mean the app has implemented it correctly. To detect basic flaws, observe the phone’s network traffic. More subtle flaws require inspecting the design of the application and the application’s configuration.

The following threat agents exist

An adversary that shares your local network (compromised or monitored wifi);
Carrier or network devices (routers, cell towers, proxys, etc);

To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:

Are all connections, not just ones to servers you own, properly encrypted?
Are the SSL certificates to date?
Are the SSL certificates self-signed?
Does the SSL use high enough cipher strengths?
Will your application accept user accepted certificates as authorities?

This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

Test Name	Description
Insecure Transport Layer Protocols	Check if traffic is on HTTPS or HTTP
TLS Authenticity Flaws	Check Poodle, Beast, CRIME, BREACH, Heartbleed
TLS Weak Encryption	Check TLS/SSL Cipher Hardening
Bypassing TLS Certificate Pinning	Check TLS/SSL pining

M4 – Insecure Authentication – Android Checklist

Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device’s input form factor.

The form factor highly encourages short passwords that are often purely based on 4-digit PINs. Authentication requirements for mobile apps can be quite different to traditional web authentication schemes due to availability requirements. In mobile apps, users are not expected to be online at all times during their session. Mobile internet connections are much less reliable or predictable than traditional web connections.

Hence, mobile apps may have uptime requirements that require offline authentication. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication. To detect poor authentication schemes, testers can perform binary attacks against the mobile app while it is in ‘offline’ mode.

Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication. As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET requests for the mobile app functionality.

Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through runtime manipulation or modification of the binary.

Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.

If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials.

There are additional risks that the data will be decrypted via binary attacks. Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.

Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.

Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.

Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. Mobile app code must protect user sessions just as carefully as its authentication mechanism.

Here are some examples of how it is often done improperly – Android Checklist

Failure to Invalidate Sessions on the Backend
Lack of Adequate Timeout Protection
Failure to Properly Rotate Cookies
Insecure Token Creation

This category captures notions of authenticating the end user or bad session management. This can include:

Failing to identify the user at all when that should be required
Failure to maintain the user’s identity when it is required
Weaknesses in session management

Test Name	Description
Information Disclosure through Logcat/Apple System Log (ASL)	Identify sensitive information through application log
Application Backgrounding (Screenshot)	Identify application snapshot/screenshot backgrounding
URL Caching (HTTP Request and Response) on cache.db	Identify HTTP caching which is stored in Cache.db
Keyboard Press Caching	Identify keyboard cache file located in: /var/mobile/Library/Keyboard
Copy/Paste Buffer Caching	Identify disabling Copy/Paste function for sensitive part of the application on EditText/UITextField
Exposing Device Specific Identifiers in Attacker Visible Elements	Observe the device’s network traffic through a proxy that Device’s information (UDID) is sent during the transmission or not.
Using Insecure Authentication Vectors	Check for any Hidden Service Requests, Password Policy
Local Authentication Bypass Threats	Check access policy or a weak authentication that allows a valid identity to be forged. Check for default Username and passwords.
Client Side Based Authentication Flaws	Check if HTTP is embed several different types of authentication protocols. e.g Basic- Base-64 encode, Digest, NTLM, Microsoft Passport – A single-sign-in (SSI) service, Negotiate and Form-based

M5 – Insufficient Cryptography

Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two fundamental ways that broken cryptography is manifested within mobile apps. First, the mobile app may use a process behind the encryption/decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data.

Second, the mobile app may implement or leverage an encryption/decryption algorithm that is weak in nature and can be directly decrypted by the adversary. The following subsections explore both of these scenarios in more depth:

Realize Upon Built-In Code Encryption Processes – Android Checklist

Using freely available tools like ClutchMod or GBD, an adversary will download the encrypted app onto their jailbroken device and take a snapshot of the decrypted app once the iOS loader loads it into memory and decrypts it (just before the loader kicks off execution).

Once the adversary takes the snapshot and stores it on disk, the adversary can use tools like IDA Pro or Hopper to easily perform static/dynamic analysis of the app and conduct further binary attacks.

Poor Key Management Processes – Android Checklist

Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:

Including the keys in the same attacker-readable directory as the encrypted content;
Making the keys otherwise available to the attacker;
Avoid the use of hardcoded keys within your binary;

Keys may be intercepted via binary attacks. See M10 for more information on preventing binary attacks.

Creation and Use of Custom Encryption Protocols – Android Checklist

Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform.

Binary attacks may result in adversary identifying the common libraries you have used along with any hardcoded keys in the binary. In cases of very high-security requirements around encryption, you should strongly consider the use of white-box cryptography.

Use of Insecure and/or Deprecated Algorithms – Android Checklist

Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:

RC2,MD4,MD5,SHA1

Test Name	Description
Cryptographic Based Storage Strength	Identify insecure/deprecated cryptographic algorithms (RC4, MD5, SHA1) on source code
Poor key management process	Identify hardcoded key in application or Keys may be intercepted via Binary attacks
Use of custom encryption protocols	Identify implementing their own protocol

Here is Mobile application Penetration Checklist PART1, stay tuned for next version of Android Checklist.

POOJA GAONKAR