Zigbee HA vs. Z Wave

[Dean Roddey]

People are saying you can update the firmware image over ZigBee, If I am reading that correctly.

If you can't pass firmware data to it then there is no real security issue. The alarming security issue is somebody running their own code inside your house in a Philips device. Now they have a key to your house data insides


I don't want another Philips Hub/bridge. I hope they don't leave it here. I have too many hubs and gadgets now.

 
The difference was that it was the light bulbs that can be updated. But the light bulbs have no access to your ethernet network or wireless network. They only have Zigbee communications capabilities. So, unless there's a way to leverage that to get something into the hub itself via Zigbee by way of the light bulb, they can't actually access your network that way. If they could have updated the hub, then yes, it would have been really bad, and that's what I initially thought was going on.

 

[LarrylLix]

 
The difference was that it was the light bulbs that can be updated. But the light bulbs have no access to your ethernet network or wireless network. They only have Zigbee communications capabilities. So, unless there's a way to leverage that to get something into the hub itself via Zigbee by way of the light bulb, they can't actually access your network that way. If they could have updated the hub, then yes, it would have been really bad, and that's what I initially thought was going on.

Thanks for the explanation.

That's the problem with most of these reports. Non-technical reports trying to make their name in cyberspace by exaggerating the problem to the point it is ridiculous. Then the public eats it up like wikipedia. LOL

 

[BobS0327]

The technical link is interesting although I am not sure why they call the attack a "worm".  Chapter 5 describes a simple takeover from a single location, device by device, and a subsequent OTA firmware replacement, not a virus-like malicious firmware spread from a compromised  device.  Also, their claim about the 70m zigbee range is exaggerated.  In my experience, it's closer to the usual 10m (30') which is not surprising for this kind of frequency band.  So, their using a drone while interesting was merely to overcome signal propagation limitation and  get closer to the target.

They probably call it a worm since it is self replicating as indicated in the introduction.  The authors describe the attack as a chain reaction attack where a newly infected lamp becomes the new source of infection for all adjacent lamps.  They compare their attack to air-borne biological infections such as influenza which is spread almost exclusively by physical proximity.  It's an autonomlusly self spreading worm.What's really interesting about this attack is that the device topology must be fairly dense in order for it to succeed.  IOW, there has to be so many devices in a given area for a successful attack.  Otherwise, it will fail and be confined to a very small subset of that area.
 
I'm somewhat confused on the reference to Chapter 5 describing a simple takeover from a single location.  My section 5 deals with the encryption primitives used to identify the AES key etc which are then used to encrypt and sign the firmware.  This section essentially deals with the first part of the attack, developing methods to encrypt, verfiy and sign OTA firmware uploads. The second (last) part of the attack is to exploit a bug in the Atmel stack to allow the exploit to take over devices from extended distances.

 

[vc1234]

They probably call it a worm since it is self replicating as indicated in the introduction.  The authors describe the attack as a chain reaction attack where a newly infected lamp becomes the new source of infection for all adjacent lamps.  They compare their attack to air-borne biological infections such as influenza which is spread almost exclusively by physical proximity.  It's an autonomlusly self spreading worm.What's really interesting about this attack is that the device topology must be fairly dense in order for it to succeed.  IOW, there has to be so many devices in a given area for a successful attack.  Otherwise, it will fail and be confined to a very small subset of that area.
 
I'm somewhat confused on the reference to Chapter 5 describing a simple takeover from a single location.  My section 5 deals with the encryption primitives used to identify the AES key etc which are then used to encrypt and sign the firmware.  This section essentially deals with the first part of the attack, developing methods to encrypt, verfiy and sign OTA firmware uploads. The second (last) part of the attack is to exploit a bug in the Atmel stack to allow the exploit to take over devices from extended distances.

I meant Chapter 6, specifically 6.2 where they describe their implementation.  They used two TI eavluation boards, one to reset a target and the other to upload defective firmware to the target.  Nowhere did the show how one bulb would preform an OTA update on another bulb.  If I missed that part, kindly show where it might be hiding.

 

[LarrylLix]

They probably call it a worm since it is self replicating as indicated in the introduction.  The authors describe the attack as a chain reaction attack where a newly infected lamp becomes the new source of infection for all adjacent lamps.  They compare their attack to air-borne biological infections such as influenza which is spread almost exclusively by physical proximity.  It's an autonomlusly self spreading worm.What's really interesting about this attack is that the device topology must be fairly dense in order for it to succeed.  IOW, there has to be so many devices in a given area for a successful attack.  Otherwise, it will fail and be confined to a very small subset of that area.
 
I'm somewhat confused on the reference to Chapter 5 describing a simple takeover from a single location.  My section 5 deals with the encryption primitives used to identify the AES key etc which are then used to encrypt and sign the firmware.  This section essentially deals with the first part of the attack, developing methods to encrypt, verfiy and sign OTA firmware uploads. The second (last) part of the attack is to exploit a bug in the Atmel stack to allow the exploit to take over devices from extended distances.

That's the rpoblem with most of these writers looking for grandeur. So many different technologies get mixed in, for examples and to grndstand the topic, when the article is done there really isn't any truth to the report any more.

 

[vc1234]

I meant Chapter 6, specifically 6.2 where they describe their implementation.  They used two TI eavluation boards, one to reset a target and the other to upload defective firmware to the target.  Nowhere did the show how one bulb would preform an OTA update on another bulb.  If I missed that part, kindly show where it might be hiding.

