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)

Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.

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.

Source: mukul975/Anthropic-Cybersecurity-Skills → skills/exploiting-insecure-data-storage-in-mobile/SKILL.md