Contents
APK Vulnerability Assessment: ......................................................................................................... 2
Abstract ....................................................................................................................................... 2
Introduction ................................................................................................................................. 2
Tools: ........................................................................................................................................... 2
Using the Mobsf for the vulnerability Assessment: ........................................................................... 3
Uploading the APK file : ............................................................................................................ 4
Application Permissions ........................................................................................................... 5
Android Api ............................................................................................................................. 5
Common Weakness Enumeration: ........................................................................................... 7
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') 7
CWE-327: Use of a Broken or Risky Cryptographic Algorithm ..................................................... 8
CWE-330: Use of Insufficiently Random Values.......................................................................... 8
Reverse Engineering On Vulnerable APK ........................................................................................... 9
CVSS Table For the APK Vulnerability Assessment .............................................................. 22
Summary of Security Concerns: .................................................................................................... 22
Key Recommendations: ............................................................................................................ 22
APK Vulnerability Assessment:
Abstract
This project involves conducting a vulnerability assessment of a purposely vulnerable Android
application obtained from the AllSafe platform. The primary objective is to identify potential security
weaknesses within the APK using the Mobile Security Framework (MobSF). By performing a detailed
static and dynamic analysis, the goal is to uncover insecure coding practices, improper configurations,
and potential data leakage risks. The assessment helps in understanding how common vulnerabilities can
be exploited and provides insight into securing mobile applications effectively.
Introduction
Mobile Security Framework (MobSF) is an open-source automated tool designed for comprehensive
security analysis of mobile applications, including Android, iOS, and Windows platforms. It supports
both static and dynamic analysis, making it a powerful solution for penetration testers, developers, and
security researchers. MobSF can decompile APK files to inspect code, detect hardcoded secrets, insecure
permissions, exposed components, and other vulnerabilities. Additionally, it provides runtime analysis
through a dynamic testing environment. Its ease of use and detailed reporting make MobSF a widely used
tool for mobile application security assessments.
Tools:
I am performing a vulnerability assessment of Android applications using the Mobile Security Framework
(MobSF) along with Genymotion. MobSF enables static and dynamic analysis of APK files to identify
potential security issues such as insecure coding practices, misconfigurations, exposed components, and
sensitive data leakage. For dynamic analysis, I use Genymotion to emulate an Android environment,
allowing MobSF to execute the APK in a controlled virtual device and monitor its runtime behavior. This
combination of tools helps efficiently detect vulnerabilities and enhances the overall security assessment
process of Android applications.
Using the Mobsf for the vulnerability Assessment:
Tool installation includes importing the Docker image:
Tool initiated:
Uploading the APK file :
Application Permissions
The table displays a list of Android application permissions, categorized by their PERMISSION,
STATUS (e.g., normal, dangerous), INFO (a brief summary), DESCRIPTION (a more detailed
explanation of what the permission allows), and CODE MAPPINGS (links to relevant code files, likely in
Java).
Permissions shown include:
● android.permission.ACCESS_NETWORK_STATE: Allows viewing of network status.
● android.permission.INTERNET: Grants full internet access.
● android.permission.QUERY_ALL_PACKAGES: Enables querying of any normal app on the
device.
● android.permission.READ_EXTERNAL_STORAGE: Allows reading external storage contents
(marked as dangerous).
● android.permission.RECORD_AUDIO: Allows recording audio (marked as dangerous).
● android.permission.WRITE_EXTERNAL_STORAGE: Allows reading, modifying, or deleting
external storage contents (marked as dangerous).
Android Api
● Android Notifications: This likely pertains to the API for creating and managing notifications on
Android devices. The associated file is NoteReceiver.java.
● Base64 Decode: This refers to the functionality for decoding Base64 encoded data. The file
PratBypass.java suggests a context where Base64 decoding might be involved in bypassing
certain checks or protections.
● Content Provider: This API is fundamental for sharing data between applications in Android.
The file DataProvider.java is directly related to implementing a Content Provider.
● Crypto: This section is for cryptographic operations. It lists multiple files:
o SQLInjection.java: This is particularly interesting as it suggests a potential security
vulnerability (SQL Injection) being explored in the context of cryptography, perhaps due
to improper use of cryptographic keys or data handling that allows injection.
o WeakCryptography.java: This file explicitly points to the use of weak cryptographic
practices, which is a common security concern.
o Other files like OkioBuffer.java, OkioByteString.java, OkioHashingSink.java,
OkioHashingSource.java, and OkioSegmentedByteString.java are likely related to the
Okio library, which is a modern I/O library for Java and Kotlin often used in conjunction
with cryptographic operations for efficient data handling.
● Dynamic Class and Dexloading: This refers to the ability of an Android application to load code
dynamically at runtime, including classes and DEX (Dalvik Executable) files. This can be a
powerful feature but also a security risk if not handled carefully.
● Execute OS Command: This category indicates the capability to execute operating system
commands from within the Android application. The file RootBeer.java suggests this might be
related to root detection or functionality that could be exploited in rooted environments.
Overall, this interface appears to be part of a system for analyzing, learning about, or auditing Android
applications, with a strong focus on security-related aspects given the presence of files mentioning "SQL
Injection," "Weak Cryptography," and "RootBeer." The "challenges" in the file paths further support this
idea.
Common Weakness Enumeration:
CWE-89: Improper Neutralization of Special Elements used in an SQL Command
('SQL Injection')
Description from the image: "App uses SQLite Database and execute raw SQL query. Untrusted user
input in raw SQL queries can cause SQL injection. Also sensitive information should be encrypted and
written to the database."
Explanation: This CWE describes a vulnerability where an application constructs all or part of an SQL
command using input that comes from an external source (like user input from a web form, URL, or
cookie) without properly "neutralizing" or sanitizing special characters in that input. This allows an
attacker to inject their own SQL code into the query, potentially leading to unauthorized access, data
manipulation, or even data deletion.
Impact: Attackers can bypass authentication, access sensitive data, modify or delete data, or even
execute arbitrary commands on the database server.
Example (Conceptual): If an application builds a SQL query like SELECT * FROM users WHERE
username = ' + userInput + ', and userInput is admin' OR '1'='1, the resulting query becomes SELECT *
FROM users WHERE username = 'admin' OR '1'='1', which would return all users, bypassing
authentication.
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
This CWE appears twice in the image, for two different but related issues:
MD5 Weak Hash:
Description from the image: "MD5 is a weak hash known to have hash collisions."
Explanation: This refers to the use of cryptographic algorithms that are considered weak, broken, or
have known vulnerabilities. MD5 is a hashing algorithm that, while once widely used, is now known to
be susceptible to "collision attacks." A collision occurs when two different inputs produce the same hash
output, which can be exploited to forge digital signatures or compromise data integrity.
Impact: Data integrity can be compromised, and in some cases, it can lead to authentication bypass
or data forgery.
ECB Mode in Encryption:
Description from the image: "The App uses ECB mode in cryptographic encryption algorithm. ECB
mode is known to be weak as it results in the same ciphertext for identical blocks of plaintext."
Explanation: This is another instance of using a weak cryptographic method. ECB (Electronic
Codebook) is a mode of operation for block ciphers. While it encrypts each block independently, this
simplicity is its downfall. If the same plaintext block appears multiple times in the input, it will produce
the exact same ciphertext block. This leaks patterns in the data, making it easier for attackers to perform
cryptanalysis, especially on images or structured data.
Impact: Patterns in encrypted data can be revealed, compromising confidentiality, even if the
underlying encryption algorithm itself is strong.
CWE-330: Use of Insufficiently Random Values
Description from the image: "The App uses an insecure Random Number Generator."
Explanation: This CWE occurs when an application relies on random numbers or values in security-
critical contexts (like generating session IDs, cryptographic keys, or tokens) but uses a generator that
produces predictable or insufficiently random outputs. True randomness is hard for computers, so pseudo-
random number generators (PRNGs) are used. If a PRNG is not "cryptographically secure" (CSPRNG),
its sequence of numbers can be predicted by an attacker, especially if the seed (starting point) is weak or
guessable.
Impact: Predictable values can lead to various attacks, including session hijacking, brute-force attacks
on sensitive data (like password reset tokens), or the generation of weak cryptographic keys.
Reverse Engineering On Vulnerable APK
Allsafe is an intentionally vulnerable application that contains various vulnerabilities. Unlike
other vulnerable Android apps, this one is less like a CTF and more like a real-life application
that uses modern libraries and technologies.
Tools Used :
Jadx-gui, adb, frida
Genymotion (a popular Android emulator used for app development and security testing)
Drag and drop the apk file that you want to test . In this scenario I am using Allsafe apk
adb devices command, which lists connected Android devices. This verifies that the emulator is
connected to the Android Debug Bridge (adb), a command-line tool that allows communication with an
emulator or device.
Root Access
Challenge 1
This application logs the user-entered string in the application logs insecurely.
This challenge is straightforward and we don’t need to dig deep into the code. After you open the
challenge and before typing anything in the textview you first need to use logcat to monitor the logs.
With grep we can also locate the entering text
Challenge 2
Hardcoded credentials mean that authentication details are stored in the application’s
source code as plain text. To retrieve this information, we need to reverse engineer the
application. For this purpose, I used the jadx-gui tool
Navigate to Source code > challenges > hardcoded credentials
Hard coded credentials
When examining the class file, I observe a variable named BODY that stores SOAP request data.
Within this data, we can identify a username and password combination embedded in the
content.
Username
password
Another hardcoded credentials
Username :admin
Password : password123
Challenge 3
Firebase is a Realtime cloud-based NoSQL database that can be integrated with both
Android and iOS apps. To start our testing we first need to find the firebase URL.
from our browser , access the /.json endpoint. If we get a Permission Denied response that means
that the database is properly configured but if we get a json data or even null as a response that
means you at least have read permission.
We found a flag
Challenge 4
SQL injection
Frida is a dynamic instrumentation toolkit used in Android penetration testing to interact with and
manipulate running applications in real-time. It allows security researchers and pentesters to inspect,
hook, and modify app behavior without source code access.
Challenge
Pin Bypass
If we look at the source code, you’ll see that the function responsible for validating the PIN is
called checkPin and it returns true if the PIN we entered is the same as the hardcoded one
To brute-force the correct 4-digit PIN by calling the vulnerable method checkPin(String pin) directly we
will be using Frida, instead of manually entering 0000 to 9999.
enter a dummy pin to trigger the checkPin function and you’ll find that the correct pin is logged in the
frida REPL shell
code for pin_bypass
When the app calls checkPin("1234") from the UI, our script intercepts that call and:
1. Runs a brute-force loop from 0000 to 9999
2. Calls the original checkPin() with each value
3. When checkPin("4863") returns true, it logs:
Now, spawn the app using frida and give it the script to be injected as follows:
frida -U -l pinbypass.js -f infosecadventures.allsafe
Access granted
Typical CVSS v3.1 Base
Finding Description CWE ID What the CWE Does (Brief)
Score
Logs confidential information, leading to data
Sensitive data logged. CWE-532 6.5 (Medium)
exposure.
Stores data on world-readable/writable external
Insecure External Storage. CWE-276 6.8 (Medium)
storage.
Stores sensitive data (e.g., passwords, keys) in
Hardcoded Sensitive Info. CWE-312 7.5 (High)
plaintext in code.
Allows attackers to inject malicious SQL commands
SQL Injection. CWE-89 9.8 (Critical)
into queries.
Weak Hashing Algorithm Uses an outdated hash that can be easily "collided"
CWE-327 5.9 (Medium)
(MD5). or reversed.
Insecure Random Number Generates predictable "random" numbers,
CWE-330 7.5 (High)
Generator. compromising security features.
Reveals patterns in encrypted data due to identical
ECB Mode in Cryptography. CWE-327 5.9 (Medium)
ciphertext blocks.
CVSS Table For the APK Vulnerability Assessment
Summary of Security Concerns:
The application contains several critical vulnerabilities related to improper handling of sensitive data
(logging, hardcoding, insecure storage) and weak cryptographic implementations. The presence of SQL
Injection is particularly concerning as it can lead to full database compromise.
Key Recommendations:
● Prioritize Critical Vulnerabilities: Address SQL Injection immediately.
● Secure Data Handling: Ensure sensitive data is never logged, hardcoded, or stored insecurely on
external storage.
● Strengthen Cryptography: Use modern, robust cryptographic algorithms and secure modes of
operation for all encryption and hashing needs.