Further, the quote below shows that they simply uploaded a bunch of bits to a target device, not a  valid Atmega firmware image.  If so, other than being incapacitated, the modified node could not possibly propagate the said blob to other adjacent nodes.  If I am right, their "worm" claim is rather specious.
 
"
The CC2530 OTA upgrade file was modified by changing the hardware type and image file size to fit the requirements of the bootloader on the new hardware, so the bootloader on the ATMega2564RFR2 would attempt the verification process. The actual verification will fail as this was not a valid OTA image for this platform, meaning we were able to perform this attack without having access to a valid firmware image.
"

 

[BobS0327]

I meant Chapter 6, specifically 6.2 where they describe their implementation.  They used two TI eavluation boards, one to reset a target and the other to upload defective firmware to the target.  Nowhere did the show how one bulb would preform an OTA update on another bulb.  If I missed that part, kindly show where it might be hiding.

 
I've copied a section on page two from the introduction...

Finally, previously reported attacks are carried
out via linear scans and infections which are all carried out
in a star-shaped structure with a centrally located attacker,
whereas our chain reaction attack spreads much faster by
making each infected lamp the new source of infection for
all its adjacent lamps; the attacker only has to initiate the
infecting with a single bad lamp, and can then retire and
watch the whole city going dark automatically.

 

[vc1234]

As I wrote earlier, according to their article, they did not have a valid atmega firmware image to upload to a bulb, so they modified the cc2530 bits to make them acceptable to the lamp atmega bootloader.  As soon as the bulb mcu would try to execute the uploaded image, it would become instantly dead, not able to communicate to anything, much less perform an OTA on its neighbors.
 
Reading the article, carefully it is doubtful they did even that.  What they describe in 6.2 looks like the first TI board made the device get dissociated from its current network and the second TI board included the device into its own network.  After that, they could control the lamp and perhaps upload the invalid firmware.  It is not altogether clear from the Chapter 6.2 they did the latter.  Nowhere did  they say "after the firmware was uploaded to lamp 1, lamp1 connected to lamp 2, performed an OTA on lamp 2, etc".  A chain of events of this nature would be simply impossible for the reason I mentioned above.
 
It is strange that they described the exclusion/inclusion process in detail, but did not elaborate on the most interesting firmware spread part other then the cursory paragraph you've mentioned. Absent this sort of description, it appears that the "worm scenario" is at best a hypothetical.

 

[ano]

True for older chips but OTA updates were added to the Z-Wave protocol with the release of the 500 series chips and Z-Wave Plus. This is pretty common now. We've released firmware updates for our HSM200 multi-sensor and our HS-WD100+ and HW-WS100+ wall switches.

I stand corrected.

 

[vc1234]

Phillips redux:
 
"They did not create a virus nor disclose information necessary for someone else to do so."
 
http://www.newsroom.lighting.philips.com/news/2016/20161103-media-alert-reports-of-philips-hue-products-being-infected-by-a-virus-are-inaccurate.html

 

[BobS0327]

Phillips redux:
 
"They did not create a virus nor disclose information necessary for someone else to do so."
 
http://www.newsroom.lighting.philips.com/news/2016/20161103-media-alert-reports-of-philips-hue-products-being-infected-by-a-virus-are-inaccurate.html

That's really incredible. The Verge video gives the impression that the academics/researchers actually exploited a Zigbee vulnerability and used that vulnerability to propagate a worm (virus) throughout a given area.  These researchers should have at least made it clear that this whole experiment was just theory not an actual proof of concept. 

 

[LarrylLix]

Leave it to the editorialists.

But if a security problem didn't exist, why would Philips encourage everybody so strongly to upgrade their Hub firmware?

I wouldn't take the chance of bricking my Hub. The security risk of hacking, that doesn't exist, isn't worth the security risk of their new firmware bricking it.

 

[vc1234]

That's really incredible. The Verge video gives the impression that the academics/researchers actually exploited a Zigbee vulnerability and used that vulnerability to propagate a worm (virus) throughout a given area.  These researchers should have at least made it clear that this whole experiment was just theory not an actual proof of concept. 

Yeah, having spent some time in academia in my previous life, the bombastic claims of that nature would have been scandalous then, especially in engineering...
 
Just pointing the company to a vulnerability and writing an honest article or two would have been good enough.

 

[wkearney99]

I wouldn't take the chance of bricking my Hub. The security risk of hacking, that doesn't exist, isn't worth the security risk of their new firmware bricking it.

 
You wouldn't, but someone putting forth the effort to snoop the hardware directly would presumably also be figuring out a way to avoid bricking situations.  The more 'off the shelf' the components are, the greater the likelihood of someone being able to work around potential bricking problems.  But COTS hardware is what helps drive down costs of components. 

Given how Philips tried to 'pull a fast one' last year it's not terribly surprising to hear of them being targeted for a hack like this.  Raise the ire of the techies at your peril, especially when it's nothing more than an attempt to force a proprietary 'upgrade' on existing customers.  Funny how that makes people mad.

 

[ano]

Given how Philips tried to 'pull a fast one' last year it's not terribly surprising to hear of them being targeted for a hack like this.  Raise the ire of the techies at your peril, especially when it's nothing more than an attempt to force a proprietary 'upgrade' on existing customers.  Funny how that makes people mad.

In fairness to Philips, I really doubt that the company was out to deceive you.  Maybe they didn't test enough, maybe an overworked engineer was just trying to get a product out because his boss was being told by his boss that the product had to be out no matter what.  If you look at the range of hacks that have occurred in just 2016,  the probability of hacked light bulbs caused by firmware downloading drones probably wasn't at the top of their list.