7.0 Mobile Platform, IoT, and OT Hacking CEH Practice Quiz

• A. M2: Insecure Data Storage
• B. M1: Improper Platform Usage
• C. M3: Insecure Communication
• D. M5: Insufficient Cryptography

OWASP Mobile Top 10 M2 (Insecure Data Storage) covers vulnerabilities where apps store sensitive data in insecure locations, including Android's SharedPreferences (XML files readable by any root process), NSUserDefaults (iOS plist files), SQLite databases without encryption, device logs, and external storage. Attackers who root/jailbreak the device or use forensic tools can extract this data trivially.

• A. SQL injection through the mobile API endpoint bypassing server-side input validation
• B. Reverse engineering of the app's business logic by decompiling the APK with jadx
• C. Man-in-the-middle interception of TLS traffic using a proxy with a CA certificate trusted by the device OS
• D. Privilege escalation on rooted devices that access the app's internal storage directory

Without certificate pinning, the app accepts any TLS certificate that chains to a trusted CA. If an attacker or tester installs a custom CA on the test device (e.g., Burp Suite's CA) and runs a proxy, the app trusts the proxy's certificate. The proxy decrypts, inspects, and re-encrypts all HTTPS traffic. Certificate pinning prevents this by requiring the server's certificate to match a specific hardcoded value, rejecting any certificate, even one from a trusted CA, that doesn't match.

• A. M2: Insecure Data Storage, the token is stored insecurely in transit
• B. M3: Insecure Communication, sensitive data transmitted without adequate transport security
• C. M7: Client Code Quality, the developer used an insecure HTTP library function
• D. M9: Reverse Engineering, attackers can extract the token format from the binary

OWASP Mobile M3 (Insecure Communication) directly covers this scenario: any transmission of sensitive data (authentication tokens, credentials, PII) over unencrypted channels (HTTP instead of HTTPS), with improper TLS configuration, or without certificate validation. Transmitting tokens in plain HTTP exposes them to passive sniffing on the same network (coffee shop Wi-Fi, rogue AP, ISP surveillance).

• A. Apple DEP / Android Zero Touch, fully corporate-manages the device from factory enrollment
• B. BYOD enrollment with containerization, corporate apps are isolated in a managed container while personal data remains separate and private
• C. Corporate-owned personally enabled (COPE), company owns the device but allows personal use
• D. Certificate-based enrollment, uses PKI client certificates to authenticate devices to the MDM server

BYOD (Bring Your Own Device) enrollment with containerization (e.g., Samsung Knox, Microsoft Intune with Android Work Profile, or Apple Managed Open-In) creates a secure corporate container on the employee's personal device. Corporate apps, email, and data reside in the managed container (encrypted separately, under IT control), while personal apps and data remain outside IT's reach. IT can wipe the corporate container without affecting personal photos, messages, or apps.

• A. CIS Mobile Device Security Benchmark
• B. OWASP Mobile Application Security Verification Standard (MASVS)
• C. NIST Mobile Threat Catalogue (NIST IR 8144)
• D. PCI DSS Mobile Payment Acceptance Security Guidelines

OWASP MASVS (Mobile Application Security Verification Standard) defines security requirements for mobile app developers and security testers in three levels: L1 (standard security, required for all apps), L2 (defense-in-depth requiring additional controls for sensitive apps like banking), and R (resilience requirements for apps needing protection against reverse engineering). Its companion guide, the OWASP MASTG (Mobile Application Security Testing Guide), provides detailed testing procedures for each MASVS requirement.

• A. The iOS Keychain is not encrypted, kSecAttrAccessibleAlways items are stored in plaintext accessible to any installed app
• B. OAuth2 tokens stored with kSecAttrAccessibleAlways are automatically shared with all apps signed by the same developer Team ID
• C. kSecAttrAccessibleAlways causes tokens to expire immediately when the device screen locks, breaking the user session
• D. kSecAttrAccessibleAlways allows keychain item access even when the device is locked, a stolen device, forensic extraction tool, or malware active during device lock can access the tokens without the user's passcode

kSecAttrAccessibleAlways (or kSecAttrAccessibleAlwaysThisDeviceOnly) makes keychain items available without requiring the device passcode or biometric authentication. This means a forensic tool (like Cellebrite or GrayKey) can extract these tokens even from a locked device if it can exploit an iOS vulnerability to access the keychain. kSecAttrAccessibleWhenUnlockedThisDeviceOnly restricts access to times when the device has been unlocked since last boot, significantly reducing the window of exposure. Sensitive tokens should use the most restrictive accessibility attribute consistent with the app's UX requirements.

• A. Drozer decompiles and de-obfuscates ProGuard-protected Android APK bytecode for source code review
• B. Drozer analyzes Android network traffic as a transparent HTTP/HTTPS proxy between the app and its backend
• C. Drozer performs GPU-accelerated brute-force attacks against encrypted Android SQLite database files
• D. Drozer interacts with live running Android IPC components, testing exported Activities, ContentProviders, Services, and BroadcastReceivers for unauthorized access, data leakage, and privilege escalation at runtime

Drozer is the industry-standard tool for testing Android IPC (Inter-Process Communication) attack surfaces. Using Drozer's agent installed on the device, a tester can: enumerate all exported app components (dz> run app.package.attacksurface), query ContentProviders directly without being the intended app (dz> run app.provider.query), send malicious Intents to exported Activities or Services, and test for path traversal in content URI handling. This dynamic, runtime testing reveals vulnerabilities that static analysis alone cannot confirm because IPC behavior depends on runtime conditions.

• A. adb install malicious.apk, installs a malicious app silently on the target device
• B. adb backup -all -apk -f device_backup.ab, creates a backup archive of all apps and their associated data
• C. adb shell pm list packages -f, lists all installed app package names and their APK file paths
• D. adb logcat -d > logfile.txt, dumps the Android system log buffer to a file on the attacker's computer

adb backup -all -apk -f device_backup.ab creates a compressed backup archive containing all apps' data (with -all) and their APK files (with -apk). The resulting .ab file can be converted to a .tar archive using Android Backup Extractor, then explored to find SharedPreferences XML files, SQLite databases, saved tokens, and other sensitive app data, all in a single command without needing to root the device.