Security audit on Android apps

The world we live in is constantly evolving, as are technological advances, with mobile devices being one of the most prominent in recent times. According to Google, in 2021,  there were already more than 3,000 million devices with  Android operating system in the world.

In the face of high demand, thousands of new applications are developed, installed, and used every day on devices, both personal and corporate, that use user data. Some of these data are sensitive, as is the case of banking or payment, medical or health applications, or even applications aimed at the education or training of minors. Therefore, mobile applications (or apps) need to be subjected to security audits by design.

Security audits help to verify that the best practices of secure development are being followed  and that data  protection legislation is complied with, or sectoral standards, such as  the PSD2 digital payment services directive,  which regulates payment services (e.g. transfers, direct debits, card payments...) made in Europe in order to promote the  transparency, competition and innovation of payment services in the financial sector. The objective of the audits is to detect all the vulnerabilities that may affect our apps to correct them and prevent cybercriminals from taking advantage of them to compromise our mobile devices with malicious intentions.

Both those who have a personal interest or curiosity, as well as those who are part of an application development team or are dedicated to systems auditing, will find in this article interesting resources to deploy a small Android audit lab and improve their skills in this field, with existing methodologies and tools.
 

Main threats

Mobile apps, in general, and Android are subject to several threats. The top 10 are included in the  OWASP Mobile Top 10 project:

1. Inappropriate Platform Use: Refers to the lack of proper use of the platform's security features, such as platform permissions and password services, as well as the inappropriate use of any exposed APIs.
2. Insecure data storage: implies the lack of security in data storage, either using cache, cookies, or other information by third-party applications to collect protected data, or by the possibility of an adversary physically obtaining the device and accessing the information stored on it.
3. Insecure communication: includes the use of insecure handshakes, incorrect SSL versions, or unencrypted communication of sensitive data.
4. Insecure authentication: includes the lack of proper identification of the user, when necessary, the inaccuracy of maintaining the user's identity when required, or weaknesses in the handling of sessions.
5. Insufficient cryptography: has to do with problems in the application of cryptography, either due to lack of proper use or its incorrect application.
6. Insecure authorization: This has to do with flaws in the authorization process, such as client-side permission decisions or forced browsing, and is different from authentication issues, such as device enrollment or user identification.
7. Client-side code quality: Applies to client-side code-level implementation issues such as buffer overflows, format string vulnerabilities, and other code-level bugs that require code rewriting to fix.
8. Code adulteration: This category covers binary patching, local resource modification, incorrect method utilization, and dynamic memory modification. Therefore, this category covers any modifications that the adversary can make to the application code. 
9. Inverse engineering: includes the analysis of the final binary to determine its source code, libraries, algorithms, and other assets. It can be used to exploit other vulnerabilities in the application, as well as to reveal information about backend servers, cryptographic keys, and intellectual property.
10. Strange functionality: This vulnerability arises when developers do not remove additional features, created during the development process to facilitate the testing of the application and that can be exploited to perform attacks against the application.
     

OWASP MAS Test Methodology

OWASP Mobile Application Security (MAS) project provides a  Mobile Application Security Standard (MASVS) and a comprehensive test guide (MASTG) covering the processes, techniques, and tools used during a mobile application security test, as well as a comprehensive set of test cases that enable testers to obtain consistent and complete results.

In addition to these two resources, OWASP proposes a checklist that helps us review the security requirements of mobile applications in a simple way. This checklist covers the following domains:

• Architecture, design, and modeling of threats: structural aspects of the application are reviewed to ensure that they are secure by design.
• Availability and data storage: the protection of sensitive data, such as user credentials and the management of private information, is analyzed.
• Cryptography: it is valued that current encryption standards and protocols are followed to protect sensitive information.
• Authentication and session management: examines whether some of the basic requirements are followed to manage user accounts and sessions.
• Network communication: it is verified that confidentiality and integrity are protected in the exchanges of information between the app and the service endpoints.
• Platform interaction: security is evaluated in the use of APIs and components.
• Code quality and build configuration: Discusses the application of secure development practices and the use of appropriate security options in build options.
• Resilience: It is reviewed if the application has specific measures to resist certain attacks on the client side, for example, through detection or obfuscation mechanisms.                                                
   

- Excerpt from the OWASP checklist to verify mobile security requirements. Source -

Tools for app security testing

The security requirements discussed in the previous section can be assessed from two complementary points of view:

• Static analysis: Static tests seek to analyze the security of the application from different artifacts, such as source code, decompiled code, binary object, or its associated files, without the need to run the application. By certain metadata, function calls, or the sequence of instructions posed by the flow of the program, possible vulnerabilities can be identified. We can find open-source tools or with free version such as:
  • Mara: a framework that allows the analysis of apps. Among other things, it allows you to unravel and decompile apks, obfuscation, string analysis, permission extraction, etc. 
  • APK Analyzer: offers a lot of information about installed applications and APK files, such as permissions, activities, certificates, signatures, etc. 
  • JAADAS: performs static analysis of the IPCs to find vulnerabilities in Android applications, built on  Soot and Scala. 
• Dynamic analysis: These tests aim to observe the behavior of the application after subjecting it to particular conditions. It is required, therefore, that the app is in operation, so that the evaluator can interact with it. To do this, we can find tools such as:
  • Drozer: Allows you to scan for security vulnerabilities in applications by interacting with the Dalvik virtual machine, the IPC endpoints of other applications, and the underlying operating system.
  • Burpsuite: works as a web proxy. It allows to capture and manipulate web traffic between a client and a server, being very useful to audit the security of the application's communications.
  • Inspeckage: tool developed to offer dynamic analysis of Android applications. By applying hooks to Android API functions, you help understand what an Android app is doing at runtime.

There are also hybrid tools that allow static and dynamic analysis. For example, this is the case of Mobile Security Framework Mobile Security Framework (MobSF).

Vulnerable test applications

The most interesting and attractive way to exercise the methodology and tools mentioned, from the technical point of view, is through vulnerable test applications, that is, those designed with the purpose of being analyzed, since they include intentional vulnerabilities. Here are a few:

• InsecureShop: is a vulnerable online store for Android. Most vulnerabilities can be exploited on an unrooted device. The application does not use any APIs. It covers a total of 19 vulnerabilities.
• AndroGoat: This is the first vulnerable application developed with Kotlin. This application covers 24 different vulnerabilities.
• InsecureBank V2: is an apk with a backend server written in Python. This application covers 25 different vulnerabilities.
• Crackmes: within the MAS project, which we have already talked about in the methodology section, a series of vulnerable Android apps oriented to the CTF are proposed. It is structured in 4 levels of difficulty.

Conclusions

Modern technologies bring with them new security risks and mobile technology is no exception. Despite constant advances in the security of Android operating systems, much of the security of apps still falls on the capabilities of developers to design, deploy and maintain robust and vulnerability-free applications. 

In this article, we have seen that the validation of security in crucial aspects of applications, such as data storage, communication between apps, the proper use of cryptographic APIs, or secure network communication, involves including audit points within the life cycle of the same. By applying good methodologies, tools, and resources in these security tests, we will be limiting the risks of our Android mobile application users.