CVE-2023-4258 - Critical Flaw in Bluetooth Mesh Provisioning Lets Attackers Replay Out-of-Band Public Keys

Bluetooth Mesh is becoming the backbone for many smart homes, industrial IoT, and lighting systems, helping devices talk securely at scale. But recently, a serious security bug—CVE-2023-4258—has been found in how some mesh stacks handle device provisioning. If you’re managing or designing products with Bluetooth Mesh, understanding this vulnerability is a must.

In this post, we’ll break down what this CVE really means, how it happens (with simple code), and why it’s dangerous. We’ll also share links to the original advisories and explain how exploits might work in real-world Bluetooth Mesh networks.

What is Bluetooth Mesh Provisioning?

Provisioning is like “enrolling” new devices into your home or industrial wireless network. It’s supposed to be very secure, using cryptography to keep eavesdroppers out. One of the steps involves sharing public keys—either over-the-air or out-of-band (OOB, like NFC or QR codes). These public keys prove that both the new device (provisionee) and the thing onboarding it (provisioner) are legit.

But CVE-2023-4258 shows that in some cases, the provisionee (the device joining the network) can be tricked into accepting an attacker’s public key—opening the door to device impersonation and network access.

What Is CVE-2023-4258?

In vulnerable Bluetooth Mesh stacks, when a device (provisionee) is supplied with a public key out-of-band (OOB), it’s possible for a remote attacker to send that same public key back during provisioning. Instead of rejecting the replay, the provisionee accepts it. This bypasses key authentication and can allow rogue devices to sneak into your mesh.

Key problem:
*The provisionee doesn’t check if the received public key during provisioning was just sent back from its own OOB data. This makes it trivial for attackers with temporary access to OOB data to “clone” or impersonate a device during provisioning.*

Reference Links

- Official CVE page: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4258
- Bluetooth SIG Security Notices: https://www.bluetooth.com/security/known-vulnerabilities/
- Nordic Advisories: https://infocenter.nordicsemi.com/topic/errata_nrf52/ERR/nRF52832/Engineering/doc/errata_nrf52832_709.html

Imagine a Python-like process on the provisionee side

def provisioning_step(received_pubkey):
    # pubkey_expected_oob is what we sent via OOB (e.g., QR code)
    if received_pubkey == pubkey_expected_oob:
        print("Warning: Received own OOB public key. Rejecting as replay attack.")
        abort_provisioning()
    else:
        proceed_with_provisioning(received_pubkey)

But in vulnerable stacks, that check doesn’t exist, so simplified

def provisioning_step(received_pubkey):
    # Accepts any public key, even if it's its own OOB-supplied key!
    proceed_with_provisioning(received_pubkey)

*End result: Attackers with temporary access to the OOB can just echo it back and “become” that device.*

What Could Attackers Actually Do?

- Impersonate the provisionee: Using knowledge of OOB public keys (easy if using QR or NFC tags available to more than just owners), attackers can become “clones.”
- Join the mesh as fake devices: Attackers can provision their own node pretending to be the legitimate one, causing confusion or security breaches.
- Man-in-the-middle attacks: By exploiting provisioning, attackers may insert themselves between devices, capturing or manipulating mesh traffic.
- Widespread compromise: If manufacturers reuse OOB keys or make them easy to extract, attacks can scale up.

Here’s how an attack might happen in code-speak, in simple steps

# Attacker gets OOB public key (from factory sticker, QR, dumps, etc)
oob_pubkey = obtain_oob_from_target()

# During provisioning, attacker connects to provisionee
provisionee.send_public_key(oob_pubkey)   # Sends its OOB key as expected

# Attacker simply sends the same key back
attacker.send_public_key(oob_pubkey)      # Echoes OOB key back to fool the stack

# Vulnerable provisionee accepts it
# Provisioning is "successful," but now the attacker is authenticated!

*In real code, this exploit would be done with actual Bluetooth mesh messages using libraries like pybluez or manufacturer devkits, but the principle is the same.*

How To Fix or Detect

1. Add a check: Devices should verify that any incoming public key isn’t the same as their own OOB public key.

Rotate OOB public keys: Never use default, hardcoded, or reused OOB keys.

3. Patch your stack: Check with your vendor or Bluetooth mesh stack supplier. Nordic’s fix removes this flaw, for example.

Conclusion

*CVE-2023-4258 is a classic lesson: even strong cryptography gets undermined by sloppy logic checks.* Out-of-band authentication is powerful—but only if devices make sure they’re not accepting their own key back! If you build or deploy Bluetooth mesh, double-check your code and push vendors for updates. Prevention is as simple as a single comparison line, but the risk of exposure is real.

Sources

- MITRE CVE-2023-4258
- Bluetooth SIG Security Notices
- Nordic’s Errata Page (Bluetooth Mesh)


If you want more deep-dives like this, follow or reach out for tailored advice on Bluetooth mesh security!

Timeline

Published on: 09/25/2023 22:15:11 UTC
Last modified on: 09/26/2023 17:19:08 UTC