Blog: Internet Of Things
Z-Shave. Exploiting Z-Wave downgrade attacks
TL;DR: Stronger S2 Z-Wave pairing security process can be downgraded to weak S0, exposing smart devices to compromise.
Z-Wave uses a shared network key to secure traffic. This key is exchanged between the controller and the client devices (‘nodes’) when the devices are paired. The keys are used to protect the communications and prevent attackers exploiting joined devices.
The earlier pairing process (‘S0’) had a vulnerability – the network key was transmitted between the nodes using a key of all zeroes, and could be sniffed by an attacker within RF range. This issue was documented by Sensepost in 2013. We have shown that the improved, more secure pairing process (‘S2’) can be downgraded back to S0, negating all improvements.
Once you’ve got the network key, you have access to control the Z-Wave devices on the network. 2,400 vendors and over 100 million Z-wave chips are out there in smart devices, from door locks to lighting to heating to home alarms. The range is usually better than Bluetooth too: over 100 metres.
There have been some interesting developments during disclosure, which seem to have been triggered when the media became interested.
The hack
As we couldn’t get hold of a controller supporting S2 security, we are using a Sigma provided tool called ‘PC Controller’. This is not a Z-Wave certified S2 controller, and hence does not display a warning when S0 security is used. Most S2 controllers have a very limited UI, so even if they do alert the user it’s likely to be no more than a flashing LED.
Older, weak Z-Wave S0 security
S0 exchanges the network key by encrypting it with a fixed key of 0000000000000000. This means that an attacker in RF range when the device is paired can obtain the network key and attack any device on the network. This is a known issue.
‘Fixing’ this with S2
S2 aims to fix this problem. The key-exchange now uses Diffie-Hellman and can also involve authentication by entry of a 5 digit code into the controller. As a result, if S2 pairing is used, it should not be possible to intercept the key.
There are other differences between S0 and S2 but they are not relevant to this issue.
If S2 pairing is used, it is true that the key cannot be intercepted. However, protocol weaknesses around the selection of S0 and S2 mean that an active attacker, present at the time of pairing, can downgrade an S2 pairing to S0, thereby allowing them to intercept the key and then intercept and inject S0 traffic on the Z-Wave network.
How-to:
Z-Wave Zniffer was used to observe both open (no encryption), S0 and S2 pairings, using a Z-Wave PC Controller using the Sigma UZB EU. S2 is not supported on any retail controllers currently available in the UK, so this was the only option available.
We used a Yale Conexis L1 smart lock with a Z-Wave module 2 installed, supporting S2:
It was noted that devices and controllers are backwards compatible. An S2 device will pair as S0 if the controller only support S0. An S0 device will pair with no encryption if the controller does not support S0. A network can support a mixture of devices, although encrypted traffic cannot move from S0 to S2 or vice versa.
Figure 1 – sniffing Z-Wave using Zniffer
The process of adding S0 devices is summarised below:
The process of adding an S2 node is shown below. Note the key exchange, a major difference between S0 and S2:
In both instances, the controller must be put into “add” mode by physical action. A button must then be pressed on the device. This causes the device to send out a “node info”, which the controller receives and proceeds with the pairing.
Notice the similarity between the first part of the S0 and S2 flows. Up until “Security Scheme Get” and “KEX get”, the type of packets sent are identical. This raises the question: what causes the controller to follow the S0 or S2 key exchange process?
There is a very limited amount of data in the payload prior to the deviation:
- Node Info – this communicates the capabilities of the node including the supported command classes.
- Assign ID – this only communicate the ID that the node should take on.
- Ack – this contains no payload.
The only differences are in the Node Info information:
Figure 2 – Node Info for a S2 device
A device supporting S2 will support the command class of 0x9F – COMMAND_CLASS_SECURITY_2.
The node info command is entirely unencrypted and unauthenticated. This leads to us being able to spoof it, removing the COMMAND_CLASS_SECURITY_2 command class. The controller then assumes that the device does not support S2, and pairs using S0 security. The attacker can now intercept the key exchange, obtain the network key and then command the device.
It’s important to note that the Z-Wave specification says that an S2 controller must notify the user when S0 security is used. We feel this will be ignored or overlooked.
The spoofed node info must contain the same home ID as the unpaired node. This home ID is not constant for a device and is regenerated each time it is removed or reset. This means an attacker must first obtain the home ID for the node before they can send a spoofed packet. This is entirely possible.
Original packet:
FB 2E E0 F2 00 01 4B 15 FF 01 01 53 DC 01 40 03 5E 55 98 9F 59
Modified packet
FB 2E E0 F2 00 01 41 14 FF 01 01 53 DC 01 40 03 5E 55 98 CD
The class of 0x9F has been removed, and the length and checksum recalculated.
Three different attacks
There are three different means by which the attack could be achieved:
Method 1
A user would normally enable “add” mode on the controller before pressing the button on the node. However, from time to time this sequence is reversed, due to user error or simply fiddling with the device. This means that the node info for the unpaired node can be sniffed by an attacker, modified, and then sent to the controller.
We successfully carried out method 1 against the Yale Conexis L1 lock, resulting in it pairing as S0 and the attacker being able to lock and unlock the device.
Figure 3 – normal S2 pairing showing class of 0x9F (second to last byte) of Node Info
Figure 4 – S2 device pairing with S0 controller – 0x9F class is ignored
Figure 5 – S2 to S0 downgrade attack. Middle highlighted packet is injected without class 0x9F
Figure 6 – PC Controller prior to pairing showing S2 enabled
Figure 7 – network key decrypted from S0 key exchange
Figure 8 – S2 device paired as S0
Method 2
Some devices send a node info as soon as the battery is inserted. This would allow the attacker to obtain the node-info as the user unboxes and powers up the device. The attack could then proceed, even if the user does not press the add buttons in the incorrect order.
Method 3
The third method involves active jamming using an RFCat. An attacker can continuously listen for the node info from the genuine node. As soon as the home ID has been obtained, they can actively jam the rest of the packet, preventing the node info from being received.
This attack requires further work though, owing to the time-critical jamming. This is because the jamming needs to occur mid-way through the transmission of a packet and the current tools available are only capable of waiting until the end of a packet.
Z-Wave standards, disclosure and misleading statements from vendors
We asked Yale if the Conexis L1 with Z-Wave Module 2 can use S2 with any hardware – there was no response 12 days from this.
However, SmartThings does not support S2, confirmed by Samsung!
Did Z-Wave know about this already, but kept it quiet?
We were fascinated to see reference to a “S0 downgrade attack” in Z-Wave documentation, suggesting that it may be a known issue but has not been acknowledged or resolved
http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS11846-20%20Z-Wave%20Plus%20Role%20Type%20Specification.pdf
There does not appear to be anything stating the S2 node should issue a warning message to the user. When an S2 node pairs to a S0 controller, the user will not be made aware.
There are two security situations possible:
User pairs an S2 device to an S2 hub and is downgraded to S0
Z-Wave say the user should be warned of this by the controller. This warning may be ignored.
The downgrade attack will leak the (single) S0 security key. This puts all S0 devices at risk, even if the user unpairs the S2 device.
User pairs an S2 device to an S0 hub and uses S0 by default
The S0 hub is totally unaware of S2, so cannot warn that S0 is in use.
The devices do not warn the user that S0 is in use.
Therefore a user is unlikely to realise.
There are only 4 controllers that support S2 in Europe; we cannot find any for sale or supported in the UK:
Homeseer (a home automation system for enthusiasts) has beta support:
https://forums.homeseer.com/showthread.php?p=1365456
Notice this phrase:
The Z-Wave Alliance has published statements that ALL devices certified after 2 April 2017 MUST support S2. Approximately 180 devices have been certified since April 2017, yet only 48 of these support S2 security – only around one quarter:
It would be unfair to call them exceptions as it seems that most devices certified since then do not support S2:
The product marketing of Conexis L1 mentions S2:
https://www.yale.co.uk/en/yale/couk/products/smart-living/smart-door-locks/z-wave-module-2/
https://www.diy.com/departments/yale-smart-lock-z-wave-2nd-gen-module/5011802286320_BQ.prd
(Notice the careful “Features may vary”)
Disclosure
During disclosure, it was found that the Z-Wave specifications referred to a “S0 downgrade attack” – this was an issue already known by Silabs. We got a lukewarm response through responsible disclosure, and it was only after a journalist contacted Silabs for comment, Silabs made a blog post entitled “tl;dr: Your Door is Still Locked”. This links to a previously unpublished report of a security test of the S2 protocol, performed over three days in June 2017, again by SensePost.
The report does find a downgrade issue with the S2 protocol, but there are some important differences to the attack we present.
In the SensePost report, the downgrade occurs when the user fails to enter the S2 “device specific key” quickly enough. The text in the report states that the downgrade is from S2 to S0, however the screenshots of the PC Controller and Zniffer indicate that no security is in use – not S0. We had noticed the same issue during our testing, but saw that the downgrade is from S2 to no security.
The PC Controller prefixes the node name with [S0] when a device is paired with S0, and nothing when no security is in use. More obviously, the Zniffer data doesn’t show the characteristic nonce get/report cycle involved during S0 communication.
Figure 1 – screenshot of SensePost report
Figure 2 – PC Controller showing an S0 paired device – notice the difference to the SensePost screenshot
Figure 3 – S0 communication showing Nonce Get/Report cycle
A downgrade to no security may sound like it has more serious impact, but it means that the attacker cannot obtain the S0 network key. This means the only node placed at risk is the one just added. If an S0 network key is obtained, all S0 devices connected in the past and future are placed at risk.
The bigger difference is that our attack can be carried out by an active attacker within RF range at the time of pairing. And when we say active attacker – we don’t mean a guy in a hoody sat in a car with a laptop. A battery-powered drop-box could be left outside the property for weeks, waiting for a pairing event to occur.
Our bigger concern with the report is that the issue was dropped from “High” to “Info”:
We strongly disagree that a flaw introduced “by design” reduces the risk this much.
We have massive respect for SensePost. They found a variant of the issue that we later discovered; the problem is that Silabs did not make their customers aware.
Conclusion
We don’t think this is a fault of Yale, we’re just using their lock as an example. Other than some slightly misleading marketing materials, their claims are accurate. The ‘Z-Shave’ issue appears to be a standards and implementation issue.
We aren’t certain how backward compatibility with S0 can be supported whilst enforcing stronger S2 security. This underlines the challenge with many protocols: how do you improve security without creating mountains of electronic waste for devices that are no longer supported?
At the very least, the user should be fully alerted to the fallback to weak security.
The risk is mitigated as one has to be present during the pairing process, but the Z-Wave RF range is significant. We’re investigating whether it might be possible to de-authenticate a Z-Wave client device, but that’s work in progress.
Finally, we’re not particularly happy that the Z-Wave Alliance appears to have been aware of the downgrade attack, but hasn’t really addressed it. The appearance in press releases that S2 was a requirement from April 2017 seems to us to be really quite misleading.
