Android Pentesting

Android Penetration Testing is a systematic process used to identify security vulnerabilities in an Android application. It involves using various tools and techniques to simulate attacks on the Android app to identify and rectify any potential security flaws.

The main objective of Android penetration testing is to discover and address app vulnerabilities before they can be exploited by cybercriminals. The security concerns primarily revolve around data theft and information leakage.

Android Penetration Testing offers several key benefits:

• Identifies security threats in Android apps
• Enhances the efficiency of the app
• Safeguards sensitive app data against hackers
• Protects app data from misbehaving apps
• Helps avoid reputational damage
• Reduces the financial impact of a data breach
• Builds trust with customers

Web vs Android Pentesting

+-------------------------------------------------------------------+-----------------------------------------+
| Web Application Security                                          | Android Application Security            |
+-------------------------------------------------------------------+-----------------------------------------+
| Client-side testing is less significant                           | Client-side testing is more significant |
| Source code remains hidden (if whitebox testing is not performed) | Source code can be accessed             |
| Compromised End devices is not a concern                          | Already compromised device is a concern |
| Unrestricted app access                                           | APK distribution issues                 |
+-------------------------------------------------------------------+-----------------------------------------+

Prerequisite-

1. Rooted Android device + PC/Computer

OR

2. PC/Computer + Emulator(Android Studio’s AVD, Genymotion etc.)

Mobile Phone.……………………….Vs………………..Emulator/Virtual Device

Source- Roman’s “Android App Hacking — Black Belt Edition” Course

Debugging Errors in LAB-

bcdedit /set hypervisorlaunchtype off

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

systeminfo

Useful Commands-

/root/Android/Sdk/emulator/emulator -list-avds

/root/Android/Sdk/emulator/emulator -avd Pixel_8_API_30
/root/Android/Sdk/emulator/emulator @Pixel_8_API_30

