Categories: Android

Android Application Penetration Testing – Part 12

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 12, we summarized the Android Security Checklist.

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:

1 Reliance Upon Built-In Code Encryption Processes-Bypassing built-in code encryption algorithms is trivial at best. Always assume that an adversary will be able to bypass any built-in code encryption offered by the underlying mobile OS.

2 Poor Key Management Processes- The best algorithms don’t matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it.

3 Creation and Use of Custom Encryption Protocols- 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 hard-coded keys in the binary. In cases of very high-security requirements around encryption, you should strongly consider the use of white box cryptography

4 Use of Insecure and/or Deprecated Algorithms- 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

Also Read Complete penetration testing guide for Android Pentesting and Checklist

M6 – Insecure Authorization – Android Security Checklist

To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in ‘offline’ mode.

Testers should try to execute any privileged functionality using a low-privilege session token within the corresponding POST/GET requests for the sensitive functionality to the back-end server.Poor or missing authorization schemes allow an adversary to execute functionality they should not be entitled to using an authenticated but lower- privilege user of the mobile app.

Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server. This may be a requirement due to mobile requirements of offline usability.

The technical impact can be wide-ranging in nature and dependent upon the nature of the over-privileged functionality that is executed. For example, over-privileged execution of remote or local administration functionality may result in the destruction of systems or access to sensitive information.

Test Name	Description
Remember Credentials Functionality (Persistent authentication)	Identify user’s password or sessions on the device
Client Side Based Authentication Flaws	Perform binary attacks against the mobile app in order to bypass offline authentication
Client Side Authorization Breaches	Perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege
Bypassing business logic flaws	Identify Missing Function Level Access Control, Negative value testing
User Propriety Data in Logcat Technical Valuable Data in Logcat	Check for adb logcat
Code Puzzling and Abusing Application State	Bypass efficient authentication enforcement mechanisms and impersonate legitimate users. Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.(Privilege escalations) Manipulate server-side values in indirect methods that cannot be predicted or detected.

Bypassing business logic flaws	Identify Missing Function Level Access Control, Negative value testing
User Propriety Data in Logcat Technical Valuable Data in Logcat	Check for adb logcat
Code Puzzling and Abusing Application State	Bypass efficient authentication enforcement mechanisms and impersonate legitimate users. Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.(Privilege escalations) Manipulate server-side values in indirect methods that cannot be predicted or detected.
Public Intents	Check defined Explicit and Implicit intents.
Permissions & Digital Signature Clipboard Separation	Check if it is possible for Removing signatures in a digital signature field. Check if unwanted permissions define in android manifest can be exploitable
Race Conditions, Deadlocks, and Concurrency Threats	Race Conditions: Check if there are Running more than one thread inside the same application does not by itself. Deadlocks: Check if concurrent modules are stuck waiting for each other to do something. Concurrency Threats: Check how threads in the system collaborate to complete the jobs they are given.

Device Denial of Service attacks

DoS tools like LOIC and Packet Generator with user-friendly interfaces from verified sources like Google’s Play store.

M7 – Client Code Quality – Android Checklist

Client-side injection results in the execution of malicious code on the mobile device via the mobile app.

The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection. Checking the code is a fast and accurate way to see if the application is handling data correctly.

Also Read Most Important Android Security Penetration Testing Tools for Hackers & Security Professionals

Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability.

Since data can come from many sources in mobile applications, it is important to list them delineated by what they are trying to achieve. In general, injection attacks on mobile devices target the following:

Data on the Device:

SQL Injection: SQLite (many phones default data storing mechanism) can be subject to injection just like in web applications. The threat of being able to see data using this type of injection is risky when your application houses several different users, paid-for/unlockable content, etc.

Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains to reading files that might be yours to view inside the application directory.

The Mobile Users Session: JavaScript Injection (XSS, Etc): The mobile browser is subject to JavaScript injection as well. Usually, the mobile browser has access to the mobile applications cookie, which can lead to session theft.
The Application Interfaces or Functions:

Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jailbreaking devices.
Binary Code Itself:

