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

- Advertisement -

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.

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, or enable fraudulent payments.

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.

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

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.

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

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

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