Critical: BindKey disclosure and full unauthorised access to THB devices (THB3 / BTH01, fw v2.1) — URGENT: immediate firmware update required

[314TeR]

⚠️ WARNING — THE CURRENT STATE IS HIGHLY DANGEROUS

In the current THB firmware implementation (tested on THB3 and BTH01, firmware v2.1), using the public web tool
PHY62x2BTHome.html allows anyone in BLE range to connect at any time to any device and:
• READ the current BindKey (even if the owner has already enabled broadcast encryption),
• DECRYPT and monitor telemetry (e.g. temperature, humidity),
• CHANGE device parameters and SET A NEW BindKey,
• POTENTIALLY UPLOAD OWN (including malicious) firmware if OTA images are not verified.

In short: an attacker within BLE range can fully surveil and/or hijack devices without any owner interaction.
This represents a critical privacy and security risk for all deployed devices.

⸻

Affected
• THB3 — firmware v2.1 (tested, bin: THB3_v21.bin)
• BTH01 — firmware v2.1 (tested)

⸻

URGENT: What must be done NOW (priority)
1. Immediately release a firmware update that requires an explicit physical owner action before allowing any administrative connection from the web/OTA tool https://pvvx.github.io/THB2/web/PHY62x2BTHome.html.
• Devices must refuse administrative queries (including BindKey reads and OTA-trigger operations) from external tools by default.
• Administrative access should be enabled only after the owner explicitly allows it through a physical action — either by pressing a hardware button on the device (e.g., one long press or two short presses), or automatically for a limited time window (recommended 60–180 seconds) immediately after battery insertion.
• The administrative window must automatically close after the timeout, and the device must block all new administrative pairing attempts until the next explicit physical action.
• This firmware change is the highest priority — it immediately closes the open attack vector and prevents unauthorised BindKey reading or firmware uploads.
2. Block remote READ access to the BindKey.
Once a BindKey is set, the device must never return its value to any external tool; it should only acknowledge that a key has been configured.
3. Suspend or restrict OTA updates from unverified sources until proper signature verification (signed firmware) is implemented and enforced.

These three actions are Priority 1 and should be implemented in the next firmware release to mitigate the vulnerability as fast as possible.

⸻

Reproduction steps (for maintainer verification)
1. Open: https://pvvx.github.io/THB2/web/PHY62x2BTHome.html
2. Discover and connect to any THB3 / BTH01 device running THB2 fw (v2.1).
3. Go to the Service tab.
4. Read the current BindKey (even if the owner has previously configured encryption).
5. Use the read BindKey to decrypt the BLE broadcasts — telemetry is decrypted successfully.

No special logs are required (the behaviour is identical to a normal connection).
A short screen recording or BLE capture can be provided upon request if needed for verification.

⸻

Impact
• Disclosure of BindKey → full decryption of telemetry data.
• Violation of user privacy (enables tracking of habits or presence, e.g. shower or occupancy patterns).
• Possible installation of malicious firmware → permanent device compromise.
• Potential use of compromised devices as a stepping stone into local networks or other systems.

⸻

Long-term recommendations
• Implement per-device or vendor-level firmware signing and verify signatures in the bootloader (secure boot chain).
• Store BindKey in a non-exportable form — usable by the device but never retrievable externally.
• Notify owners (e.g. through the app) about administrative connection attempts from unknown sources.
• Harden production builds to disable debug/admin interfaces or enforce proper authentication.

⸻

Request & next steps

Please confirm receipt of this report and indicate which of the Priority 1 mitigations will be included in the next firmware release.
I can supply a short screen recording demonstrating BindKey reading and provide BLE logs if needed for internal testing.

Best regards,
Piotr

[pvvx]

URGENT: What must be done NOW (priority)

I'm waiting for your "Pull requests" :)

Where did you see that these firmware versions have protection against unauthorized access?
Currently, this feature is only available in firmware for TLSR825x devices.

Security is planned and will be implemented when I have sufficient free time and inclination.
Security will be implemented by setting up the standard BLE option using a 4-digit PIN-code.

Implementation is planned no earlier than the end of this year.
If you'd like to expedite the process, I welcome your pull requests for discussion and implementation of the desired functionality.

[rogerclarkmelbourne]

@314TeR
So is the solution simply to prevent OTA and some other functions operating unless the button is being pressed.

IMO.
Reading of Temperature and Humidity data by other people within BLE range is not a critical issue and should be added as a separate low prority issue.

My personal experience with the THB2 is that the OTA was not reliable even at very short distances, and I had to flash the entire firmware via USB->Serial

A very short term fix would be to completely disable OTA and only use direct connection. This could be rolled out via an OTA.

IMHO. I doubt many people ever update their devices after first flashing them, so personally I think the OTA could be removed permanently.

[pvvx]

Disrupting an OTA update does not affect the thermometer's functionality.
A crash can only occur if the battery is low a BOOT update, but never during an APP update.
OTA for APP is completely safe.

[rogerclarkmelbourne]

@pvvx

I was trying to use OTA when power via a USB Serial adaptor, just after I flashed the boot file.

Possibly the USB Serial adaptor 3.3V output could not supply enough current to sustain the OTA.
When I get time I will try OTA with new batteries fitted to the THB2

All my sensors are easy for me to access, so its not a big problem to open them, solder wires and flash via USB Serial

[pvvx]

OTA:

1. When OTA starts, the FW APP loading identifier (in to Flash) flag is erased.
2. When data is transferred to OTA, the checksum of each transferred block (up to 20 bytes) is verified.
3. When data loading is complete, the CRC32 checksum of the entire FW written to Flash is verified.
4. If everything is successful, only then is the identifier written indicating that this FW APP can be launched.
5. A reboot to BOOT occurs.
6. Upon startup, BOOT always checks the FW APP validity flag and launches the APP.

A violation at any point results in an error message and a reboot to BOOT.
A timeout is in effect: if OTA data is not received for a long time, a reboot to BOOT occurs.

[rogerclarkmelbourne]

@pvvx

My problem with OTA was disconnection during the data transfer. But this could have been caused by insufficient current from the USB Serial.

Anyway. Personally its easier for me to install everything via USB Serial, and probably update via USB serial if update is ever essential

[pvvx]

My problem with OTA was disconnection during the data transfer. But this could have been caused by insufficient current from the USB Serial.

This also doesn't affect over-the-air (OTA) app downloads.
Power outages can only affect the firmware during OTA updates when the bootloader is replaced. And then, only immediately after the OTA update, when the already loaded BOOT firmware code is rewritten to the flash memory in the corresponding boot area. This occurs less than a second after the BOOT firmware completes the OTA update transfer, immediately after the CRC32 check of the entire loaded firmware.

Bottom Line:

1. OTA APP: Over-the-air (OTA) APP updates are completely safe for apps—you won't damage your BOOT. And your BOOT is always ready for a new OTA update.
2. OTA BOOT: Over-the-air (OTA) BOOT updates are not safe - there is a 0.2% chance of BOOT corruption if you turn off your device while an OTA update is completing.