CVE-2022-32506

Executive Summary

CVE-2022-32506 is a critical physical access vulnerability affecting Nuki Home Solutions smart lock and bridge devices. An attacker with physical access to the device's circuit board can abuse the Serial Wire Debug (SWD) interface to gain full control over the processor, debug firmware, and read or modify both internal and external flash memory. This allows for permanent compromise of the device, including extraction of cryptographic keys, modification of lock behavior, and installation of persistent backdoors. The vulnerability stems from the lack of debug interface protection (e.g., JTAG/SWD lock) on production devices. No public exploit code or proof-of-concept is currently available, but the attack vector is well-understood in hardware security research.

Supply Chain & Package Security

This vulnerability is not related to software supply chain or package management (NPM, PyPI, Go, Ruby). It is a hardware-level issue requiring physical access to the device PCB.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (No official vector assigned by NVD) Threat Level: High (Physical Access Required)

Rationale: While the CVSS score is 0.0 due to lack of official scoring, the vulnerability is severe because it allows complete compromise of the device's firmware and data. The attack requires physical access, which limits the attack surface but makes it extremely dangerous for targeted attacks against high-value locations (e.g., corporate offices, luxury residences).

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

• Attack Vector: Physical (requires access to circuit board)
• Attack Complexity: Low (standard SWD debug tools)
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality: High (full flash read)
• Integrity: High (full flash write)
• Availability: High (can brick device)

Deep Dive & Mechanics

The vulnerability exploits the Serial Wire Debug (SWD) interface, a two-pin debug protocol used by ARM Cortex-M processors. On Nuki devices, the SWD pins (SWDIO and SWCLK) are exposed on the circuit board without any protection mechanism (e.g., debug authentication, password, or physical fuses). An attacker can connect a standard SWD debugger (e.g., J-Link, ST-Link, or a Raspberry Pi with OpenOCD) to these pins and:

1. Halt the processor – Stop execution of the current firmware.
2. Read flash memory – Dump the entire firmware, including cryptographic keys, Wi-Fi credentials, and lock pairing secrets.
3. Write flash memory – Modify the firmware to bypass authentication, change lock behavior, or install a backdoor.
4. Debug firmware – Step through code, set breakpoints, and analyze runtime behavior.

The attack does not require any software exploit or network access. It is a pure hardware-level compromise.

Affected Components:

• Nuki Smart Lock 3.0 (firmware < 3.3.5)
• Nuki Smart Lock 2.0 (firmware < 2.12.4)
• Nuki Bridge v1 (firmware < 1.22.0)
• Nuki Bridge v2 (firmware < 2.13.2)

Root Cause: The manufacturer did not implement SWD/JTAG lock bits or debug authentication in the production firmware. This is a common oversight in IoT devices where debug interfaces are left enabled for manufacturing but not disabled for end users.

Vulnerable vs. Patched Code

Since this is a hardware-level vulnerability, there is no "code diff" in the traditional sense. The fix involves enabling the SWD lock mechanism in the microcontroller's option bytes or using a debug authentication mechanism.

Vulnerable Configuration:

• SWD interface enabled and unlocked
• Debug authentication not implemented
• No physical tamper detection on debug pins

Patched Configuration (firmware >= patched versions):

• SWD interface locked via option bytes (cannot be accessed without erasing the chip)
• Debug authentication implemented (requires a secret key to unlock debug)
• Physical tamper detection may be added to erase sensitive data if debug pins are accessed

Example of Locking SWD on STM32 (common MCU in Nuki devices):

// This code would be executed during boot to lock SWD
HAL_StatusTypeDef ret;
uint32_t option_byte = 0;
option_byte = READ_REG(FLASH->OPTR);
option_byte |= FLASH_OPTR_SWD_SWITCH; // Disable SWD
HAL_FLASH_OB_Unlock();
HAL_FLASH_OB_Program(FLASH_OB_OPTION_BYTES, option_byte);
HAL_FLASH_OB_Lock();
HAL_FLASH_OB_Launch(); // Reboot to apply

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Physical access to the Nuki device (Smart Lock or Bridge)
• Screwdriver to open the device casing
• SWD debugger (e.g., ST-Link V2, J-Link EDU, or Raspberry Pi Pico with OpenOCD)
• Computer with OpenOCD and GDB installed

Steps:

1. Open the device – Remove screws and carefully open the casing to expose the PCB.
2. Identify SWD pins – Locate the SWDIO and SWCLK test points or pads. Also find GND and VCC (3.3V).
3. Connect debugger – Connect SWDIO, SWCLK, GND, and optionally VCC to the debugger.
4. Dump firmware:

   openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "init" -c "reset halt" -c "flash read_bank 0 firmware_dump.bin 0 0x100000" -c "shutdown"
   

