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 StorageSome 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 CommunicationThe 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 hav
