September 29, 2021
In August, we launched AppSweep, a free, developer-oriented, mobile application security testing tool. With AppSweep, developers can address risks in their Android code and dependencies early in the development process by surfacing mobile security issues. Our philosophy on presenting findings is to ensure they are relevant, actionable, and coupled with clear recommendations on how to fix them.
To learn more about AppSweep, check out this video:
We’ve been monitoring the use of AppSweep and, in the first 45 days AppSweep has been available, we’ve captured more than 100,000 findings across the mobile apps that have been scanned. Interestingly, there is no one industry that stands out above the rest. The findings we’ve seen to date were observed in Android applications across a range of industries, including Finance, Healthcare, Agricultural tech, Telecommunications and Consumer Technology.
Regarding the most common security issues, there were three that stood above the rest. They include:
- Insecure communication due to TLS misconfiguration
- Insecure cryptography
- Lack of protection from Tapjacking
Insecure communication due to TLS configuration
With mobile applications, there is almost always a need to communicate with a server backend, and transmitting data across the internet creates the opportunity for MitM (Man-in-the-Middle) attacks. While most developers understand the importance of implementing SSL/TLS, we still observe common misconfigurations or incorrect handling of certificates that result in a vulnerable TLS configuration.
Malfunctioning X509 Trust Manager
In classes that implement X509TrustManager, the certificate chain needs to be checked correctly. If the certificate chain cannot be trusted the connection must not be established.
TLS Certificate Check Disabled
Hostname verification needs to either use the default implementation or needs to be correctly implemented. For example, if hostname verification is not implemented correctly by not checking the hostname and simply returning true, this allows an attacker to impersonate the server in a MitM attack.
TLS Outdated Version Enabled
Initializing SSLContext with a generic or old TLS version may enable outdated and insecure communication protocols. In such cases, the TLS version used depends on the API level of the device and how the server is configured. The developer should explicitly use a secure version to prevent such problems.
Insecure cryptography
If your mobile app uses encryption, it is important to ensure the cryptography that is used is kept up-to-date and is used correctly. As time evolves, crypto libraries also mature with many becoming deprecated or declared obsolete. This can leave your app vulnerable.
In ideal circumstances, all efforts should be taken to design your application to avoid storing any sensitive data on the mobile device. In cases where this is unavoidable, or where greater sensitivity around the code or data requires encryption, proven and up-to-date cryptographic algorithms and protocols should be used.
Common examples of insecure cryptography include using native crypto classes that are outdated; the Android SDK will often deprecate cryptography classes and therefore the Android SDK documentation should be regularly consulted.
We also see improper defaults such as ECB, or Electronic Codebook encryption mode, which can cause pattern exposure in the encrypted data. Inspired by the Linux penguin ECB example, we’ve illustrated this problem with the Guardsquare logo.
Using ECB mode exposes patterns that allow an attacker to potentially decrypt the encrypted data without a key. ECB splits the message into blocks and encrypts them separately. Because the blocks are encrypted independent of each other, certain patterns in the encrypted data can be revealed that can help to decrypt the data without having the secret encryption key.
A more secure mode is CBC, or cipher block chaining, which uses the data of the previous block to encrypt the next one. This creates better data diffusion, increasing the difficulty in breaking the encryption.
The last example of insecure cryptography is when a range of insecure ciphers are still commonly used. A good example is the use of insecure pseudo-random number generator algorithms, such as CWE-335: Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) and CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG).
Lack of protection from Tapjacking
Not protecting view elements, like buttons, allows a malicious app on the same device to trick the user into clicking on elements without their consent by overlaying the element with their own. Basically, they hide where the user really taps. This is especially important for security-relevant parts of an application, like pin/password entry.
Tapjacking has been a nagging problem that continues to be relevant for many Android apps. For highly sensitive applications, such as payment processing, it is important to ensure all relevant views and components are adequately protected.
The solution for tapjacking protection is quite simple and should be considered in all sensitive views/components: You can simply add `filterTouchesWhenObscured="true"` to the relevant view elements in the respective layout xml files or set the protection programmatically.
More information on how to protect the views of your app can be found in the Android SDK documentation.
AppSweep: Free Scanning to Surface Your Mobile Security Issues
We’ve touched on just a few of the more common findings that AppSweep has discovered in applications over the first 45 days, many of which are strongly related to the categories covered in the OWASP Mobile Top 10. But there are many more types of security findings that can be discovered in your app.
The good news is AppSweep provides clear recommendations on how to effectively and efficiently resolve these issues.
If you have any feedback, we’d like to hear it, you can post questions or share feedback directly through the Guardsquare Community for AppSweep.
