Using the OWASP Mobile TOP 10 methodology for testing Android applications.

I read my old publications and realized that they are still relevant. So please don’t judge me harshly, these were my early attempts at writing. Here is the link to the original: https://habr.com/ru/post/352252/

According to BetaNews, out of the top 30 applications with over 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 malicious interception. Furthermore, 44% of applications contain confidential data with strict encryption requirements, including passwords or API keys, and 66% use functional features that can compromise user privacy. This is why mobile devices are the subject of many security discussions. Taking all this into consideration, we at ByteCode have decided to explore the OWASP Mobile TOP 10 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 are used to characterize the security level of the application. [2,7,11]

• M1: Improper Platform Usage
• M2: Insecure Data Storage
• M3: Insecure Communication
• M4: Insecure Authentication
• M5: Insufficient Cryptography
• M6: Insecure Authorization
• M7: Client Code Quality
• M8: Code Tampering
• M9: Reverse Engineering
• M10: Extraneous Functionality

Tools

To test the application ‘PasswordManager-1.3-release.apk’ in accordance with OWASP Mobile TOP 10, we did not use online and file-sharing resources, but only used a set of programs described:

• Apktool — The program for unpacking apk-files. It is used for software localization, analyzing application structure, etc.
• adb — This is a tool that comes installed with the Android SDK and allows you to manage devices running the Android OS. It works on a client-server principle and uses port 5037.
• dex2jar — This is a tool that is used to convert a modified APK file to a JAR file.
• Drozer —This is a framework that contains tools for searching vulnerabilities in mobile devices and software. It functions as an application and interacts with the Dalvik virtual machine, other applications, and the operating system.
• VCG scanner —This is a tool for static analysis of source code and can analyze the following programming languages: C/C++, Java, C#, VB, and PL/SQL.
• JD-GUI- This is a tool that is used together with dex2jar. It provides the ability to open decompiled source code.
• Genymotion — This is tool for emulate Android OS.
• Pidcat — This is a tool for sniffing apllication log.

In start, we decompile the program ‘PasswordManager-1.3-release.apk’ using the Apktool tool. Decompilation by the Apktool program does not allow obtaining the source code in a readable form, but it allows access to other program resources that will tell about the architecture, libraries used by the program, etc.

apktool d /root/Desktop/PasswordManager-1.3-release.apk
ls -l

Decompile APK

APK-file structure

APK-file structure:

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

To view the source code of the program, we use the dex2jar tool . This made it possible to analyze the source code of the program with the VCG-scanner static code analyzer and manually .

Convert smali to java

Dex2Jar tool

M1. Improper Platform Usage

AndroidManifest.xml

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

• minimum supported Android version— uses-sdk minSdkVersion = “23” (Android 6.0). This information allows us to understand the necessary requirements for the device (or virtual machine) on which the program will run (or be tested), and from there, using open sources, to identify vulnerabilities in the target operating systems;
• Activities: WelcomeActivity (общая), ContentActivity, FormActivity. This information provides an idea of the components of the software application that enable the interaction between the user and the program’s backend;
• Service: PasswordGeneratorService. The presence of this service allows to quickly find the class that works with cryptographic functions.
• Content Provider: UsersProvider (export). The presence of a content provider allows you to find the class that interacts with external resources and databases.

M2. Insecure Data Storage

In the program, some debugging information may be displayed in the system logs. In this case, a third-party program that has READ_LOGS permission (for example, logcat or pidcat) can access sensitive information, thereby violating its confidentiality.

During testing, the pidcat program was used. The vulnerability was found in the program code — the developer left the Log.d() function, which is used for debugging the source code. [6–8]

Mobile application

Password in applications logs

Source code which display credentials

Recommendations for fixing the vulnerability — delete or comment out the line of source code that reflects the debugging information in the logs.

During the analysis of the program by the Drozer framework, exported components — ContentProvider were found , which 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 can access the local database of the software application.”

Exported ContentProvider

Analyzing the source code, an insertion into the local database of the program was found. The data found makes it possible to gain unauthorized access to the system.

Credentials in source code

Recommendations for fixing the vulnerability found:

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

M3. Insecure Communication

The minimum version of Android OS defined in the program does not allow the use of a proxy. This feature of the operating system helps protect against traffic decryption on the proxy by replacing the certificate. However, the program automatically switches from HTTPS to HTTP protocol if the latter does not support encryption, which may result in transmitting information over an open channel.

M4. Insecure Authentication

There is no functionality in the source code that should provide authentication to a remote server that performs checks on the following points:

• absence of requirements for user identification verification;
• absence of session control checks;
• deficiencies in session management.

M5. Insufficient Cryptography

Through manual analysis of the application’s source code, the FastCrypto.java class was analyzed, which converts a byte array to an MD5 hash. The MD5 algorithm has already been recognized as unreliable at the time of testing. Its hash sum can be cracked using both online resources and software tools. [13]

