The first talk at 2016 Shmoocon was a great one. Joseph Hall and Ben Ramsey presented their work hacking Z-Wave, a network that has been gaining a huge market share in both consumer and industrial connected devices. EZ-Wave uses commodity Software Defined Radio to exploit Z-Wave networks. This is not limited to sniffing, but also used for control with the potential for mayhem.
Z-Wave is a proprietary wireless protocol which operates in the 900 Mhz spectrum. This spectrum is great for penetrating walls and floors which is part of the reason Z-Wave has been seeing a lot of success in the market.
To being their research, Joseph and Ben looked to see what tools are already available. OpenZWave is available but doesn’t support operations outside of the protocol. Two other options are Z-Force and Scapy0-radio. Both presented at past Blackhat Conferences and looked promising, but lacked availability. They decided to roll their own.
EZ-Wave is a chain of different tools. ezstumbler is used for network discovery; are there Z-Wave devices in use around us? ezrecon interrogates devices once a network has been found, yielding the software version, supported commands, current state*, and current configuration*. These last two traits (marked with asterisks) are not available on encrypted devices. With this in mind, the question becomes: how many devices are using encryption. As I’m sure you guessed, the answer is few.
Joseph and Ramsey purchased 33 different Z-Wave devices currently on the market and tested them. The test hardware is quite familiar to us. During the talk they demonstrated detecting, contacting, and controlling devices using a pair of HackRF One, the spectacular unit developed by Michael Ossmann who is also on hand for this year’s Shmoocon. One unit was issuing commands, the other unit was listening for Z-Wave packets.
In their tests of these 33 units the researchers found only nine utilized encryption. Five of the nine were Z-Wave enabled door locks — good on them for having encryption. The really bad news is that 3 of the remaining four had “opt-in” encryption that only runs if the user explicitly configures them to use it.
I previously alluded to the mayhem that is opened up by these unencrypted systems. During the talk, a paper discussing damage to industrial compact fluorescent lights (PDF) was referenced that showed bulbs can be damaged by turning them on and off using specific timings. This is due to thermal stress — turn them on and they warm up, turn them off and they cool down, repeat. The trick is to figure out how quickly they can be switched while still maximizing the thermal stress. Their testing determined that it is possible to destroy CFLs in half of one night. Why? Mayhem is a reason in itself, but industrial espionage is another. If all the lights in an entire warehouse are destroyed in a single night it will disrupt work for quite some time. Sure, we’re only talking CFLs in this example, but there are all kinds of other devices using the technology. I live in a cold climate. If someone turns off your thermostat for an extended period of time the water pipes in your house will freeze and burst.
Of course this isn’t all doom and gloom. The moral of the story is that as the number of connected devices grows, encryption must be included and should be enabled by default.
always happy to see SDR on hackaday :)
But did they hack Zwave Plus which is the new standard that everyone has switched to?
I strongly want to know the answer to this. I can’t tell from the linked Github page if they are omitting the “Plus” because it authentically isn’t the target, or for the same semantic reasons nobody typically includes it in speech (a la “TACACS+”).
From Z-Wave talking about Z-Wave Plus: “Z-Wave 500 Series platform…” and the EZ-Wave Github: “…determines device’s Z-Wave module generation (3rd of 5th gen).”
So now I’m more than 90% certain this attack includes Z-Wave Plus (500 Series = 5th Generation right?) but would love some official clarification.
I think it does include it:
242 class ZWavePlusInfo(Packet): 243 name = "ZWavePlusInfo" 244 fields_desc = [ 245 ByteEnumField("cmd", 1, {0x01: "GET", 0x02: "REPORT"}),From this file in their repo.
@MikeSczcys: Your HackRF One link in the article is pointing to a zwave resource, not to HackRF One.
Thanks, fixed.
Yes, we demonstrated using EZ-Wave on Z-Wave Plus devices (Aeotec Siren Gen 5, LED Bulb, and Smart Switch 6 demo’d during presentation). Z-Wave Plus does not mandate the use of encryption. When encryption is used, the device can’t be controlled, but recon is still possible.
Thanks Joe
Cool! It looks like adding support for various SDRs is just a matter of modifying/genericizing a GRC file. :)
Joe, if you see this — for adding support for other SDRs, are there any particular Z-Wave devices you’ve tested that you’d recommend starting with, just to verify the tools? Something that nicely intersects “cheap” and “works well with the tool” would be preferable.
Cheers!
Jon, I recommend any mains powered Z-Wave device. EZ-Wave can sniff traffic from battery operated devices but right now it can’t communicate reliably with them because of their low duty cycles. No such problem with devices that are plugged into the wall.
Also, it only works with the 40kbps data rate right now. All the devices I’ve tested that support the 100kbps data rate also support the 40kbps rate. But if you’re just sniffing and the device is talking at the 100kbps rate, you won’t see it. The device will start using the 40kbps data rate once you start transmitting to it.
Once you get the hang of the scapy zwave layer, you’ll be able to put together scripts to transmit whatever commands you want.
At 100k zwave is using different freq, so you will not see anything when you stay on the freq used by 40k mode. Btw, all this (and more) can be done with zwave zniffer, so you guys haven’t hacked anything^^
There are also a few other zwave analysis projects like this on github. But has anyone seen any open zwave stacks for the common RF microcontroller platforms?
Antennas in HackRF does not go there.. those two input ports he put antennas on (on the picture) is for sync signals..
There are actually two HackRFs stacked on top of each other (you can see the 2nd one if you look closely). The antennas are plugging into the proper port of each…it just looks there are two antennas plugged into the CLK ports on one.
I just started researching on Hackrf and SDR..I tried to install EZ-wave as well, but not able to successfully execute the command “./install.sh grc” in the installation process…and also not able to find any solution for it.