CVE-2023-6960

Executive Summary

CVE-2023-6960 describes a critical security flaw in the TTLock ecosystem. The vulnerability lies in the TTLock mobile application's handling of virtual keys and lock settings. When a user deletes a virtual key or changes lock settings via the app, the deletion or change is only performed on the client side (the mobile device). The server-side data is not invalidated or removed. This means that if an attacker can obtain a preserved copy of the virtual key or settings data (e.g., from a device backup, a compromised phone, or network interception), they can continue to access the lock even after the intended deletion by the legitimate owner. This effectively renders the "delete" function useless and creates a persistent, unauthorized access vector.

Supply Chain & Package Security

This vulnerability is not related to an open-source package (NPM, PyPI, Go, Ruby). It is a proprietary mobile application (TTLock App) and its associated cloud backend. The supply chain risk is primarily to end-users who rely on the TTLock system for physical security. The lack of a patch or vendor acknowledgment means that all users of the TTLock App are potentially affected.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or an error in the NVD data. Based on the vulnerability description, a more accurate score would be calculated as follows:

• Attack Vector (AV): Network (the attacker can exploit this remotely if they have the preserved key data)
• Attack Complexity (AC): Low (no special conditions required beyond obtaining the key data)
• Privileges Required (PR): Low (the attacker needs to have obtained the key data, but no further authentication is needed to use it)
• User Interaction (UI): None (the victim does not need to perform any action for the exploit to succeed once the key is obtained)
• Scope (S): Changed (the vulnerable component is the app, but the impact is on the physical lock)
• Confidentiality (C): High (unauthorized access to a physical space)
• Integrity (I): High (the attacker can potentially change lock settings)
• Availability (A): Low (the attacker could potentially lock out the legitimate user)

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L Estimated Score: 8.6 (High)

Threat Level: High. The vulnerability undermines the core security promise of a smart lock system. The persistence of deleted keys creates a significant risk of unauthorized physical access.

Deep Dive & Mechanics

The core issue is a client-side only deletion mechanism. The TTLock App likely stores virtual keys and lock settings in a local database (e.g., SQLite, Realm) or shared preferences on the mobile device. When a user initiates a "delete" operation:

1. Client-Side Action: The app removes the key or setting from its local storage.
2. Server-Side Action (Missing): The app does not send a command to the TTLock cloud backend to invalidate the key on the server or to push a revocation command to the physical lock.

The physical lock itself likely has a list of authorized keys stored in its firmware. The lock does not receive a "key revoked" message. Therefore, any key that was ever authorized remains authorized on the lock until the lock's firmware is updated or the key is explicitly revoked via a server-side command.

An attacker can exploit this by:

1. Obtaining a Backup: Gaining access to a device backup (e.g., iCloud, Google Drive, local backup) that contains the app's data.
2. Compromising the Device: Having access to the victim's unlocked phone.
3. Network Interception: Intercepting the initial key provisioning process (though this is more complex).

Once the attacker has the virtual key data (e.g., a key ID, a cryptographic token, or a shared secret), they can install the TTLock App on their own device, import the key data, and use it to unlock the lock. The lock will accept the key because it has never been told to revoke it.

Vulnerable vs. Patched Code

No specific code is available for this proprietary application. The vulnerability is a design flaw, not a code-level bug.

Vulnerable Behavior:

• The app's deleteKey() function only removes the key from the local database.
• The app does not call a server API like POST /api/v1/keys/revoke or send a BLE command to the lock to remove the key.

Patched Behavior (Hypothetical):

• The app's deleteKey() function would:
  1. Send a DELETE /api/v1/keys/{keyId} request to the TTLock cloud server.
  2. The server would mark the key as revoked in its database.
  3. The server would push a notification to the lock (via the cloud-to-lock communication channel) to remove the key from its authorized list.
  4. Only after successful server-side revocation would the app remove the key from its local storage.

Exploitation & Lab Setup

Red Team (Exploitation)

Objective: Gain unauthorized physical access to a TTLock-protected door.

Prerequisites:

• A TTLock App backup file from the victim's device (e.g., TTLockBackup.db).
• A rooted/jailbroken Android/iOS device or an emulator.
• The TTLock App installed on the attacker's device.

