Application of the OWASP Mobile TOP 10 methodology for testing Android applications

According to BetaNews, of the top 30 applications with more than 500,000 installations, 94% contain at least three medium-risk vulnerabilities, and 77% contain at least two high-risk vulnerabilities. Of the 30 applications, 17% were vulnerable to MITM attacks, exposing all data to interception by intruders.

In addition, 44% of applications contain sensitive data with strict encryption requirements, including passwords or API keys, and 66% use functionality that could jeopardize user privacy.

That is why mobile devices are the subject of many security discussions. Taking all this into account, we at Hacken decided to review the OWASP Mobile TOP10 methodology in order to demonstrate the process of analyzing mobile applications for vulnerabilities.

OWASP Mobile TOP 10 is one of the main methodologies for testing applications for vulnerabilities. Table 1 describes 10 vulnerabilities that apply to characterize the security level of an application. [2,7,11]

Table 1: Vulnerabilities and their descriptions

To test the application “PasswordManager-1.3-release.apk”, in accordance with the OWASP Mobile TOP 10, we did not use online and file-sharing resources, but only used the set of programs described in Table 2. [6 - 10]

Table 2: Programs Used

First, we decompile the PasswordManager-1.3-release.apk program using the Apktool tool (see Figure 1). Decompiling with Apktool does not allow you to get the source code in an understandable form, but it allows you to gain access to other program resources that tell about the architecture, the libraries that the program uses, etc.

Fig. 1. Decompiling PasswordManager-1.3-release.apk.

Fig. 2. The structure of "PasswordManager-1.3-release.apk".

In fig. 2. shows the structure of the apk-file of the program, namely:

• AndroidManifest.xml file - describes permissions, components, SDK version, which is recommended to use, and other application settings;
• apktool.yml file - contains service information necessary for Apktool to be recompiled;
• lib directory - saves the libraries that are additionally loaded into the software application by the developer. In this case, a library with the .so extension is used;
• original directory - the service files of the software application are saved;
• res directory - contains file, graphic and other resources of the software application;
• smali - saved source code files in bytecode.

To view the source code of the program, we use the dex2jar tool (see Fig. 3). This made it possible to analyze the source code of the program with a static code analyzer VCG-scanner and manually (see. Fig. 4).

Fig. 3. Getting the source code "PasswordManager-1.3-release.apk" using dex2jar

Fig. 4. The package and class structure of “PasswordManager-1.3-release.apk” shown by dex2jar

M1. Architectural Bypass (Improper Platform Usage)

Fig. 5. AndroidManifest.xml file

Access to the AndroidManifest.xml file gives the following information about the program:

• Android minimum version - uses-sdk minSdkVersion = "23" (Android 6.0). This information allows you to immediately understand the necessary requirements for the device (or virtual machine) on which the program will work (or be tested), and from here, using open sources, find out the vulnerabilities of target operating systems;
• list of activities: WelcomeActivity (total), ContentActivity, FormActivity. This information gives an idea of ​​the components of a software application that provide user interaction and the program's backend;
• service: PasswordGeneratorService. The presence of this service allows you to quickly find a class that works with cryptographic functions;
• Content Provider: UsersProvider (Exported). The presence of a content provider allows you to find a class that interacts with external resources and databases.

M2. Insecure Data Storage

In the program part of the debug information can be displayed in the system logs (see Fig. 6 and 7). In this case, a third-party program that has READ_LOGS rights (for example, logcat or pidcat) can access sensitive information, thereby violating its confidentiality.

During testing, the pidcat program was used (see Fig. 7). The vulnerability was detected in the program code (see Fig. 8) - the developer left the Log.d () function, which is used to debug the source code. [6 - 8]

Fig. 6. Password is encrypted.	Fig. 7. In the process of the program, the password that is saved is displayed in the logs.

Fig. 8. The place in the program code, which leads to data leakage.

Recommendations for closing the vulnerability - remove or comment out the line of the source code that reflects debugging information in the logs.

When analyzing the program by the Drozer framework, the exported components were found - ContentProvider (see Fig. 9); this allows you to view the program's URI and access the local database that the program uses [9].

Using the app.provider.query module, we get access to the local database of the software application.

Fig. 9. Exported URI-ContentProvider and examples of the implementation of the vulnerability.

By analyzing the source code, an insertion into the local database of the program was found (see Fig. 10). The data found makes it possible to gain unauthorized access to the system.

Fig. 10. Storage of data in open form in the source code.

Recommendations for fixing a found vulnerability:

