Exploiting Insecure Data Storage In Mobile

Exploiting Insecure Data Storage in Mobile

When to Use

Use this skill when:

• Assessing whether mobile applications store sensitive data securely on the device filesystem
• Testing for credential leakage through SharedPreferences, SQLite databases, or plists
• Evaluating keychain/keystore implementation for proper access control attributes
• Performing data-at-rest security assessment during mobile penetration tests

Do not use this skill on production user devices without authorization -- data extraction techniques require physical access or root/jailbreak privileges.

Prerequisites

• Rooted Android device or emulator with ADB access
• Jailbroken iOS device with SSH access or Objection-patched IPA
• ADB (Android Debug Bridge) for Android filesystem access
• SQLite3 CLI for database inspection
• Frida/Objection for runtime data extraction
• Target application installed and exercised (logged in, data cached)

Workflow

Step 1: Map Application Data Storage Locations

Android storage paths:

# Internal storage (app-private, requires root)
/data/data/<package_name>/
├── shared_prefs/      # SharedPreferences XML files
├── databases/         # SQLite databases
├── files/             # General files
├── cache/             # Cached data
├── lib/               # Native libraries
└── app_webview/       # WebView data

# External storage (world-readable on older Android)
/sdcard/Android/data/<package_name>/

# Check for world-readable files
adb shell run-as <package_name> ls -la /data/data/<package_name>/

iOS storage paths:

# App sandbox (accessible via SSH on jailbroken device)
/var/mobile/Containers/Data/Application/<UUID>/
├── Documents/         # User data, backed up by default
├── Library/
│   ├── Preferences/   # NSUserDefaults plists
│   ├── Caches/        # Cache data
│   └── Application Support/
└── tmp/               # Temporary files

Step 2: Extract and Analyze SharedPreferences (Android)

# Pull SharedPreferences files
adb shell run-as <package_name> cat shared_prefs/*.xml

# Or on rooted device
adb pull /data/data/<package_name>/shared_prefs/ ./shared_prefs/

# Search for sensitive data
grep -ri "password\|token\|secret\|key\|session\|auth\|cookie" shared_prefs/

Common insecure storage patterns:

<!-- Plaintext credentials -->
<string name="user_password">mysecretpass123</string>
<string name="auth_token">eyJhbGciOiJIUzI1NiIs...</string>
<string name="api_key">sk-live-abc123def456</string>

<!-- Sensitive PII -->
<string name="user_ssn">123-45-6789</string>
<string name="credit_card">4111111111111111</string>

Step 3: Analyze SQLite Databases

# Pull databases
adb pull /data/data/<package_name>/databases/ ./databases/

# Open and inspect
sqlite3 databases/app.db
.tables
.schema users
SELECT * FROM users;
SELECT * FROM sessions;
SELECT * FROM tokens;

# Search all tables for sensitive columns
sqlite3 databases/app.db ".dump" | grep -i "password\|token\|secret\|credit"

Check for unencrypted SQLCipher databases:

# If database opens without password, it's unencrypted
sqlite3 databases/app.db "SELECT count(*) FROM sqlite_master;"
# Success = unencrypted (vulnerability)

Step 4: Inspect iOS Keychain Storage

# Using Objection
objection --gadget com.target.app explore
ios keychain dump

# Check protection class attributes
# kSecAttrAccessibleWhenUnlocked - OK for most data
# kSecAttrAccessibleAlways - VULNERABLE: accessible even when locked
# kSecAttrAccessibleAfterFirstUnlock - acceptable for background apps

Step 5: Assess External Storage and Backup Exposure

Android:

# Check if backup is enabled
aapt dump badging target.apk | grep -i "allowBackup"
# android:allowBackup="true" = vulnerability

# Extract backup data
adb backup -f backup.ab -apk <package_name>
java -jar abe.jar unpack backup.ab backup.tar
tar xvf backup.tar
# Inspect extracted data for sensitive information

# Check external storage
adb shell ls -la /sdcard/Android/data/<package_name>/

iOS:

# Check backup exclusion
# Files in Documents/ are backed up by default
# Check NSURLIsExcludedFromBackupKey attribute
objection --gadget com.target.app explore
ios plist cat Info.plist

Step 6: Runtime Memory Analysis

# Dump process memory for sensitive data
objection --gadget com.target.app explore
memory search "password" --string
memory search "BEGIN RSA PRIVATE KEY" --string
memory dump all /tmp/memdump/

# Android: Check for sensitive data in logs
adb logcat -d | grep -i "password\|token\|key\|secret"

Key Concepts

Tools & Systems

• ADB (Android Debug Bridge): Command-line tool for Android device interaction and filesystem access
• Objection: Frida-powered runtime exploration for keychain dumping and memory inspection
• SQLite3: Command-line interface for inspecting unencrypted SQLite databases
• Android Backup Extractor (ABE): Tool for unpacking ADB backup files to inspect stored data
• iExplorer: GUI tool for browsing iOS app sandbox filesystem

Common Pitfalls

• Encrypted but key in code: Some apps encrypt databases but store the encryption key in SharedPreferences or hardcoded in the binary. Always check for key storage alongside encryption.
• MODE_WORLD_READABLE deprecation: This flag was deprecated in API 17, but legacy apps may still use it, making SharedPreferences readable by other apps.
• iOS backup scope: By default, all files in the Documents directory are included in iTunes/iCloud backups. Verify that sensitive files have the backup exclusion attribute set.
• Clipboard exposure: Data copied to clipboard is accessible to all apps. Check if the app copies sensitive data (passwords, tokens) to the clipboard.