CVE-2023-7007
Description
Sciener server fails to validate GatewayG2 connections, allowing an attacker to impersonate the gateway and obtain the unlockKey for any associated lock.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Sciener server fails to validate GatewayG2 connections, allowing an attacker to impersonate the gateway and obtain the unlockKey for any associated lock.
Vulnerability
Overview
The Sciener server does not validate connection requests from the GatewayG2 peripheral, enabling a network-level impersonation attack. An attacker who can position themselves between the GatewayG2 and the server can present themselves as a legitimate gateway. The server will accept this fake connection and subsequently transmit the unlockKey field to the attacker [1][2]. This is a fundamental flaw in the server-side authentication of gateway devices.
Exploitation
No authentication or prior access to the lock is required; the attacker only needs network access to the path between the GatewayG2 and the Sciener cloud. By spoofing the gateway's identity during the initial handshake, the server is tricked into providing the unlockKey. This key is a critical secret that the lock uses to authorize unlock commands [2].
Impact
With the unlockKey, the attacker can issue commands to the lock (e.g., unlock, lock) as if they were an authorized user. The lock itself does not distinguish between a legitimate gateway and an attacker who holds the key. This compromises the physical security of any door or property using the affected Sciener locks, Gateways, and the TTLock application [1][2].
Mitigation
As of the publication date (2024-03-15), Sciener has not released a patch for this server-side validation issue. The vulnerability has been reported through CERT/CC and coordinated disclosure. Until a fix is deployed, organizations should consider the risk of deploying GatewayG2 devices in untrusted network segments [1][2].
AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The Sciener server does not validate that a reconnecting gateway is the same physical device as the originally registered gateway, allowing an attacker to replace the gateway's encryption key and hijack the connection."
Attack vector
An attacker who knows a registered gateway's MAC address can impersonate that gateway by connecting to the Sciener server and sending a new generated AES key (GAK) encrypted with the hardcoded AES key (HAK). The server accepts the key replacement and routes subsequent lock-bound messages through the attacker's connection. This allows the attacker to perform a BLE MITM attack against the lock, including coercing the TTLock app to downgrade the protocol version and expose the unlockKey value. With the unlockKey, the attacker can then brute-force the 16-bit challenge (1/65,536 chance per attempt) while keeping the connection open, sending ~30 attempts per second, guaranteeing lock opening within ~40 minutes (median ~20 minutes) [ref_id=1].
Affected code
The vulnerability is in the Sciener server's gateway initialization logic. When a gateway reconnects, the server does not validate whether the connection request comes from the same physical gateway that was previously registered. Instead, it accepts any new gateway key (GAK) sent encrypted with the hardcoded key (HAK) for a given MAC address, and switches to using the most recent connection for that MAC.
What the fix does
The advisory does not specify a patch or remediation. The vulnerability stems from the server's failure to validate that a reconnecting gateway is the same physical device that was originally registered. A proper fix would require the server to authenticate reconnection attempts using the previously established GAK rather than accepting a new GAK encrypted only with the hardcoded HAK, or to bind the gateway identity to a cryptographic credential that cannot be replaced by a third party [ref_id=1].
Preconditions
- inputAttacker must know the MAC address of a gateway already registered with the Sciener server
- networkAttacker must be able to connect to the Sciener server over the network
- networkAttacker must have physical proximity to the target lock for the BLE MITM phase
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.