Passwords in the local database of the program are stored in a “saltless” hash value. Using Drozer, access to the database was obtained, and passwords were found. After that, the password was cracked using the online MD5 Decrypter service.

Insecure hash algorithm

Password, the hash sum of which is generated by the MD5 algorithm.

Decryption

The source code was scanned by the VCG scanner program, which found that the program uses a vulnerable library for generating key blocks. At the time of writing the article, when using the java.util.Random library, it is possible to predict the next random value, and it is recommended to use the java.security.SecureRandom library instead. [12]

VCG scanner result

Insecure library in source code

M6. Insecure Authorization

The program lacks authentication functionality, but it should be provided based on the program’s purpose.

M7. Client Code Quality

The following vulnerabilities were found using VCG scanner. Red vulnerabilities indicate issues with input file name control and the use of try/catch blocks. This can lead to errors when the program is running, loading, and executing the executable file. Green vulnerabilities are related to the use of the Intent object. According to OWASP, receiving an Intent object from another component without verification is considered a vulnerability.

Recommendations:

• Use exception handling blocks other than try/catch.
• Control incoming parameters and file names.
• Verify Intent objects when receiving them.

VCG results

M8. Code Tampering

A potential SQL injection vulnerability was found using the Drozer framework. This vulnerability could allow modifying data stored in the local database. To verify this, an attempt was made to modify the data in the database, but the response to the request to change the information was “Not yet implemented” . This means that the request to modify the data is not implemented in the program , so using the Drozer framework during testing does not have the ability to modify data.

Drozer scan

Drozer scan results

Code review

M9. Reverse Engineering

The program’s source code is not obfuscated, which allows analyzing the source code. The apktool and dex2jar programs were used to analyze the program code. After that, the architecture and functionality were analyzed, as well as static code scanning which revealed potential vulnerabilities that were described above.

To protect the source code, it is necessary to obfuscate it. It is also necessary to not only consider its encryption but also add means of detecting code tampering.

M10. Extraneous Functionality

No hidden functionality was found during testing.

Executive summary

After analyzing the possibility of using the OWASP Mobile TOP 10 methodology for testing vulnerabilities in mobile applications, we can conclude that it allows for a visual and numerical analysis of the number of potential vulnerabilities that can lead to a breach of confidentiality, integrity, and availability of the information that the program receives, stores, and processes. However, some drawbacks were noted, namely that some vulnerabilities can simultaneously belong to different categories, which makes it difficult to assess the risk of the vulnerability found and the way to close it. Thus, a visual demonstration of the use of the OWASP Mobile TOP 10 methodology was carried out, and it was concluded that the program cannot be released.

Testing result:

• M1. Improper Platform Usage — 1
• M2. Insecure Data Storage — 2
• M3. Insecure Communication — 1
• M4. Insecure Authentication — 0
• M5. Insufficient Cryptography — 2
• M6. Insecure Authorization — 0
• M7. Client Code Quality — 2
• M8. Code Tampering — 1
• M9. Reverse Engineering — 1
• M10. Extraneous Functionality — 0

Source

1. Sreenivasa Rao Basavala, Narendra Kumar, Alok Agarrwal. Mobile Applications -Vulnerability Assessment. Through the Static and Dynamic Analysis. — Conference on Advances in Communication and Control Systems 2013.
2. Vulnerability Testing: A Security Health Check-Up for Mobile Apps. URL: https://www.wired.com/insights/2013/04/vulnerability-testing-a-security-health-check-up-for-mobile-apps/
3. Alejandro Argudo, Gabriel López, Franklin Sánchez. Privacy vulnerability analysis for Android Applications: A practical approach (2017). URL: http://ieeexplore.ieee.org/document/7962545/
4. Ricky M., Monique L. Magalhaes. Assessing the Security of Mobile Applications — Part 1. Planning. URL: http://techgenix.com/assessing-security-mobile-applications-part1/
5. Ricky M., Monique L. Magalhaes. Assessing the Security of Mobile Applications — Part 2. Testing the application. URL: http://techgenix.com/assessing-security-mobile-applications-part2/
6. Mobile Security Wiki. URl: https://mobilesecuritywiki.com
7. DefconRU. Mobile security. URL: https://defcon.ru/category/mobile-security/
8. Information security. Basic to Advanced. Android. URL: https://securitylabexpert.wordpress.com/android/
9. MWR Labs. Drozer. URL: https://labs.mwrinfosecurity.com/tools/drozer/
10. Appie — Android Pentesting Portable Integrated Environment. URL: https://manifestsecurity.com/appie/
11. OWASP Mobile Security Project. URL: https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
12. Взлом генератора случайных чисел Java. URL: https://xakep.ru/2015/07/20 /java-random-hack/
13. Все методы взлома MD5. URL: https://xakep.ru/2013/10/13/md5-hack/