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.
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.
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.
|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.|
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
|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)|
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.
|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
|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|
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:
|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.