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.