How to carry out mobile app risk assessments

If you work for a large organisation, the chances are that a requirement may occasionally surface for a new mobile app to be deployed on company-issued mobile devices for staff usage. This post is to help guide security analysts and engineers on how they can use MobSF to carry out basic internal security reviews of any mobile applications that their respective organisation may intend to deploy for their end users.

Please note that this blog post is high-level, intended for moderately technical audiences, and is limited in scope to only static analysis of Android apps. I may cover more involved assessment methodologies via dynamic analysis in a future post.

Requirements

• A Linux OS (in this guide I'll be using Kali)
• Some basic CLI experience
• A dedicated Android device which is rooted (optional)

Installing and deploying MobSF

To get started we can leverage the open-source Mobile Security Framework, more commonly known as MobSF, to automate static analysis and generate a report.

1. Install MobSF using:

   git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
./setup.sh

2. Update MobSF using:

   git pull origin master
. venv/bin/activate
pip install --no-cache-dir --use-deprecated=legacy-resolver -r requirements.txt
python manage.py makemigrations
python manage.py makemigrations StaticAnalyzer
python manage.py migrate
deactivate

3. Deploy MobSF using:

   ./run.sh 127.0.0.1:8000
   
   

   

   

4. Obtain an APK file for analysis:

   To interrogate the compiled binaries and functionality for analysis, MobSF requires the raw APK file of the desired app. APK files can be obtained a number of ways, and the process can differ between free and paid-for apps. I plan to create a separate blog post in the future which helps guide through the process I've standardised for myself involving a rooted Android device. For now I might recommend trying third-party services such as APK Pure.

5. Upload an APK file for analysis:

   From here you can upload any .apk binary for static analysis. Note, any uploaded file should be a raw .apk and not the compressed .zip container or .xapk package in which the .apk files usually reside.
   
   If an .xapk package is sourced, you can extract the raw .apk files from this by renaming the filename to a .zip extension. For example, if the filename is com.riggsmobileapp.xapk, rename this to com.riggsmobileapp.zip, open the .zip, then pull out the .apk file(s) you wish to analyse and submit them into MobSF for analysis. Third-party app providers also reserve the ability to supply these files and may do so upon request.

6. Review the generated report:

   Once static analysis is complete, MobSF will produce a report detailing its findings. These can be interactively navigated using the categories listed within the left sidebar, or exported into a PDF file using the PDF Report button.

   

What should your assessment of the MobSF report aim to cover?

This will largely depend on the mobile app and on your organisational risk appetite for introducing new mobile apps into their environment. Below I will expand on some key areas I think are worth reviewing, but please note that these should not be considered exhaustive.

1. Application permissions
   

   The functionality and access of an app are determined by its permissions. These permissions vary, spanning from the ability to retrieve data stored on the mobile device, such as contacts and media files, to operating certain hardware components like the device's camera or microphone.
   
   This information can be found in the following location of the report:

   1. Permissions
      

      The Permissions tab provides detailed information about permissions extracted from the AndroidManifest.xml file. This file in an Android application is responsible for declaring the permissions the app needs, along with many other settings. Within this tab you should see a list of permissions the app has requested and brief descriptions of what those permissions allow the app to do. You should pay particular attention to any permissions which do not align with the app's described purpose and that can potentially compromise user privacy or the device security.

      

2. Network traffic
   

   In static analysis, it's useful to assess specific destinations, or servers, to which an app dispatches data and the sources from where it extracts data. This means it's useful to consider the server's credibility, the integrity of the connections (whether they're all secured or only a fraction of them), and the nature of information returning via these links (for example, whether malware or phishing attacks are originating from a previously considered safe URL).
   
   This information can be found in the following locations of the report:

   1. Reconnaissance > Hardcoded Secrets
      

      Check for any URLs which might be hardcoded as destination servers. Assess if any shown are unexpected (in the context of the application purpose) and consider manual review of their IP reputation and conduct reverse-lookups to identify any anomolies.

      

   2. Malware Analysis > Domain Malware Check
      

      Check for any URL domains within the report which indicate a suspicious status. This may indicate that the app communicates with a server domain that is known to have been associated with malicious activities in the past.

      

   While the report can offer some information about the usage of secure data transfer protocols, it may not provide a complete picture. The application could make decisions at runtime about which protocols to use, or it could use different protocols in different circumstances. For a more thorough analysis, you might need to intercept and inspect the application's network traffic using a tool like Burp Suite.

