Mobile Security Testing. Make the First Step!

Have you ever wondered how to secure a mobile project? Maybe you have even started conducting research, only to become even more confused about the topic? If you answered “yes” at least once, then let me give you a helping hand! In this article, you will learn how to test the basic aspects of security in the modern mobile app ecosystem and the benefits of taking such a direction.

First things first. Why mobile security matters.

Why should you even bother to raise awareness about the security in your workspace? Security, similarly to Quality, is a distributed responsibility of the entire team. While working on an app, you’re not only bound by a contract with a client but also with end-users by an informal social contract.

Ensuring mobile security – what does it mean to me?

• One of its arising responsibilities is active data leakage prevention.
  Very often, a team working on an app is the last bastion of enforcing the seven key principles of GDPR (General Data Protection Regulation), published in 2016 and implemented 2 years later. Check out: What does GDPR mean for Mobile App Owners – 12 Use Cases.
• When it comes to mobile security responsibilities towards a client, securing an app code from leaking is definitely one of them.
  This aspect is extremely important while working on complex algorithms implemented on the client-side. Such solutions should not be public or easily accessible by anyone other than the project owners. The company needs to keep things such as API keys, Web API details, algorithms, custom and innovative solutions private.
• Avoiding situations when a mobile app is attacked and gets removed from application stores is an obligation towards both the client and end-users.
  Apps can be exposed to undesirable effects of third parties, which can result in turning your phone into a well prospering bitcoin miner. When such a situation happens, the app is taken off the store as soon as the faulty behavior is detected and remotely uninstalled at worst.

Underestimating the aspects I mentioned before may lead to serious consequences for all 3 sides. Find out more about this topic:

• What is Mobile (and Web) Application Security and How to Secure your App?
• 5 Key Legal Issues in Mobile App Development

Once upon a time… What may happen if you neglect mobile security

Imagine the scenario when a company encounters a huge security gap in an app but they notice it too late. The app is already released and users have suffered from those issues. After a tiring and lengthy legal process, as well as enormous financial penalties, the company wants to start over.

Sadly, their reputation is in shreds already and even rebranding may not help. The company is losing the trust of their users and receiving lots of negative opinions. They need to face the inevitable – all that’s left to do is to shut down. If you have signed a contract with that company – you have just lost the client, and your reputation as a specialist can be harmed too.

Have you felt that shiver in your neck? I know it might sound scary, but if you are reading this article, it means you are in a good place to protect yourself from being a part of this pessimistic scenario.

Let’s see what the most crucial areas of mobile security are and which of them should be addressed first.

5 key areas of mobile app security you should be aware of

1. Network traffic

When building and testing a mobile app, it is important to ensure that the communication with servers is properly secured. This is where the HTTPS protocol comes to the rescue. The enhanced version of its older HTTP brother encrypts the exchanged data with SSL (secure socket layer)/TLS (transport layer security).

To perform basic tests in this area, it is handy to gain some experience with Proxy tools like Burp Suite, Charles Proxy and Proxyman, which can be used to intercept requests and responses from a Web API. If you have never worked with any of them, I recommend you pick Burp Suite and give it a try. It can quickly become your favorite toy during mobile testing as it provides a broader view on the integration and communication with a Web API.

Additionally, you can use the tool to verify if the app<->server communication relies on the HTTPS protocol. Simply check the network traffic going through the device and filter URLs under the domain your API is deployed to. For example, in Burp Suite, you can track all the URLs that are not starting with “https” and are within the API domain. If any URLs are logged while this filter is set, you should carefully verify them, as it may be the first vulnerability in the app you have encountered.

HTTPS is not the only protocol you should be aware of. As mentioned before, SSL/TLS  is used for data exchange encryption. Similar to HTTP/S, there were multiple versions of those protocols released and implemented in the last quarter of the Internet’s existence (so far!). The oldest TLS versions (1.0 & 1.1) have been considered as not secure enough, deprecated and, as of 31st of March 2020, no longer supported.

So what is it all about? Why can’t we just adapt our API to use 1.2 onwards?

Well, it turns out that it’s not as simple as you may think. For example, Android 4.4 and all the versions below support 1.0 and 1.1 versions of TLS by default, so developers should remember to enable TLS 1.2 support manually. To make sure your team did this, type the following command in your terminal with the Web API URL and its port.

As an output, you will get the TLS version supported by the Web API.

With the recently published (2 years ago) TLS 1.3 version, why not migrate to it upfront? Well, native support for TLS 1.3 comes only with iOS 12.2 and Android 10 onwards. With over 80% of iOS 13 adoption, you don’t need to worry about the Apple world. With less than 10% Android 10 adoption, however, you can either enable the support with custom implementations for earlier Android APIs or wait 3-5 years for the TLS 1.3 support to reach the current iOS level. So for now, you can rest easy, unless the rapidly developing quantum computing becomes a thing and redefines our look at the security of the IT systems.

2. Application’s persistent data

