Chapter 34 Quiz: Mobile & IoT Security¶

C — M9: Insecure Data Storage

OWASP Mobile M9 (Insecure Data Storage) covers scenarios where sensitive data is stored in insecure locations accessible to other apps or attackers with device access: SharedPreferences, SQLite databases, log files, SD card, or app cache. The Android Keystore system should be used for cryptographic keys and sensitive credentials. Plaintext tokens in SharedPreferences are readable by any app with root access.

B — Mobile Application Management (MAM) — manage and protect only the corporate apps and data container, without controlling the personal device

MAM (also called app-level management or containerization) allows the organization to manage corporate apps and the data within them without enrolling the personal device into MDM. The corporate data container is encrypted, can be remotely wiped independently of the device, and enforces copy/paste restrictions between work and personal apps. Full MDM on personal devices raises privacy concerns and legal issues in many jurisdictions.

B — iOS uses a mandatory App Store review process and code signing enforced by Apple; Android allows sideloading (installation from unknown sources) with user permission

iOS enforces a closed ecosystem: all apps must be notarized and signed by Apple; sideloading (outside TestFlight/MDM enterprise profiles) is restricted. Android allows APK sideloading from unknown sources with user acknowledgment. Both platforms use application sandboxing to isolate apps from each other, but Android's openness increases exposure to malicious APK distribution. Android enterprise features (Work Profile) can restrict sideloading on corporate devices.

B — Default and Hardcoded Credentials

Hardcoded and default credentials are one of the most pervasive and exploited IoT vulnerabilities (OWASP IoT Top 10: I1). The Mirai botnet infected hundreds of thousands of IoT devices by scanning for default credentials. Hardcoded credentials cannot be changed by the user — firmware updates are required to fix them. MQTT without TLS and with weak credentials enables eavesdropping on sensitive telemetry (patient data in this case, creating HIPAA implications).

B — Deploy IoT devices on a dedicated isolated VLAN/network segment with a firewall enforcing strict whitelisted communication rules to a purpose-built IoT gateway

IoT network segmentation places OT/IoT devices on a dedicated network segment, isolated from the corporate LAN. A firewall enforces allow-list rules: IoT devices can only communicate with their specific management/telemetry gateway — not with each other (east-west blocked) or the internet (direct). MAC filtering (C) and static IPs (D) are trivially bypassed and do not provide real isolation.

C — Physical attack surface — exposed debug interfaces (JTAG, UART, ICSP)

Manufacturing debug interfaces (UART, JTAG, SWD, ICSP) left active and accessible on production hardware expose a physical attack surface. An attacker with physical access can extract firmware, inject code, or obtain a root shell. Mitigations include: disabling or destroying debug interfaces in production firmware, requiring authentication on debug ports, and using secure boot. Physical attacks are often overlooked in IoT security modeling.

B — Enable TLS on port 8883, require client certificate authentication, and implement topic-level ACLs to restrict what each device can publish/subscribe to

MQTT security best practices: TLS encryption (port 8883 vs. plaintext 1883), client certificate authentication (prevents unauthorized devices from connecting), and topic-level ACLs (device01 can only publish to devices/device01/telemetry, not subscribe to other devices' topics). Without these controls, any device on the network can read all telemetry and publish arbitrary commands to any actuator.

B — Certificate pinning is effective against network-based MitM attacks but can be bypassed by attackers with root/jailbreak access who can instrument the app's runtime

Certificate pinning prevents network-level MitM (e.g., a corporate proxy or attacker inserting their certificate). However, on a rooted/jailbroken device, dynamic instrumentation tools (Frida, Objection) can hook the app's runtime and override the pin validation logic. This is a known limitation: pinning protects against passive network interception but not against an attacker who controls the device. Defense-in-depth (obfuscation, anti-tampering, root detection) reduces but does not eliminate this risk.

B — Isolate the device from the network (airplane mode / Faraday bag) to prevent remote wipe, then perform a logical or filesystem acquisition using a mobile forensics tool

The first preservation priority in mobile IR is network isolation — an MDM or remote wipe command sent before acquisition destroys evidence. Airplane mode disconnects cellular and Wi-Fi; a Faraday bag provides RF shielding. After isolation, use a validated mobile forensics tool (Cellebrite UFED, Oxygen Forensics, GrayKey) for acquisition. Factory reset (A) is evidence destruction. Rebooting (C) may alter volatile state.

B — A fitness tracking app collects precise GPS location in the background and shares it with third-party advertising SDKs without user consent or disclosure in the privacy policy

OWASP Mobile M6 (Inadequate Privacy Controls) covers scenarios where apps collect, process, or share personal data in ways that violate user expectations or privacy regulations (GDPR, CCPA). Covert GPS collection and undisclosed third-party data sharing is a textbook M6 violation. It also creates regulatory liability. M9 covers insecure storage (A), M5 covers insecure communication (C), and M4 covers input validation (D).