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

According to BetaNews, among the 30 best applications with more than 500,000 downloads, 94% contain at least 3 average risk vulnerabilities, while 77% contain at minimum two high-level vulnerabilities. Among the 30 applications 17% were vulnerable to MITM attacks exposing all data to interception by malicious users.

Furthermore, 44% of applications contain confidential data with strict encryption requirements, including passwords or API keys, while 66% utilize functional abilities which can compromise users’ confidentiality.
This is exactly why mobile devices are subject to numerous security discussions. Bearing this in mind, we at Hacken have decided to address the OWASP Mobile TOP 10 methodology in order to demonstrate the process of conducting vulnerability analysis for mobile applications.

OWASP mobile TOP 10 is one of the main methodologies of testing mobile applications’ vulnerabilities. The 10 vulnerabilities which are used to characterize the security level of an application are described in Table 1. [2,7,11]

We didn’t utilize online and file-sharing resources for testing “PasswordManager-1.3-release.apk” application but only used a set of programs, the description of which is provided in the Table 2. [6 – 10]

First, we decompiled “PasswordManager-1.3-release.apk” application with the help of the Apktool program (see Figure 1). Apktool decompilation doesn’t allow us to receive the source code in an understandable format but allows to access other program resources which will describe the architecture, libraries the program uses etc.

Figure 1. Decompilation of “PasswordManager-1.3-release.apk”.

Figure 2. Structure of “PasswordManager-1.3-release.apk”.

Figure 2 shows the structure of the program’s apk-file, as follows:

• AndroidManifest.xml file – describes permissions, components, recommended SDK version, and other application settings;
• Apktool.yml file – contains service information required for Apktool to conduct recompilation;
• lib directory – libraries which are additionally included in the software application by the developer are saved. In this particular case, the library with .so extension is used;
• original directory – service files of the software application are saved;
• res directory – contains a file, graphic and other resources of the software application;
• smali – source code files are saved in the form of a byte-code.

In order to view the program’s source code, we utilized the dex2jar tool (see Figure 3). It provided the opportunity to analyze the source code of the program with a help of VCG-scanner static code analyzer and manually. (see Figure 4).

Figure 3. Getting the source code of “PasswordManager-1.3-release.apk” with the help of dex2jar

Figure 4. Structure of packages and classes of “PasswordManager-1.3-release.apk” shown with the help of dex2jar

M1. Improper Platform Usage

Figure 5. AndroidManifest.xml file

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

• minimum allowable Android version – uses-sdk min SdkVersion = “23“ (Android 6.0). This information makes it possible to understand the necessary requirements for the device (or virtual machine) the program will be tested on; thus, we determine the vulnerabilities of the targeted operating systems with the help of open sources;
• the list of activities: WelcomeActivity (common), ContentActivity, FormActivity. This information gives the idea of the software application components which provide interaction between the user and a backend-program;
• service: PasswordGeneratorService. Availability of the service allows us to quickly find the class which interacts with external resources and databases.

M2. Insecure Data Storage

Some part of the debugging information in the program can be displayed in the system logs (see Figures 6 and 7). In this case, an outside program which has the READ_LOGS permission (for example, logcat or pidcat), can get access to sensitive data, thereby breaching confidential information.

During testing, we used the pidcat program (see Figure 7). The vulnerability in the programming code was detected (see Figure 8) – the developer left the Log.d() function which is used in source code debugging. [6 – 8]

Figure 6. Encrypted password

Figure 7. During the work of the program, the saved password is displayed in logs.

Recommendations on closing vulnerabilities – delete or comment out the source code line which displays the debugging information in logs.

During the program analysis by Dozer framework, exported components were found by – ContentProvider (see Figure 9), which allows us to view URI programs and get the access to local database the program uses [9].

With the help of the app.provider.query module we received access to the local database of the software application.

Figure 9. Exported URI-ContentProvider and examples of vulnerability implementation.

While analyzing source code, the insert to program local database was found (see Figure 10). The data obtained makes it possible to get unauthorized access to the system.

Figure 10. Data storage in an open form in the source code.

Recommendations on fixing the discovered vulnerability:

• to set the following flags in AndroidManifest.xml. file for this ContentProvider: android:exported = false and android: protectionLevel = “signature”;
• it’s necessary to permit ContentProvider access with a help of the following parameterized requests: query(), update() and delete().

M3. Insecure Communication