3. Secure data transmission
   

   Android platforms by default employ TLS to protect all data transmitted to or from an Android device. However, developers have the discretion to modify their app's network security settings to permit unencrypted connections. For this reason it's useful to validate that any network configurations observed are optimised to leverage secure protocols.
   
   This information can be found in the following locations of the report:

   1. Scan Options > View AndroidManifext.xml
      

      The report will provide a detailed analysis of the AndroidManifest.xml file, which could include usage of insecure protocols, if they are declared.

      

   2. Security Analysis > Code Analysis
      

      Here, you can find the analysis of the .java or .kt files. Look for usage of HTTP/HTTPS calls in this section. It might show insecure HTTP calls (http://) if the application is using them, which would indicate that it is not using secure SSL/TLS protocols for those calls.

      

4. Application components
   

   It's useful to inspect the fundamental components of the application, including the programming language, techniques, libraries, frameworks etc, to ensure that the application employs safe elements devoid of known vulnerabilities.
   
   This information can be found in the following locations of the report:

   1. Components > Services
      

      This displays a list of all the services used by the Android application. A service is an application component that can perform long-running operations in the background, and it does not provide a user interface. It can continue running even if the application's main process is not active, or the application is in the background. These services can be important from a security perspective because they can perform actions without direct user interaction. For example, a service could be used to periodically sync data with a server, or to run some computation in the background.

      

   2. Components > Libraries
      

      This section offers a detailed view of the native libraries that the app includes, which can be helpful in the security analysis of the application, as by knowing which third-party libraries are used, you can check if these libraries have known vulnerabilities. If the version of the library used by the application is known to have security vulnerabilities, then the application might be vulnerable as well.

      

5. App store records
   

   It may be useful to conduct a thorough analysis of the data available on the app store. This includes information like the identity of the developer, the number of app installations, the frequency of updates, the presence of a process for reporting bugs, and any negative or fraudulent app reviews. Additionally, it's worth examining the developer's credibility for indications of fraudulent activities. Warning signs may include nonfunctional 'contact us' links, irrelevant information on FAQ pages, or a collection of unrelated or suspicious apps within their portfolio.

6. Third-party intelligence
   

   It can also be useful to consider looking for assessments or reports shared by other researchers to gain additional insight. For example, you could try submitting search queries to Google such as "[INSERT APP NAME HERE] vulnerability" or "[INSERT DEVELOPER NAME HERE] data breach" to identify if any evidence exists within the public domain to suggest that your organisation's adoption of the app could introduce risk.

My risk report template

Below I have included a copy of a Microsoft Word document template I drafted to help with documenting the appropriate risk report findings. My recommendation is to consider using a document like this to evidence your analysis and archive it, along with the full MobSF output, within your organisation's filesystem for auditable reference. This should help the business understand any associated point-in-time risk a particular mobile app may carry, and can be relied upon as evidence when required to demonstrate that you have exercised a reasonable degree of due diligence.

Mobile App Risk Report Template (.DOCM)	Mobile App Risk Report Template (.PDF)

The key is to present your report findings in a clear, concise manner, offering a complete picture of the potential risks, while also giving actionable recommendations for mitigating these risks. Remember to adjust and customise the template as necessary to best suit the requirements of your organisation and the specific nature of the app that you're assessing.

Follow Jacob Riggs

Jacob Riggs

Jacob Riggs is a Security Lead based in the UK with almost a decade of experience working to improve the cyber security of media and third sector organisations. His contributions focus on expanding encryption tools, promoting crypto-anarchist philosophy, and pioneering projects centred on leveraging cryptography to protect the privacy and political freedoms of others.

E3FE 4B44 56F5 69BE 76C1 E169 E3C7 0A52 9AEF DB6F