Mobile malware or other malicious apps may perform a binary attack against the presentation layer (HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app’s executable. These code injections are executed either by the mobile app’s framework or the binary itself at runtime.

Test Name	Description
Insufficient WebView hardening (XSS)	Identify misconfiguration on “android.webkit.WebSettings” (Javascript/File access/Plugins), XSS through UIWebview
Content Providers: SQL Injection and Local File Inclusion	Identify SQLi and LFI on Content provider component
Injection (SQLite Injection, XML Injection)	Identify SQLi and XMLi on application
Local File Inclusion through NSFileManager or Webviews	Check LFI on application (../ , ../../blah\0) Webviews FileAccess attack through setAllowFileAccess

Code Signing	Check if application is digitally sign and its .apk files optimize
Exposing External Java Interfaces in Web Views DOM JavaScript Execution Risks at WebViews	Check for webviews – two most important callbacks are WebChromeClient for browser events and WebViewClient for web events.
Loading Dynamic DEX onto Dalvik	Check if android application Instead of loading Dalvik executable (“dex”) files from the default location, it can load them from alternative locations such as internal storage or over the network.
NDK Exposed Code Secrets	Check for ndk exposed code On path ANDROID_HOME and ANDROID_NDK_HOME at local installation of SDK and NDK.
Tapjacking	Check if activities in one android application can gather input while an overlay is active of other application
Abusing Dynamic Code Execution Decisions	In Android, the DexClassLoader allows an application to load classes from jar and apk files. Check if we can create apk files to be loaded into another application during runtime.

M8 – Code Tampering

Tampering detection is a preventive measure used in mobile applications to help to ensure that a third party hasn’t recompiled and published your application under their account or store without your consent.

To detect and mitigate the tampering of Android applications.

Check if the application has been renamed.
Check if the application has been published without your consent.

Test Name

Description

Abusing Android Components through IPC intents (“exported” and “intent-filter”)

Identify android exported components

Abusing URL schemes

For iOS: Identify URL schemes through info.plist and Clutch+Strings to obtain URL scheme structures

For Android: Identify URL schemes through source code or apk file

M9 – Reverse Engineering

In order to reverse engineer an APK file from its source, you need to do the following:

Exploding APK
Extracting Java Classes
Decompiling Java Sources
Inspecting APK Content

Test Name	Description
Reverse Engineering the Application Code	Disassembling and Decompiling the application, Obfuscation checking
Unauthorized Code Modification	Binary attack through run-time manipulation and code modification
Debug the application behavior through runtime analysis	Identify “android:debuggable” attribute Using GDB/LLDB attach to application

M10 – Extraneous Functionality – Android Checklist

This category deals with session handling and the various ways it can be done insecurely. 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:

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

Failure to Invalidate Sessions on the Backend

Many developers invalidate sessions on the mobile app and not on the server side, leaving a major window of opportunity for attackers who are using HTTP manipulation tools. Ensure that all session invalidation events are executed on the server side and not just on the mobile app.

Lack of Adequate Timeout Protection

Any mobile app you create must have adequate timeout protection on the backend components. This helps prevent the malicious potential for an unauthorized user to gain access to an existing session and assume the role of that user.

Good timeout periods vary widely according to the sensitivity of the app, one’s own risk profile, etc., but some good guidelines are:

15 minutes for high-security applications
30 minutes for medium security applications
1 hour for low-security applications

There is an increasing trend towards allowing long timeout values on mobile app sessions due to the nature of user interaction with mobile apps. Often, users are doing many things at once when using their mobile apps.

Interactions tend to be sporadic, unpredictable, and drawn out over a longer timeframe than with traditional web apps. In some ways, it makes sense that longer timeout sessions are required because the interval between interactions might be longer.

However, this increased session timeout window will increase the risk of session stealing if session handling is not done properly. It is important to raise this risk with the powers-that-be to ensure that session handling is handled properly.

Failure to Properly Rotate Cookies

Another major problem with session management implementations is the failure to properly reset cookies during authentication state changes. Authentication state changes include events like:

Switching from an anonymous user to a logged in user
Switching from any logged in user to another logged in user
Switching from a regular user to a privileged user.
Timeouts.
For each of these event types, it is critical that sessions are destroyed on the server side and that the cookies presented as part of the previous sessions are no longer accepted. Ideally, your application would even detect any use of said cookies and would report that to the appropriate security team.

Insecure Token Creation

In addition to properly invalidating tokens (on the server side) during key application events, it’s also crucial that the tokens themselves are generated properly. Just as with encryption algorithms, developers should use well-established and industry-standard methods of created tokens. They should be sufficiently long, complex, and pseudo-random so as to be resistant to guessing/anticipation attacks.

Test Name	Description
Session invalidation on Backend	Ensure that all session invalidation events are executed on the server side and not just on the mobile app
Session Timeout Protection	Mobile app must have adequate timeout protection on the backend components
Cookie Rotation	Ensure that reset cookies are properly implemented during authentication state changes (Anonymous<->User, User A<->User B, Timeout)
Token Creation	They should be a standard algorithm, sufficiently long, complex, and pseudo-random so as to be resistant to guessing/anticipation attacks.