5. Analyze firmware – Use binwalk, Ghidra, or IDA Pro to extract keys and secrets.
6. Modify firmware – Patch the binary to disable authentication or add a backdoor.
7. Write modified firmware:

   openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "init" -c "reset halt" -c "flash write_bank 0 patched_firmware.bin 0" -c "shutdown"
   

Alternative (Raspberry Pi Pico as SWD adapter):

# Install picoprobe firmware on Pico
# Connect Pico to Nuki SWD pins
openocd -f interface/raspberrypi-swd.cfg -f target/stm32f4x.cfg -c "init" -c "reset halt" -c "flash read_bank 0 dump.bin 0 0x100000" -c "shutdown"

Blue Team (Defender)

Detection of Physical Tampering:

• Visual inspection – Check for signs of device opening (scratched screws, broken seals, loose casing).
• Tamper-evident seals – Apply tamper-evident stickers over screw holes and casing seams.
• Electronic tamper detection – If possible, add a circuit that detects when the casing is opened and erases sensitive data (e.g., using a battery-backed SRAM or TPM).

Firmware Integrity Verification:

• Remote attestation – Implement a mechanism where the device periodically sends a signed hash of its firmware to a cloud server. If the hash changes, alert the owner.
• Secure boot – Ensure the device uses signed firmware updates and verifies the signature before booting.

Network Monitoring (for post-compromise behavior):

• Monitor for unusual network traffic from the Nuki Bridge (e.g., connections to unknown IPs, large data exfiltration).
• Use a firewall to restrict outbound traffic from the Bridge to only known Nuki cloud servers.

Indicators of Compromise (IOCs)

Physical IOCs:

• Scratches or damage on device casing
• Broken tamper-evident seals
• Loose screws or missing screws
• Solder flux residue near SWD test points

Firmware IOCs:

• Unexpected changes in firmware hash (compare with known good hash from Nuki)
• Presence of debug code or backdoor functions in firmware dump
• Modified cryptographic keys or certificates

Network IOCs (if backdoor installed):

• Outbound connections to unknown IP addresses on non-standard ports
• DNS queries for suspicious domains
• Unusual data volumes during idle periods

Example YARA rule for detecting modified firmware:

rule Nuki_Firmware_Backdoor {
    meta:
        description = "Detects common backdoor patterns in Nuki firmware"
        author = "Valters IT"
        date = "2025-04-10"
    strings:
        $backdoor1 = { 6A 00 68 ?? ?? ?? ?? E8 ?? ?? ?? ?? } // call to debug function
        $backdoor2 = "debug_enabled" nocase
        $backdoor3 = "unlock_override" nocase
    condition:
        any of them
}

Detection Engineering

YARA Rule

rule CVE_2022_32506_Nuki_SWD_Exploit {
    meta:
        description = "Detects firmware dumps or modified firmware from Nuki devices with SWD access"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2022-32506"
    strings:
        $swd_header = { 00 00 00 00 00 00 00 00 } // placeholder for SWD-related pattern
        $nuki_magic = "Nuki" ascii
        $firmware_version = /[0-9]+\.[0-9]+\.[0-9]+/
    condition:
        $nuki_magic and $firmware_version and filesize < 2MB
}

Sigma Rule

title: Nuki Device Firmware Tampering via SWD
id: 7b8c9d0e-1f2a-3b4c-5d6e-7f8a9b0c1d2e
status: experimental
description: Detects network indicators of compromised Nuki devices after SWD exploitation
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        dest_ip:
            - "10.0.0.0/8"  # Example internal IPs
            - "192.168.0.0/16"
        dest_port:
            - 4444  # Common backdoor port
            - 8888
        duration: "> 3600"  # Long-lived connections
    condition: selection
falsepositives:
    - Legitimate firmware updates
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 4444,8888 (msg:"CVE-2022-32506 Nuki Device Backdoor Communication"; flow:to_server,established; content:"|00 01 02 03|"; depth:4; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update firmware – Upgrade all Nuki Smart Lock and Bridge devices to the latest patched versions:
   • Smart Lock 3.0: >= 3.3.5
   • Smart Lock 2.0: >= 2.12.4
   • Bridge v1: >= 1.22.0
   • Bridge v2: >= 2.13.2
2. Physical security – Install devices in tamper-resistant enclosures or locations where physical access is restricted.
3. Tamper-evident seals – Apply seals to device casing and regularly inspect them.

Long-term Mitigations:

• Disable SWD in production – Manufacturers should lock debug interfaces before shipping.
• Implement secure boot – Use signed firmware and verify signatures at boot.
• Remote attestation – Periodically verify firmware integrity via cloud service.
• Physical tamper detection – Add sensors that detect casing opening and trigger data erasure.

Workarounds (if patching is not possible):

• Physically remove or disable the SWD test points on the PCB (requires soldering skills).
• Encapsulate the device in epoxy resin to prevent access to the PCB.
• Use a Faraday cage or shielded enclosure to prevent wireless exfiltration.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert
This report is provided for educational and defensive purposes only.