Another crucial area of mobile security testing is the storing of persistent data in a mobile app – which seems to be an easy task. Just pick one of the available frameworks, grab the data you received from a user or BE (backend), and that’s it. Implementation-wise – all is done, but have you ever wondered if the data you just stored is properly secured and if it contains any sensitive information about the user? First of all, you should check if there is any business justification for storing such data. If, for some reason, it’s necessary for your company to run, make sure all the data was reviewed by the person appointed as the Data Protection Officer.

The next step is to identify the frameworks used for data storage. Android applications usually rely on SharedPreferences and SQLite databases. So, if you have a test device with the debug variant of the app installed and a spare USB cable at hand, you can do some research on your own. Connect to the device with ADB command, locate the data/data/your-app-package/ directory. The databases and shared_prefs directories are exactly what you are looking for.

If the app uses firebase services, you will most likely see multiple .xml files under the shared_prefs directory and .db files under the databases one. Try to locate the ones created by your developers and pull them to your workstation. You may start wondering if it’s that easy to access data of any app installed on your phone, but there is not much to worry about. Each app has its own private disc space allocated, which can be accessed only by itself. The only exceptions are debug builds and rooted devices (less than 1% of the market).

But let’s go back to the file we’ve pulled from the device a moment ago. There are two options – persistence data can be encrypted or not. If it’s encrypted – you can celebrate – as another layer of security was implemented by your developers. To verify the shared preferences, you can simply open their files in any text editor. If you see the key-value pairs in a plain text, then they are definitely not encrypted.

When you want to verify an SQL database, search for an SQL viewer (there are plenty available online) and import data from the .db file. If it opens, that means it’s not encrypted but at least you can examine the scheme, browse the data manually or perform a few SQL queries to verify that everything is correct.

3. Android Application package – Android build artifact

Contrary to the iOS apps distribution system, which is way more closed, though secure, Android needs some developer effort to make it less accessible to the public.

There are a few tools that can help you keep the code harder to reverse engineer:

• ProGuard & R8 (R8 is used by default starting from Android Studio 3.4) – tools for code obfuscation – changing names to literals. Thanks to these, the code is less readable for humans and also “lighter” due to the fact that the many long names tiresomely imagined by developers are replaced with a combination of single letters. How to check if you’re using one of these in your app? Check the build.gradle-s and see if the minifyEnabled option is set to true.
• DexGuard – the enterprise version of ProGuard used for code encryption. Not a mandatory one, but definitely something worth checking as an additional protection layer.

You should also keep in mind that API keys shouldn’t be easy to find somewhere in the .apk

This is, for me, the easiest way to check:

• Search for your publicly available production .apk version on one of the apk mirrors
• Upload it to one of the online apk decompilers
• Download the decompile code to your computer
• Use the terminal to look up some keywords that you want to make sure are not there. So, if you’re trying to make sure that API keys are not there, try searching for “api_key”

4. Third-party, open-source libraries

The main question here is if the libraries used in the project are trustworthy? What if they collect some info about the user? There are a few things you can do to minimize this risk:

• When adding a new library, make sure that it:
  • was already used by many apps, such as by checking the usages on the https://mvnrepository.com/artifact/com.squareup.retrofit2/retrofit
  • has a good reputation among the community by checking the code repository and related social media
  • has no major issues found by the community and scanning tools, such as
    https://ossindex.sonatype.org/component/pkg:maven/com.squareup.retrofit2/[email protected]

If you found them safe – make sure you also check the source from which you want to download them.

• To ensure any already introduced libraries are still safe, run an automated dependency check regularly as a part of your pipelines:
  • Go to Dependency check
  • Add the OWASP dependency check plugin to gradle:
    
    apply plugin: 'org.owasp.dependencycheck'

    1	apply plugin: 'org.owasp.dependencycheck'

  • Use the Dependency check plugin by OWASP to check libraries for known, published vulnerabilities.
    
    ./gradlew dependencyCheckAnalyze --info

    1	./gradlew dependencyCheckAnalyze --info

    
    

• Be extra focused while checking the permissions app is asking for.
  If there is a case that the app wants permissions for something not related to any of its features, it can be a sign that a malicious library is used in the project. For example: imagine that a camera app, among the storage and camera permissions, wants to access your phone calls. This is something you should be concerned about!

5. Logging sensitive data

• Check if your production app is not logging any requests or transactions (you can use tools for network traffic tracking from the 1st point)
• Check your analytics/crashlytics tools – when the issue is logged in there, be sure that sensitive data is not logged along with the information about the users and their actions/crashes

Mobile application security testing – wrap up

Testing mobile security is a challenge worth accepting. Now that you have read this article, you are one step closer to taking care of it in your project. I hope it is easier for you, since you should already have an idea of where to start.

Do not be scared to begin this journey and test if your mobile app is well secured. The whole new world of mobile testing is waiting for you to discover its complexities. Read also: How to Secure your mCommerce Application.

Related posts