-
Notifications
You must be signed in to change notification settings - Fork 19
Optimize Attacks
Some touchlink-enabled devices require an MAC-layer acknowledgment (ACK) on the reception of the scan response. If they do not receive an ACK within a specified time frame of 864 microseconds, they drop further communication. Z3sec is too slow in sending this ACK since the processing of the received ZigBee frames is not performed on the hardware platform but in software, and therefore delayed for a few milliseconds. However, we can impersonate an existing ZigBee device, referred to as spoofed device, by setting the extended source address of our scan request to the extended address of the spoofed device. As a result, the spoofed device sends an ACK upon reception of a scan response, even if this device had never sent any scan request. This is an inherent feature of the IEEE 802.15.4 MAC layer, and we can leverage this mechanism for “providing” ACKs timely.
An exemplary command triggering the identify action of a touchlink-device on channel 20 for a duration of 15 seconds, while spoofing another ZigBee device that is within the wireless range:
z3sec_touchlink --sdr -c 20 --src_pan_id 0xABCD --src_addr_ext 00:17:88:01:00:ed:5c:30 identify --target 11:22:33:33:55:66:77:88 -d 15
This command spoofs another ZigBee device that does not necessarily supports touchlink commissioning. In our example, the spoofed device has the PAN ID 0xABCD and the extended address 00:17:88:01:00:ed:5c:30.
In the ZigBee speci�cation, the manufacturers are advised to limit the wireless range of touchlink commands such that only ZigBee devices in close proximity are able to perform the touchlink commissioning procedure. This limitation, denoted as proximity check, should be implemented in a way that the received signal strength of an initiator device must be above a certain threshold.
However, some (old) touchlink-enabled devices implement flawed ZigBee stacks, which can be exploited in order to circumvent this proximity check.
We encountered two types of incorrect processing of touchlink frames:
Touchlink commands can be send via broadcast without waiting for a scan response.
Procedure: The scan request is broadcasted according to the specification and the inter-PAN transaction ID is set to a non-zero random value. Afterwards, wait for 0.25 seconds but does not try to receive any scan responses. Then, a touchlink command frame is broadcasted including the non-zero inter-PAN transaction ID from the foregoing scan request.
To send a broadcast command with Z3sec, please add the flag --broadcast to supported commands.
Example:
z3sec_touchlink --sdr -c 20 identify -d 15 --broadcast
This bug was first discovered by Ronen et al.
Procedure: A scan request is omitted and only a single touchlink command is sent. The touchlink command packet deviates from the specification in two aspects. In the MAC layer, the destination address mode is set to 2 (short address) and the MAC destination is set to 0xffff (broadcast). On application layer, the inter-PAN transaction ID is set to zero.
To exploit the bug in the proximity check with z3sec_touchlink, please add the flag --no_scan to supported commands.
Example:
z3sec_touchlink --sdr -c 20 identify -d 15 --no_scan
Touchlink-enabled devices using a correct ZigBee stack should not react to the above modified touchlink command frames. Some previously affected devices already receive OTA updates to fix the bugs.
Even without exploiting any bugs in the ZigBee stack, it is possible to enlarge the touchlink range by adjusting the TX gain of the USRP.