IoT Goes Nuclear: Creating a ZigBee Chain Reaction
iotworm.eyalro.net
iotworm.eyalro.net
How else do you explain how woefully unprepared we are?
When attacks can be trivially copied, even obscure security issues can become easily exploitable problems under attack from bulk exploitation tools.
For as many of these REAL security issues we face, there are many stories published that have no real-world impact.
Examples: The story from defcon (or blackhat, cant remember which) about installing ransom-ware on your smart thermostat.
The headlines were all "Hackers make thermostat ransom-ware" or "Your smart thermostat is now vulnerable to ransom-ware"
A few points: - It required local access - It required an SD card reader - It also required the thermostat run a local HTTP server
Another decent example were the SmartThings security holes from earlier this year: - It was mostly an oauth2 authorization issue (applications requesting grant types it didn't need) - The apps were actually independently developed (not ST official) and took some technical knowledge to deploy yourself - The rest were known security issues in the Zigbee protocol that SmartThings has little control over. Similar to this article.
Or the botnet of cameras which is probably the most high-profile example and most relevant are labeled as "The IoT brought down the internet"
That's a lesson for the makers of those cheap DVRs and Cameras, it was also a lesson in user documentation to avoid them doing stupid things. That's the only example in recent years I've seen that goes anywhere, but the problem is it's drowned out by nonsense and clickbait headlines.
In fact: the finger-waggers have been right about this issue since approximately 1988, when Paul Graham's friend shut down much of the Internet with a tiny C program that shouldn't have been possible to write back then, but is in fact still possible to write in 2016.
I'm becoming more and more convinced that nothing is going to change (with regard to overall security in general) until we have some huge event that negatively impacts a large portion of the population in a major way. Until then, things will continue as they are, and security won't be taken seriously.
I'm ready for the 2016 version of the 1988 sendmail worm (or perhaps something with the "average user"-visible impact of the 1990 AT&T crash), just to "get it over with" and get us moving forward.
"We can't keep driving these and feel good about ourselves. So something needs to be done and I just want an answer.… It's not about the initial mistake — it's what you do to make things better." http://www.cbc.ca/news/canada/toronto/vw-emissions-1.3708372
Edit: Sorry everyone! I just saw it! Thank you! For those who see this: https://en.wikipedia.org/wiki/Morris_worm & this: https://www.cs.cornell.edu/courses/cs1110/2009sp/assignments...
Fascinating stuff... Thanks for sharing!
http://cs.dartmouth.edu/~vibhu/wireless/PIPExploits.pdf
Basically control frames run in the same band as the payload data, so if you put a ZigBee header half way down your packet and cause some noise, the inside application data turns into a new packet header. You can't do this on 802.11b/g/n/etc because the control data is send out of band from the application layer data.
It's considerably different from the attack mentioned in this post, but we've know at least that the protocol has been broken for years.
Anyone in tech with two braincells to rub together could tell you that security is a hard problem. And yet there has been a consistent pressure in IoT enthusiasm which rested on the premise that security was a solved problem. Everything about IoT went against decades of hard-won wisdom about internet security: lessen your surface area, keep as much stuff off the internet (behind firewalls) as possible, constant vigilance through patching and staying up to date on vulnerabilities is important, use strong credentials to secure anything that could ever be reached from the internet. In short, that internet security was a big and difficult job, and a constant battle that required careful risk management.
IoT enthusiasts dismissed all of that and never had a good counter-argument, just the insistence that nothing, not even security issues, should get in the way of how cool IoT devices could be.
It was obvious that this would be a problem. And every security expert made mention of it. There is no "oops, well how were we to know?" about it.
What do you mean? This is an expected outcome of the "ship ASAP", "competition uber alles" culture, rewarding short term gains over everything else. Our whole technological ecosystem was built on this mindset.
The solution of course is alternate economic structures that respect the commons. The distinguished economist Elinor Ostrom wrote a whole book called Governing the Commons which presents real-life alternatives to markets for commons-like economic activity.
Or we could continue marching to the drum of neoliberalism and try to contort markets until they meet our needs. Love me some procrustean capitalism.
Market forces are really powerful. See Samsung's recent troubles -- once everything was fine, and then -- BAMM! - their phone sales went down without any external regulation. (pun intended.)
Let's not start claiming the internet itself somehow qualifies as a "common", because with common ownership rationally comes common censorship (as with the FCC and public broadcasts).
Security is indeed a commons because the overall security of the ecosystem only benefits each person weakly, and so every actor rationally benefits by neglecting security.
External regulation isn't the only way to address commons problems. Manufacturers can see the writing on the wall and work together to solve issues, but only if the public pushes them to.
I'd say it absolutely requires a high-impact case, something like downing of an airplane, or a cyberattack that sets half of the city in flames. Otherwise, any concern of people about security will quickly get papered over by marketing - as it always is.
The analogy here is more like the latter: It is better for Manufacturer X to rush their IoT device to market to maximize profits, ignoring security concerns. If every manufacturer does this (the person in front of you at the stadium just stood up, so you stand up too), then whoa, we have millions of insecure devices waiting to be exploited. This is indeed a tragedy of the commons.
The vendors of Thread devices probably care even less about security and, for instance, choose to make every single one of their devices Internet-accessible instead of creating gateway apps for a local mesh network of devices.
http://www.zigbee.org/zigbee-alliance-creating-end-to-end-io...
Me: "Yes triple-DES is reasonably secure, how do you exchange keys?"
Them: "That is part of the connection setup."
Me: "Great, how do you protect the keys during setup?"
Them: "What do you mean?"
Me: "What form of encryption do you use when you're doing the setup, and sending over the keys?"
Them: "Well we really can't encrypt the setup part, after all we haven't even set up a connection yet."
Me: "Ok, and thanks. Now move along, we'll call you..."
This is how the top comment starts on the HN thread about the ZLL master key being published, two years ago:
"This may not be much of an attack. The master key is used only during "commissioning", when a controller is introduced to a light."
So the vendor who is thinking about it, would have told me about their public key system which is used in the initial transfer to protect the secrets. Then they would have described how they can upgrade and change keys over time as attackers gain the upper hand on various bit lengths, and how the elements of their system that depend on randomness, do so without being susceptible to a birthday attack or an algorithm attack on their PRNG.
When they do that, I know they've been thinking seriously about how such systems are built and deployed and there is some hope that doing the do diligence "deep dive" will show me a solid system.
Without authentication asymmetric encryption is still useless, because someone could man-in-the-middle your key exchange, swap out the public key that is sent both ways and make either side think they now have a secure channel with each other while in reality they have a secure channel with the man in the middle.
So the challenge is that they'll need some equivalent of what in the HTTPS world would be a Certificate Authority. For which you'll have the same kind of update/upgrade path questions that you very rightfully ask for the key lengths.
Of course not all situations need that, but understanding what the endpoints are trying to achieve and how that objective could be compromised by an attacker will inform on which identities must be established, and to whom, in order to achieve that objective.
global AES-CCM key that Philips uses to encrypt and authenticate new firmware
(I can already imagine how the idiots fixed this: by drawing another set of bytes for a new "authentication" key..)
I wonder how many years until there are fewer than 15000 vulnerable Hue devices in Paris...
We should hold manufacturers accountable for not aggressively pushing security updates on their users.
There's really no way to /force/ companies to support products they release like that. The company may not even exist a few years down the road. You could force them to release the firmware source so the users/community can patch it themselves but I don't see a way to do what you're saying.
Also, the market would be harder to enter. I don't see a problem with this.
First world problems and all.
I'm glad I bought up a stockpile of incandescents before they were banned.
I stockpiled too. and I have dimmers on pretty much every lamp (including the toilet), so the bulbs last for a very long time. when you don't burn them on full wattage they last much much longer.
It's not even possible to get two ZigBee products from different manufacturers to operate (like a switch and a lamp).
The attack can't succeed at what the industry's been failing for 10 years.
> It's not even possible to get two ZigBee products from
> different manufacturers to operate (like a switch and a
> lamp).
And indeed, if someone were to implement this, they would basically have built a standard ZigBee inter-device communication protocol, by using existing software features (bugs), in otherwise incompatible devices.
This is not too far off from something like Stuxnet, so -- given enough available capital -- it should be possible.
I was indeed half-joking, half-serious. Actually, aren't there cases where viruses (the biological kind) have ended up serving a function in the DNA machinery of multi-cellular life-forms? Would be a funny parallel.
Lemme me give a simple illustration. You know that wifi has different encryptions standards: WPA1, WPA2, WPA2-something, TKIP, AES (and mixes of those).
Now, imagine that Zigbee has no encryption standard, each manufacturer invented something of his own. [That's a simple example of a piece of the L2 layer. Trust me, ALL the upper layers are are even more of a mess :D].
There are thousands of bugs in Zigbee devices for sure, but they are specific per device/firmware/network stacks. Not cool enough for a fun apocalypse.
(Is it the same content?)
This is also why you're starting to see more and more devices opt to a completely device to cloud infrastructure instead of local communication. More control of the stack on device and in the air.
http://www.zigbee.org/zigbee-alliance-statement-on-security/
What's the right protocol to use that doesn't have horrible vendor lock-in? ZWave has some chip licensing requirement, doesn't it?
If you want to investigate further replace the "return r;" in the very end of those two "evals" with "console.log(r);" then get the decoded code from the browser's console. Then run through code beautifier (built-in in Firefox JS debugger) to get readable code. But there are more code obfuscations later, though easy to reverse but I don't have the time right now.
View Source reveals that this site is actually an iframed version of http://www.wisdom.weizmann.ac.il/~eyalro/iotworm/.
I hate these catchy titles.
Surely chain reaction is a member of this set, but not the only thing. Sure, most nuclear devices we hear about use the chain reaction (power plants, bombs), but an x-rax machine is also somewhat a nuclear device.
Sometimes we even induce neutron capture, which is the opposite of chain reactipn (afaik to create some special isotopes, or to start/sustain a chain reaction).