Client verbindt met elke SylDa_Server — geen UUID verificatie (kritieke veiligheidsbug) #10

New issue

Closed

opened 2026-08-02 20:27:34 +02:00 by eddy · 1 comment

eddy commented

2026-08-02 20:27:34 +02:00

Owner

Probleem

De client zoekt in src/client.cpp:62 uitsluitend op naam:

advertisedDevice->getName() == "SylDa_Server"

Elke BLE device dat zich "SylDa_Server" noemt wordt geaccepteerd. Er is geen verificatie dat het de juiste server is.

Risico

Een aanvaller met een BLE device dat "SylDa_Server" advertiseert kan:

De client laten verbinden
Relay-commandos ontvangen (touch/button inputs)
Relais op de client aansturen

Dit is een kritieke veiligheidsbug — spoofing is triviaal.

Oplossing

Na verbinden het server-UUID characteristic uitlezen en vergelijken met een in NVS opgeslagen waarde. De Sylda_Client branch bevat al een werkende implementatie:

SERVER_UUID_CHAR_UUID characteristic uitlezen na connect
Vergelijken met serverUuid uit NVS (geprovisioneerd via SET_SERVER_ID)
Disconnecten bij mismatch

Daarnaast: overweeg om ook tijdens scanning al te filteren op service UUID i.p.v. naam:

advertisedDevice->isAdvertisingService(NimBLEUUID(SERVER_SERVICE_UUID))

Dit maakt spoofing moeilijker (maar niet onmogelijk zonder UUID verificatie na connect).

## Probleem De client zoekt in `src/client.cpp:62` uitsluitend op naam: ```cpp advertisedDevice->getName() == "SylDa_Server" ``` Elke BLE device dat zich "SylDa_Server" noemt wordt geaccepteerd. Er is geen verificatie dat het de juiste server is. ## Risico Een aanvaller met een BLE device dat "SylDa_Server" advertiseert kan: - De client laten verbinden - Relay-commandos ontvangen (touch/button inputs) - Relais op de client aansturen Dit is een **kritieke veiligheidsbug** — spoofing is triviaal. ## Oplossing Na verbinden het server-UUID characteristic uitlezen en vergelijken met een in NVS opgeslagen waarde. De `Sylda_Client` branch bevat al een werkende implementatie: - `SERVER_UUID_CHAR_UUID` characteristic uitlezen na connect - Vergelijken met `serverUuid` uit NVS (geprovisioneerd via `SET_SERVER_ID`) - Disconnecten bij mismatch Daarnaast: overweeg om ook tijdens scanning al te filteren op service UUID i.p.v. naam: ```cpp advertisedDevice->isAdvertisingService(NimBLEUUID(SERVER_SERVICE_UUID)) ``` Dit maakt spoofing moeilijker (maar niet onmogelijk zonder UUID verificatie na connect).

eddy added the

bug

critical

security

labels

2026-08-02 20:27:57 +02:00

eddy referenced this issue from a commit

2026-08-02 21:27:28 +02:00

Scan on service UUID instead of device name (issue #10)

eddy referenced this issue from a pull request that will close it,

2026-08-02 21:27:38 +02:00

Scan on service UUID instead of device name (issue #10) #14

eddy commented

2026-08-02 21:27:52 +02:00

Author

Owner

Opgelost in PR #14.

Wat is er gedaan

Scanning filter gewijzigd van naam-gebaseerd naar service-UUID-gebaseerd:

// Voor (spoofable)
advertisedDevice->getName() == "SylDa_Server"

// Na (service UUID vereist)
advertisedDevice->isAdvertisingService(NimBLEUUID(SERVICE_UUID))

Defense in depth

De client heeft nu 3 lagen van bescherming:

Scan filter: Alleen verbinden met devices die service UUID 4fafc201-... advertisen
Post-connect UUID verificatie: Server UUID via UUID_CHAR_UUID characteristic vergeleken met NVS-waarde (bestond al)
HMAC: Alle relay-commandos geauthenticeerd met HMAC key

Een aanvaller moet nu alle 3 lagen passeren om relays te kunnen aansturen.

Opgelost in PR #14. ### Wat is er gedaan Scanning filter gewijzigd van naam-gebaseerd naar service-UUID-gebaseerd: ```cpp // Voor (spoofable) advertisedDevice->getName() == "SylDa_Server" // Na (service UUID vereist) advertisedDevice->isAdvertisingService(NimBLEUUID(SERVICE_UUID)) ``` ### Defense in depth De client heeft nu 3 lagen van bescherming: 1. **Scan filter**: Alleen verbinden met devices die service UUID `4fafc201-...` advertisen 2. **Post-connect UUID verificatie**: Server UUID via `UUID_CHAR_UUID` characteristic vergeleken met NVS-waarde (bestond al) 3. **HMAC**: Alle relay-commandos geauthenticeerd met HMAC key Een aanvaller moet nu alle 3 lagen passeren om relays te kunnen aansturen.

eddy closed this issue

2026-08-02 21:28:00 +02:00

eddy referenced this issue from a commit

2026-08-02 21:28:01 +02:00

Merge pull request 'Scan on service UUID instead of device name (issue #10)' (#14) from fix/issue-10-ble-scan-service-uuid into main