Overview

Sciener is a company that develops software and hardware for electronic locks that are marketed under many different brands. Their hardware works in tandem with an app, called the TTLock app, which is also produced by Sciener. The TTLock app utilizes Bluetooth connections to connect to locks that utilize the Sciener firmware, and allows for manipulation of the lock. Sceiner firmware locks also supports peripherals. The GatewayG2, also produced by Sciener, allows for connection to an appropriate lock through the TTLock app through WiFi. Sciener firmware also allows wireless keypad connection to supported devices.

Analysis has revealed that various locks are vulnerable through the Sciener firmware. Additional vulnerabilities within the TTLock App and GatewayG2 can be further utilized to compromise the associated electronic lock integrity, and affect any locks that utilize them.

A number of these vulnerabilities are facilitated through the unlockKey character. The unlockKey character, when provided to the appropriate lock, can be used to unlock or lock the device.

Description

The vulnerabilities are as follows:

• CVE-2023-7006

The unlockKey character in a lock using Sciener firmware can be brute forced through repeated challenge requests, compromising the locks integrity. Challenge requests take place during the unlocking process, and contain a random integer between 0 and 65535. Challenge requests can be repeatedly prompted and responded to without any limitations, until the correct integer is discovered. Successfully completing the challenge request provides the unlockKey character.

• CVE-2023-7005

A specially crafted message can be sent to the TTLock App that downgrades the encryption protocol used for communication and can be utilized to compromise the lock, such as by providing the unlockKey character. During the challenge request process, if a message is sent to the lock unencrypted, and with a specific set of information, the corresponding message that contains the unlockKey character will be provided unencrypted.

• CVE-2023-7003

The AES key utilized in the pairing process between a lock using Sciener firmware and a wireless keypad is not unique, and can be reused compromise other locks using the Sciener firmware. This AES key can be utilized to connect to any other Sciener lock that supports wireless keypads, without user knowledge or interaction.

• CVE-2023-6960

The TTLock App supports the creation of virtual keys and settings. They virtual keys are intended to be distributed to other individuals through the TTLock app, for unlocking and locking the lock. They can also be set to only be valid for a certain period of time. Deletion of these keys only occurs client side in the TTLock app, with the appropriate key information persisting within the associated lock. If an attacker acquires one of these keys, they can utilize it to unlock the lock after its intended deletion or invalidation.

• CVE-2023-7004

The TTLock App does not employ proper verification procedures to ensure that it is communicating with the expected device. This can be utilized by a threat actor who introduces a device that spoofs the MAC address of the lock, allowing for compromise of the unlockKey value.

• CVE-2023-7007

The Sciener server does not validate connection requests from the GatewayG2, allowing an impersonation attack. An attacker can impersonate the MAC address of a GatewayG2 that has established a connection with a lock, then connect to Sciener servers and receive messages instead of the legitimate GatewayG2. This can facilitate access of the unlockKey character.

• CVE-2023-7009

Some Sciener-based locks support plaintext message processing over Bluetooth Low Energy, allowing unencrypted malicious commands to be passed to the lock. These malicious commands, less then 16 bytes in length, will be processed by the lock as if they were encrypted communications. This can be further exploited by an attacker to compromise the lock's integrity.

• CVE-2023-7017

Some Sciener locks' firmware update mechanism does not authenticate or validate firmware updates if passed to the lock through the Bluetooth Low Energy service. A challenge request can be sent to the lock with a command to prepare for an update, rather than an unlock request. This allows an attacker within Bluetooth range to pass an arbitrary malicious firmware to the lock, compromising its integrity.

Impact

These vulnerabilities allow attackers with physical, adjacent, or Bluetooth connection proximity to the lock access of various capabilities to compromise the lock integrity, without victim knowledge or interaction. This results in the locks functionality being null.

Affected versions:

Kontrol Lux lock, firmware versions 6.5.x to 6.5.07Gateway G2, firmware version 6.0.0TTLock App, version 6.4.5

Solution

There is no software solution for these vulnerabilities, only a potential work-around. By disabling various functions related to the Bluetooth capability of locks using Sciener firmware, several of the attacks can be prevented. However, as the locks are designed with the intention of utilization with the TTLock App, this may not be a practical solution for most users.

Acknowledgements

Thanks to Lev Aronsky, Idan Strovinsky, and Tomer Telem of Aleph Research by HCL Software for providing the report and information. This document was written by Christopher Cullen.

Vendor Information

References

https://alephsecurity.com/2024/02/20/kontrol-lux-lock-1/ https://alephsecurity.com/2024/03/07/kontrol-lux-lock-2/