• the file in AndroidManifest.xml for this ContentProvider set the following flags: android: exported = false and android: protectionLevel = "signature";
• Access to ContentProvider must be performed using parameterized queries: query (), update () and delete ().

M3. Insecure Communication

The minimum version of the Android OS, which is defined in the program, does not allow the use of Proxy. This feature of the operating system allows you to protect against decryption of traffic on the Proxy by replacing the certificate.
But the program implements automatic switching from the HTTPS protocol to the HTTP, if the latter does not support encryption, which can lead to the transfer of information by the open transmission channel.

M4. Insecure Authentication

In the source code there is no functionality that should provide authentication on a remote server that checks the following items:

• no requirements for verification of user identification;
• lack of verification control sessions;
• lack of session management.

M5. Weak cryptoresistance (Insufficient Cryptography)

Using manual analysis of the source code of the application, we analyzed the class FastCrypto.java, which converts an array of bytes into a hash sum using the MD5 algorithm (see Fig. 11). The MD5 algorithm at the time of testing has already been recognized as unreliable. Its hash sum can be selected, both with the help of online resources, and with the help of software tools. [13]

Passwords in the local database in programs are stored in the salt-free hash value (see Fig. 12). With the help of Drozer, access to the database was obtained and passwords were found. After that, using the MD5 Decrypter online service, a password was selected (see Fig. 13).

Fig. 11. Connecting the library and hashing algorithm definitions.

Fig. 12. A password whose hash sum is generated by the MD5 algorithm.

Fig. 13. The result of the selection of the hash sum.

The source code was scanned by the VCG scanner program and found that the program includes a vulnerable library (see Fig. 14 and 15), which is used to generate key blocks. At the time of this writing, when using the java.util.Random library, it is possible to find the following random value and it is recommended to use the java.security.SecureRandom library. [12]

Fig. 14. Vulnerability after scanning VCG scanner.

Fig. 15. Vulnerable java.util.Random library.

M6. Insecure Authorization

There is no authorization functionality in the program, but it should be provided, based on their program purpose.

M7. Content Control Client Applications (Client Code Quality)

The following vulnerabilities were found using the VCG scanner (see Figure 16). The red color highlights the vulnerabilities of the control over the input of the file name and the use of try / catch blocks. This can lead to errors when running the program, loading and running the executable file. Vulnerabilities related to the use of the Intent object are highlighted in green. According to OWASP, accepting an Intent object from another component without checking is considered a vulnerability.
Recommendations:

• use of control blocks with the exception of try / catch;
• control of incoming parameters and file names;
• checking intent objects upon their receipt.

Fig. 16. Scanning result.

M8. Data Modification (Code Tampering)

Using the Drozer framework, a potential SQL-injection vulnerability was found (see Figure 17). This vulnerability may provide the ability to modify data stored in a local database. For verification, an attempt was made to modify the data in the database (see Fig. 18), but a response to the request for information change was received - “Not yet implemented” (see Fig. 18). This means that the request for data modification is not implemented in the program (see Fig. 19), therefore, using the Drozer framework, for the time of testing, it is not possible to modify the data. [9]

Fig. 17. Check database vulnerabilities.

Fig. 18. Verification of the found vulnerability.

Fig. 19. The weak point of data modification.

M9. Source Code Analysis (Reverse Engineering)

The source code of the program is not obfuscated, which makes it possible to analyze the source code. For the analysis of the program code, the programs apktool and dex2jar were used. After that, the architecture and the functional were analyzed, as well as a static code scan (see Fig. 1 - 5, 8, 10 - 11, 14 - 16, 18) was carried out and potential vulnerabilities described above were revealed.

To protect the source code it is necessary to obfuscate it. It is also necessary to provide not only its encryption, but also to add means for detecting code falsification.

M10. Hidden functionality (Extraneous Functionality)

Hidden functionality was not found at the time of testing.

findings

After analyzing the possibility of using the OWASP Mobile TOP 10 methodology for testing mobile application vulnerabilities, we can conclude that it allows you to visually and in numbers analyze the number of potential vulnerabilities that could lead to a breach of confidentiality, integrity and availability of information that the program receives, stores and processes . But at the same time, some shortcomings were noted, namely, some vulnerabilities can be simultaneously classified into different categories, which makes it difficult to assess the risk of the found vulnerability and how to close it. Thus, a visual demonstration of the use of the OWASP Mobile TOP 10 methodology was conducted and it was concluded that the program should not be released. The number of vulnerabilities is shown in Table 3.

Table 3: