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

Image for post
Image for post

Originally published in Hub Hacken Blog.

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]

Image for post
Image for post

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]

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

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;

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).

Image for post
Image for post

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

Image for post
Image for post

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

M1. Improper Platform Usage

Image for post
Image for post

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;

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]

Image for post
Image for post

Figure 6. Encrypted password

Image for post
Image for post

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

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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”;

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;

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).

Image for post
Image for post

Figure 11. Library connection and determination of hashing algorithm.

Image for post
Image for post

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

Image for post
Image for post

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]

Image for post
Image for post

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

Image for post
Image for post

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;
Image for post
Image for post

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]

Image for post
Image for post

Figure 17. Database vulnerability check.

Image for post
Image for post

Figure 18. Found vulnerability verification.

Image for post
Image for post

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.

Summing all up

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.

Image for post
Image for post

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

Written by

The community of crypto and cybersecurity enthusiasts united to keep not only themselves but also their friends and family safe in today’s digital world.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store