Steps:

1. Obtain Backup: Acquire the victim's TTLock App data. On Android, this might be in /data/data/com.ttlock.app/databases/. On iOS, it would be in the app's Documents directory.
2. Extract Keys: Analyze the backup file. Look for tables or files containing virtual_key, lock_key, or similar. The key data is likely a string or a blob.
3. Import Key: On the attacker's device, replace the local database with the extracted one, or use a tool to inject the key data into the app's storage.
4. Access Lock: Open the TTLock App. The imported key should appear. Use the app to unlock the door.

Example (Conceptual - Android):

# On victim's device (rooted)
adb pull /data/data/com.ttlock.app/databases/ttlock.db

# On attacker's device (rooted)
adb push ttlock.db /data/data/com.ttlock.app/databases/
adb shell am start -n com.ttlock.app/.MainActivity

Blue Team (Defense & Detection)

Objective: Detect and prevent the exploitation of this vulnerability.

Detection:

• Monitor for Unusual Key Usage: Log all unlock events on the TTLock cloud backend. Flag any key that is used after its reported deletion time.
• Device Integrity Checks: Implement a mechanism on the lock to periodically check with the cloud for a list of revoked keys. If a key is used that is not on the current authorized list, trigger an alert.
• User Education: Advise users to change the lock's master password and re-pair all keys after any suspected compromise. This forces a full key rotation.

Prevention:

• Vendor Action: The vendor (TTLock) must implement server-side key revocation. This is the only true fix.
• User Workaround: Users should not rely on the "delete" function. Instead, they should change the lock's admin password and re-invite all legitimate users. This effectively creates a new set of keys and invalidates the old ones.

Indicators of Compromise (IOCs)

• Network Traffic: Anomalous BLE (Bluetooth Low Energy) unlock commands from a device that is not the legitimate owner's.
• Cloud Logs: Unlock events associated with a key ID that was previously deleted.
• Device Artifacts: Presence of a TTLock App backup file on a device that is not the primary user's.
• File Hashes (Example): The hash of the TTLock App database file (e.g., ttlock.db) may be used to identify compromised backups. (Note: This is highly version-specific and not a reliable IOC.)

Detection Engineering

YARA Rule

rule TTLock_VirtualKey_Persistence {
    meta:
        description = "Detects TTLock App database files that may contain preserved virtual keys"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2023-6960"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $sqlite_header = "SQLite format 3"
        $key_table = "CREATE TABLE virtual_key"
        $key_data = "key_id"
    condition:
        $sqlite_header at 0 and $key_table and $key_data
}

Sigma Rule

title: TTLock Virtual Key Deletion Bypass
id: 8c5a2f3b-1e2d-4a7c-9b8f-6e3d2a1c0b5a
status: experimental
description: Detects potential exploitation of CVE-2023-6960 by monitoring for unlock events using keys that were previously deleted.
author: Valters IT
date: 2024-01-01
logsource:
    product: ttloud
    service: unlock_events
detection:
    selection:
        EventID: "UNLOCK_SUCCESS"
        KeyStatus: "DELETED"
    condition: selection
falsepositives:
    - Legitimate key re-import after accidental deletion
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TTLOCK Potential Key Exfiltration - Backup Download"; flow:to_server,established; content:"GET"; http_method; content:"/api/v1/backup"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation (Users):

1. Change Master Password: Change the lock's master password via the TTLock App. This will invalidate all existing keys.
2. Re-invite Users: Delete all users and re-invite them. This forces the creation of new keys.
3. Monitor Lock Activity: Regularly check the lock's activity log for any unauthorized access.
4. Disable Remote Access: If possible, disable the lock's remote access feature until a patch is available.

Long-Term Remediation (Vendor):

1. Implement Server-Side Revocation: The TTLock cloud backend must be updated to handle key deletion requests. When a user deletes a key, the server must mark it as revoked and push a revocation command to the lock.
2. Force App Update: Release a mandatory app update that enforces the new server-side revocation logic.
3. Security Audit: Conduct a full security audit of the app's data handling and synchronization logic.

Valters IT