The minimum OS Android version which is identified by the program doesn’t allow for the use of Proxy. This peculiarity of the operating system provides the protection of traffic decryption with Proxy by switching the certificate.
However, an automatic switching from HTTPS to HTTP protocol is implemented in the program if the latter (HTTP) supports encrypting. This can lead to data transmission by an open channel.

M4. Insecure Authentication

The source code doesn’t have the functionality to provide a remote server authentication which carries out the checks on the following points:

• the absence of requirements regarding the user identification check;
• the absence of session control check
• the weaknesses of session management.

M5. Insufficient Cryptography

With the help of manual source code analysis of the application, we analyzed FastCrypto.java class, which carries out the conversion of the array of bytes into the checksum by the MD5 algorithm (see Figure 11). During the testing, the MD5 algorithm was considered unreliable. Its checksum can be matched both with the help of online resources and different programming tools. [13]

Passwords in the local database of the program are stored in the hash value “no salt” (see Figure 12). With the help of Drozer, we received access to the database and found the passwords. After that, with the help of the MD5 Decrypter online service, we matched the password (see Figure 13).

Figure 11. Library connection and determination of hashing algorithm.

Figure 12. The password, the checksum of which is generated by the MD5 algorithm.

Figure 13. The result of matching a checksum.

We scanned the source code with the VCG scanner program. We discovered that the program connects to the vulnerable library (see Figures 14 and 15), which is used to generate key blocks. At the time of writing the article, it was possible, in the case of using java.util.Random library, to find the next random data. We recommend the use of java.security.SecureRandom library. [12]

Figure 14. The vulnerability was found after scanning with VCG scanner.

Figure 15. Vulnerable java.util.Random library

M6. Insecure Authorization

The program doesn’t contain a functional authorization but it should be envisaged according to the program’s goal.

M7. Client Code Quality

We found the following vulnerabilities with the help of VCG scanner (see Figure 16). The control of entering a file name as well as using try/catch blocks vulnerabilities are marked in red. This can lead to error occurrence in the program operation, loading and running an executive file. The vulnerabilities connected with the usage of the Intent object are marked in green. According to the OWASP, receiving the Intent object from the other component without checking is considered a vulnerability.
Recommendations:

• use the control blocks, except try/catch;
• control the input parameters and names of files;
• check Intent objects when receiving.

Figure 16. Scanning result.

M8. Code Tampering

With the help of Drozer framework, we found the potential SQL-injection vulnerability (see Figure 17). The vulnerability can provide the ability to modify the data saved in the local database. In order to verify, we attempted to modify the data located in the database (see Figure 18.). However, the response to the query to change the information was as follows – “Not yet implemented” (see Figure 18). This means that the query to modify the data was not implemented in the program (see Figure 19), therefore, during the testing with the help of Drozer framework, we could not modify the data. [9]

Figure 17. Database vulnerability check.

Figure 18. Found vulnerability verification.

Figure 19. Data modification vulnerability.

M9. Reverse Engineering

The program’s source code isn’t obfuscated which gives the opportunity to analyze the source code. We used Apktool and dex2jar programs in order to analyze the programming code. After that, we analyzed the architecture and functions as well as the static code scanning (see Figures 1 – 5, 8, 10 – 11, 14 – 16, 18). As a result, we detected the potential vulnerabilities described above.
It’s necessary to conduct the source code obfuscation in order to protect it. Also, an encryption, as well as the means for detecting code forgery, should be envisaged.

M10. Extraneous Functionality

During the testing, no extraneous functionality was found.

Conclusions

By analyzing the ability to implement the OWASP TOP 10 methodology for testing mobile applications vulnerabilities, we can conclude that it allows us to clearly and in figures analyze the number of potential vulnerabilities which can lead to confidentiality breaches, loss of integrity, and accessibility of the information the program receives, stores, and processes. However, at the same time, some weaknesses were noted, namely, some vulnerabilities may simultaneously belong to different categories, which makes it harder to analyze the risks of the vulnerability found and the way to close it. Thus, we carried out a clear demonstration of the OWASP Mobile TOP 10 methodology implementation and concluded that the program cannot be released. The number of vulnerabilities is shown in Table 3.

About the author

This article was written by a penetration tester working at Hacken. Our specialists are skilled and qualified to check and subsequently secure your systems, applications, and networks. Diligence, high quality, transparency and quick response are only some of the benefits of working with us.

Read our success stories:
Penetration testing of TTC test-net
Crypto Exchange Penetration Testing As It is
Hacken performed penetration testing for Tokenaire