IOT failure - again
-
It's like saying that Windows security doesn't work because people shared passwords at one company. Or that SSH isn't secure because you CAN hard code passwords and let them get compromised.
Those are end user issues, not protocol issues.
-
@scottalanmiller said in IOT failure - again:
http://betanews.com/2016/11/14/philips-hue-light-bulbs-worm-vulnerable/
Hard coded keys (passwords) and the threat is only to other bulbs all sharing the same password. Obviously not a flaw, just bad planning. Not a ZB issue.
Sorry if you thought I was implying that ZB was broken.. (it's not great by any means, but not as broken as this implementation by Philips).
-
@Dashrender said in IOT failure - again:
Sorry if you thought I was implying that ZB was broken.. (it's not great by any means, but not as broken as this implementation by Philips).
THIS implementation isn't broken at all, either!! Nothing whatsoever wrong with ZB here at all. Where are you getting that? The articles aren't saying that at all.
-
The article does get the recap of what they write originally wrong and call it the implementation. It's not, whatever intern recapped obviously couldn't read the original. It's a shared password only.
-
With further offline discussion - we found that something called touchlink is where the implementation (or advancement in technology) failure took place in ZB.
I found this black hat article, https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly-wp.pdf
... ZLL devices support a feature called “Touchlink Commissioning” that allows devices to be paired with controllers. As the default and publicly known TC link key is used, devices can be “stolen”. Tests showed that amateur radio hardware using normal dipole (Rasperry Pi extension board) antennas already
allowed Touchlink Commission from several meters away whereas for security reasons this should only work in close proximity. Usage of professional radio equipment would allow an even higher distance for such a successful device
takeover.This tells me (though I haven't found it yet) that there is some type of spec that is suppose to prevent pairing of devices outside of a certain range.
-
https://www1.informatik.uni-erlangen.de/filepool/publications/zina/ZLLsec-SmartBuildingSec16.pdf
Nice read about touchlink, ZLL.
-
https://eprint.iacr.org/2016/1047.pdf
We focus in this paper on the popular Philips Hue smart
lights which had been sold (especially in the European
market) in large numbers since 2012. The communication
between the lamps and their controllers is carried out by the
Zigbee protocol, which is the radio link of choice between
many IoT devices due to its simplicity, wide availability, low
cost, low power consumption, robustness, and long range (its
main disadvantage compared to WiFi radio communication
is its limited bandwidth, which is not a real problem in most
IoT applications). The Hue lamps contain a ZigBee chip
made by Atmel, which uses multiple layers of cryptographic
and non-cryptographic protection to prevent hackers from
misusing the lamps once they are securely connected with
their controllers. In particular, they will ignore any request
to reset or to change their affiliation unless it is sent from
a ZigBee transmitter which is only a few centimeters away
from the lamp. Even though the attacker can try to spoof
such a proximity test by using very high power transmitters,
the fact that the received power decreases quadratically with
the distance makes such brute force attacks very hard (even
at ranges of a hundred meters). This requires high power
dedicated equipment and cannot be done with the standard
ZigBee off the shelf equipment.
Our initial discovery was that the Atmel stack has a
major bug in its proximity test, which enables any standard
ZigBee transmitter (which can be bought for a few dol-
lars in the form of an tiny evaluation board) to initiate a
factory reset procedure which will dissociate lamps from
their current controllers, up to a range of 400 meters.
Once this is achieved, the transmitter can issue additional
instructions which will take full control of all those lamps.
We demonstrated this with a real war-driving experiment
in which we drove around our university campus and took
full control of all the Hue smart lights installed in buildings
along the car’s path. Due to the small size, low weight, and
minimal power consumption of the required equipment, and
the fact that the attack can be automated, we managed to
tie a fully autonomous attack kit below a standard drone,
and performed war-flying in which we flew hundreds of
meters away from office buildings, forcing all the Hue lights
installed in them to disconnect from their current controllers
and to blink SOS in morse code.
By flying such a drone in a zig-zag pattern high over a
city, an attacker can disable all the Philips Hue smart lights
in city centers within a few minutes. Even though such an
attack can have very unpleasant consequences, its effects are
only temporary since they can be reversed by the tedious
process of bringing each lamp to within a few centimeters
from its legitimate controller and reassociating them.interesting, seems that the implementation error (still haven't found how the distance is supposed to be ensured) is in the ZigBee chip from Atmel, not something Philips did wrong.
-
It's likely that this attack was only possible because a master key, one that's distributed to all certified ZigBee manufacturers under a secrecy clause and used on every ZigBee device, was in fact leaked in 2015. With this master key along with the flaw in the Atmel chip, probably is what allowed this situation to exist.
haven't they learned yet that a master key doesn't work? DVD's anyone? BluRay?
-
https://arxiv.org/pdf/1608.03732.pdf
Because our implementation failed to
send the acknowledgment within the demanded time frame
of 864 microseconds, we spoof another ZigBee device in
the network that acknowledges the reception of the scan
response, even if this device did not send the
scan request, as shown in Figure 6In contrast, the Hue bulb responses to any arbitrary
originator because apparently no acknowledgment on MAC-layer is required. -
@dafyre Yeah, i've got a set of 3. they're awesome
I'm gonna pick up some of the light strips soon too! Deck, outdoor kitchen, and mood lighting needs to happen -
@hubtechagain Better make sure your bulbs don't get hacked, ha ha.
-
I'll stick with my Old School Lutron Caseta switches and dimmers, and using a local apple tv as a bridge for homekit. These vendors doing their own standards are the problem.
-
@Jason said in IOT failure - again:
I'll stick with my Old School Lutron Caseta switches and dimmers, and using a local apple tv as a bridge for homekit. These vendors doing their own standards are the problem.
What own standards would those be?
The bulbs in question use ZB a widely used standard.
-
@Dashrender said in IOT failure - again:
The bulbs in question use ZB a widely used standard.
Zigbee is a randomly developed standard by a new alliance that doesn't have much experience. It's had many security concerns since day one. Anyone using it just plain didn't care about security.
-
@Jason said in IOT failure - again:
@Dashrender said in IOT failure - again:
The bulbs in question use ZB a widely used standard.
Zigbee is a randomly developed standard by a new alliance that doesn't have much experience. It's had many security concerns since day one. Anyone using it just plain didn't care about security.
I completely agree, though I wouldn't call it new.
So what open standard do you know about that all of these guys are refusing to use, that's been vetted and so far stands up to good security practices?
-
@Dashrender said in IOT failure - again:
@Jason said in IOT failure - again:
@Dashrender said in IOT failure - again:
The bulbs in question use ZB a widely used standard.
Zigbee is a randomly developed standard by a new alliance that doesn't have much experience. It's had many security concerns since day one. Anyone using it just plain didn't care about security.
I completely agree, though I wouldn't call it new.
So what open standard do you know about that all of these guys are refusing to use, that's been vetted and so far stands up to good security practices?
I'm a bit curious too. He has tons of secret knowledge about this stuff and AV equipment that when prompted for, doesn't have anything to show for it. Can't tell if he's bluffing and doesn't realize we will ask for more info, or if he knows so little that he's unclear as to what constitutes a reasonable bluff. The Curtis dilemma, in the second case, wants to sound cool but knows so little he can't tell when he is telling a reasonably lie or a ridiculous one (like that he watched the Internet get invented in 1998 - years after we'd all been using it regularly.)
