CVE-2018-15002 in Vivo
Summary
by MITRE
The Vivo V7 device with a build fingerprint of vivo/1718/1718:7.1.2/N2G47H/compil11021857:user/release-keys allows any app co-located on the device to set system properties as the com.android.phone user. The com.qualcomm.qti.modemtestmode app (versionCode=25, versionName=7.1.2) that contains an exported service named com.qualcomm.qti.modemtestmode.MbnTestService that allows any app co-located on the device to provide key-value pairs to set certain system properties. Notably, system properties with the persist.* prefix can be set which will survive a reboot. On the Vivo V7 device, when the persist.sys.input.log property is set to have a value of yes, the user's screen touches be written to the logcat log by the InputDispatcher for all apps. The system-wide logcat log can be obtained from external storage via a different known vulnerability on the device. The READ_EXTERNAL_STORAGE permission is necessary to access the log files containing the user's touch coordinates. With some effort, the user's touch coordinates can be mapped to key presses on a keyboard.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 04/24/2020
This vulnerability exists within the Vivo V7 smartphone running Android 7.1.2 and demonstrates a critical privilege escalation flaw that allows any locally installed application to manipulate system properties with elevated permissions. The vulnerability stems from an exported service named com.qualcomm.qti.modemtestmode.MbnTestService within the com.qualcomm.qti.modemtestmode application which operates with version code 25 and version name 7.1.2. This service exposes functionality that permits arbitrary apps co-located on the device to set key-value pairs for specific system properties, effectively bypassing normal Android permission boundaries and allowing unauthorized modification of system-level configurations.
The technical flaw specifically involves the exposure of system properties with the persist.* prefix which are designed to persist across device reboots and maintain their values in the system configuration. The vulnerability becomes particularly dangerous when the persist.sys.input.log property is set to "yes" as this configuration triggers the InputDispatcher component to log all user touch events to the logcat system log. This behavior creates a direct pathway for sensitive user interaction data to be captured and potentially exploited, as the logcat output contains detailed information about screen touch coordinates and user interactions that can be leveraged for malicious purposes.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass comprehensive user privacy and security compromise. Attackers can exploit this flaw to monitor and record all user touch interactions, effectively creating a persistent surveillance mechanism that operates across all applications on the device. The ability to map touch coordinates to keyboard key presses through the logcat data enables sophisticated attack vectors including keystroke logging, user behavior analysis, and potential credential harvesting. The vulnerability's exploitation requires only local app installation and the READ_EXTERNAL_STORAGE permission to access the log files, making it particularly dangerous as it can be triggered without requiring elevated privileges or network access.
This vulnerability aligns with CWE-276, which addresses improper privileges, and represents a classic example of insecure service exposure in mobile operating systems. The attack pattern follows the ATT&CK framework's privilege escalation techniques, specifically targeting the "Service Execution" and "Input Capture" domains. The security implications are further compounded by the fact that the persist.* system properties maintain their values across reboots, creating a persistent backdoor that survives device restarts and can be exploited for long-term surveillance. The vulnerability demonstrates the critical importance of proper Android service permission management and highlights the dangers of exposing system-level configuration interfaces to untrusted applications within the device's local execution environment.
Mitigation strategies should focus on restricting access to system properties and implementing proper service exposure controls within the Android framework. Device manufacturers should ensure that only authorized applications can modify persist.* system properties, and that services exposing system configuration interfaces require proper authentication and authorization mechanisms. Security researchers recommend implementing additional checks within the InputDispatcher component to prevent unauthorized logging of user interaction data, while system administrators should monitor for unauthorized access to system properties and implement proper application sandboxing to prevent local privilege escalation attacks. The vulnerability also underscores the necessity of regular security audits of Android system services and the importance of proper permission model enforcement in mobile operating systems to prevent similar exposure scenarios.