# for resolving errors
rm /root/.android/avd/Pixel_8_API_30.avd/*lock

#Emulator Hidden menu
nc 127.0.0.1 5554

Sharing mobile screen using adb-

https://www.youtube.com/watch?v=xmCq61hjxVc&t=1s

ADB Components-

1. Daemon(Runs on the device)
2. Server (Runs on the client machine(Laptop))
3. ADB Shell (Binary installed on the client machine(Laptop))

#Connecting to adb
adb shell
adb devices
adb -s <serail> shell
adb connect <IP>

# For viewing debug logs
adb logcat

#Downloading apk from device
pm list packages
pm path <package name>
adb pull <path_of_apk>

It actually uses two ports for communication:

ADB Client Port (Default: 5037): This port is used by the ADB client running on your development machine. It listens for incoming connections from the ADB daemon on the Android device. This port is not typically configurable.
ADB Daemon Port (Default: Random assigned port): This port is used by the ADB daemon (adbd) running on the Android device. The ADB daemon listens on a randomly assigned port number in the range of 5555 to 5585 by default. This allows for connecting multiple ADB clients (e.g., emulators) to a single device without conflicts.

#Screen Mirroring and Universal Copy-Paste with Scrcpy

#Remove Bloatware
adb shell pm uninstall -k --user 0 com.facebook.appmanager

#Creating backups
adb backup -f app_backup.ab -apk com.example.myapp

#Record Screen
adb shell screenrecord /sdcard/screen.mp4

#List permissions 
adb shell dumpsys package <package_name> | grep permission

APK format-

APK is just a zip file.

• “AndroidManifest.xml” — Contains information about the app, like name, version, permissions, and components it uses.
• “META-INF/” — Directory containing metadata files required for installation and execution.
• “classes.dex” — Compiled bytecode of the app’s Java or Kotlin code.
• “lib/” — Directory containing native libraries specific to certain device architectures.
• “res/” — Directory containing the app’s resources, such as images, layouts, strings, and styles.
• “resources.arsc” — Binary file containing compiled resources from the “res/” directory.

Showcase Mobsf (Automated Testing)

Showcase Dynamic Testing

SSL Pinning Bypass-

adb push /root/Downloads/frida-server-16.2.1-android-x86 /data/local/tmp
chmod 777 /data/local/tmp/frida-server-16.2.1-android-x86

ps -ef | grep -i frida
adb forward tcp:27042 tcp:27042

frida-ps -Uai

objection --gadget com.application.zomato explore
>android sslpinning disable

biometric byapss

Drozer Commands

adb forward tcp:27042 tcp:27042
drozer console connect
run app.package.info -a com.withsecure.example.sieve
run app.package.attacksurface com.withsecure.example.sieve

M3: Insecure Authentication/Authorization example-

run app.activity.info -a com.withsecure.example.sieve

# opens activity containing sensitive info
run app.activity.start --component com.withsecure.example.sieve com.withsecure.example.sieve.activity.PWList

M3: Insecure Authentication/Authorization another example-

#listing content providers
run app.provider.info -a com.withsecure.example.sieve

run scanner.provider.finduris -a com.withsecure.example.sieve

https://owasp.org/www-project-mobile-top-10/

M9: Insecure Data Storage

1.ADB Logcat-

The issue of adb logcat revealing sensitive information fall under the category of “M9: Insecure Data Storage” in the OWASP Mobile Top 10 Risks 2024. This risk involves storing sensitive information insecurely on the system. If an application is logging sensitive information to logcat, it could potentially be accessed by an attacker, especially if the device is rooted. Therefore, developers should avoid logging sensitive information and ensure secure data storage practices are followed. Please note that the specific categorization can vary depending on the exact nature and context of the risk.

Primary use cases of adb logcat in Android pen-testing are:

1. Monitoring App Behavior: Identify suspicious activities, data leaks, file system access, and potential entry points for exploitation.
2. Identifying Vulnerabilities: Uncover hardcoded credentials, insecure cryptographic implementations, input validation issues, and other weaknesses.
3. Debugging and Reverse Engineering: Understand app logic, APIs used, and execution flow for effective reverse engineering.
4. SSL/TLS Analysis: Analyze SSL/TLS connections, cipher suites, certificates, and potential vulnerabilities.
5. Permission Analysis: Identify permissions requested by the app and potential privilege escalation or data leakage risks.
6. Error Handling and Crash Analysis: Investigate app crashes, exceptions, and stack traces for memory corruption or other vulnerabilities.
7. Dynamic Analysis: Use in conjunction with tools like Frida or Ghidra for comprehensive dynamic analysis.

• adb logcat --pid=<process_id> - Filters the log output for the specified process ID.
• adb logcat --pid=$(pidof com.example.app) - Filters the log output for the process with the specified package name.

2. Harcoded Secrets-

https://payatu.com/blog/damn-insecure-and-vulnerable-app-diva/

apktool d diva.apk
grep -Ri vendor

M1: Improper Platform Usage

1. SQL injection-

This issue fall under the category of “M1: Improper Platform Usage” in the OWASP Mobile Top 10 Risks 2024. This category includes misuse of a platform feature or failure to use platform security controls. It might also include incorrect assumptions about the environment, such as the case here where the developer has assumed that input will be safe.

In the example shown, the input “‘or ‘1’=’1' — “ is used to manipulate the SQL query and return all user data, bypassing any username requirement. This is a clear indication of improper input validation.

Developers should always validate, filter, and sanitize input to prevent such vulnerabilities. They should also use parameterized queries or prepared statements to ensure that user input is not treated as part of the SQL command.

M3: Insecure Authentication/Authorization

The application allows access to API credentials without proper authentication or authorization.

Clicking the “View API Credentials” button provides access, but the challenge is to bypass this step and directly access the credentials.

The vulnerability lies in the improper handling of access controls.
The activity responsible for displaying API credentials lacks proper restrictions.
Steps Taken:
1. By analyzing logcat output, you identified the name of the next activity after clicking the button.
2. You used the adb shell am start command to directly launch the APICredsActivity.
3. As a result, you gained access to the API credentials without any authentication or restrictions.
Implications:
This vulnerability allows unauthorized access to sensitive information.
Other apps could potentially exploit the same weakness to access these credentials.
Mitigation:
Developers should enforce proper authentication and authorization mechanisms.
Activities handling sensitive data should have appropriate access controls.
Regular security testing and code reviews are essential to identify and fix such issues.

adb shell am start jakhar.aseem.diva/.APICredsActivity
adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.action.VIEW_CREDS