312-50 Question 393
Single answer▪ Mobile Platform Attack VectorsDuring an authorized assessment of a company's Android mobile application, you discover that the app stores an OAuth access token in a world-readable location on external storage. The app also has the android:debuggable flag enabled in the production build. Which attack vector would MOST directly allow another malicious app on the same device to abuse the victim's authenticated session without first exploiting the Android kernel or obtaining root access?
- A
A malicious app reads the token from external storage and reuses it to call the backend API as the victim user
- B
A malicious app performs a baseband firmware downgrade to intercept the token before the app encrypts it
- C
A malicious app modifies SELinux policy at runtime to gain access to the app's private internal storage
- D
A malicious app uses NFC tag emulation to overwrite the token in the victim app's process memory
Show answer and explanation
Correct answer: A
Explanation
The best answer is the malicious app reading the OAuth token from external/shared storage and reusing it. This is a classic mobile platform attack vector: insecure storage of sensitive data. On Android, app-private internal storage is sandboxed per application, while shared/external storage has historically been accessible beyond a single app boundary depending on platform version, permissions, and storage model. Storing bearer tokens there can enable session hijacking because OAuth access tokens are often sufficient on their own to authenticate API requests.
The android:debuggable flag in a production build is also a significant security issue because it can expose the app to debugging and analysis risks, especially on development-enabled devices. However, the scenario asks for the most direct way another malicious app could abuse the authenticated session without root or kernel compromise. Reading a token from insecure storage and replaying it is the straightforward answer.
This aligns with common mobile security guidance from Android security best practices and OWASP Mobile Application Security guidance: sensitive credentials, tokens, and secrets should not be stored in shared/external storage; instead, use app-private storage and platform-backed protections such as Android Keystore where appropriate. In CEH terms, this tests understanding of mobile platform attack vectors involving insecure data storage, local malicious applications, and credential/token abuse in realistic enterprise app assessments.
- A. Correct.
Correct. On Android, data placed on external/shared storage is not protected like app-private internal storage. If a sensitive OAuth bearer token is stored in a world-readable location, another app with appropriate storage access can read it and replay it against the backend API. This is a direct mobile platform attack vector involving insecure local data storage and token theft. The debuggable flag is also a serious weakness, but in this scenario the token exposure on shared storage is the most direct path for another app to abuse the session without root or kernel exploitation.
- B. Incorrect.
Incorrect. A baseband firmware downgrade is highly specialized and not the most direct or realistic way for a local malicious app to steal an already stored token. It also targets cellular modem components rather than normal application-layer token storage. The scenario specifically asks for the attack vector that another app on the same device could use directly without advanced low-level compromise.
- C. Incorrect.
Incorrect. Modifying SELinux policy at runtime generally requires elevated privileges or a rooted/compromised device. The question explicitly excludes attacks that require kernel exploitation or root access. While SELinux bypasses can matter in advanced attacks, they are not the most direct or feasible method here.
- D. Incorrect.
Incorrect. NFC tag emulation does not provide a standard mechanism to overwrite another app's process memory. This option mixes unrelated mobile features with process-memory tampering. Process memory manipulation of another app would typically require debugging privileges, code injection, or platform compromise, not ordinary NFC capabilities.