Daniel Buentello is one of the top security researchers out there looking into the security of common, consumer products that are part of the growing “Internet of Things.” Most recently, Buentello has been making the rounds of security cons with a presentation he calls “Weaponizing Your Coffee Pot.” The talk, which Bountello presented at the recent DerbyCon hacker conference in Kentucky and at ToorCon in Seattle in July. That talk was something of a call to arms for security folk to start poking around the growing list of IP-enabled consumer products. Buentello notes that most – including products from large firms like Belkin are insecure by design and in deployment.
As we noted when we wrote about Buentello presentation early in October, the interesting stuff here is Daniel’s methodology for reverse engineering the software that runs these commercial developments, which offers something of a blueprint for others to follow.
More recently, Buentello turned his gaze to the über-popular Nest “smart” thermostat, which has become the poster child for The Internet of Things – an object lesson in how software driven, smartly designed and cloud-connected devices will transform our physical spaces. Under the hood, however, many of these devices – the Nest included – fail to live up to their slick and polished exteriors and graphical interfaces. (Our recent story on the IZON was another case-in-point.)
Buentello works as a security analyst in the IT security industry, but conducts research in his free time. He recently published a deep dive analysis on the Nest, with a detailed analysis of the inner workings of the world’s coolest thermostat. In this exclusive interview with The Security Ledger, Buentello talks about what he found and how the design of the Nest and its inner workings suggest how it might be used in the future, and also how it might be attacked.
Security Ledger: What do we understand about what NEST runs under the hood and what cool hacks might be possible using the current hardware and software?
Daniel: It runs Linux. Because it is an embedded system though, it is at the mercy of the update cycle of the binaries/kernel. If you take a look at the software history on Nest page you can see that they avoid updating binary code. It’s common practice to do this with embedded systems for fear of breaking. This type of practice will change as these devices start becoming smarter…I hope.
Security Ledger: Nest is a powerful device and that there are a lot more capabilities built into it that are either placeholders for now (not implemented) or where the purpose of the hardware isn’t clear. Zigbee is just the most glaring example of this. Did I get that right?
Daniel: Yes, but lets not use Zigbee anymore. An article was recently posted that gives some insight as to why we shouldn’t refer to it as Zigbee. Nest, instead of using a vetted standard, has developed a proprietary protocol that is used by their family of products. This is something I’m investigating and I will have more details soon. Now back to your remark. Nest deliberately strays away from specifics about hardware and instead focuses on what the hardware provides. Apple has a tendency of doing the same thing. I think is smart from a marketing/sales standpoint but from security perspective it isn’t. Especially when the device is packed full of sensors. Another thing that was mentioned was how the smoke detector can “enhance” the Nest Thermostat capabilities via its motion sensing capabilities.
Security Ledger: You say that Nest (the company) is doing a lot of pretty cool things to allow it to function that aren’t well explained or documented. The bit you discuss about how the device charges its battery by starting and stopping the heater is a great example. That’s a cool hack and, for many homes, something that wouldn’t even get noticed (because there’s a significant lag between the heater turning on and the burner firing.) Still – it doesn’t totally sit right. If the device is surreptitiously cycling my burner on and off just to power itself, what else might it do. You know? What are some others?
Daniel: Good question. It’s hard to answer without being speculative. I will say one thing. The 2 gigabytes of flash is very interesting. You’re talking about a firmware size (for both processors) of about 38 megabytes uncompressed. Even if it kept as a backup firmware for fallback, in case of a bad update, then you’re left with 60 megabytes, give or take. Then you have other mounted partitions that aren’t included in the firmware (like user settings and boot variables). Maybe your thinking 256 megabytes of flash at the most.
The Nest team is smart. When you look at the board it is clearly evident they designed this board to be efficient. Not only with space but cost. Why spend the money and put 2 GB? My guess: this stores your schedules. After all, the Internet access isn’t required for the thermostat to work (hence the local storage). Still 2 GB is a lot. This is something I will be looking into. For now, I ripped the flash destructively so it can’t be read from the board.
Security Ledger: You make the point that – unlike some other Internet of Things products – Nest isn’t an easy target for remote attack. There are no exposed ports, there is no direct logical access from smart phones. However, it is a device that could be manipulated directly (via the mini USB port, etc.). That’s a less likely scenario, but possible. I’d be interested in knowing what you consider the most likely attack scenarios that don’t require hacking the Nest cloud?
Daniel: The 802.15.4 protocol. 802.15.4 was created for low power/low memory devices such as embedded systems. Another thing it was designed for was mesh networking. This make its perfect for Nest future ecosystem. The smoke detector talks to thermostat and vice versa. This is happening over a network that we don’t normally interact with. It was designed for more autonomous systems, like smart meters. A possible attack vector would be a criminal (keep in mind the average criminal is adapting to technology, take a look at the Nordstrom card skimmers) driving around “sniffing” or war driving for these networks — listening in and seeing if anyone’s home. They could do this from the comfort of their car.
Security Ledger: Speaking of which: hacking the Nest Cloud? How likely an attack scenario is that? In your presentation, you make it look pretty dire (“I control tens of thousands of homes!”) but would it be that bad? Is a Nest botnet possible? If so, is it probable, given the current device capabilities, security, etc.?
Daniel: The situation here is a lot worse than what meets the eye. In fact I am working on a report that goes deeper into this. (It is still about 6 months out. I need more targets and data). Long story short: this is the monetization model. Sell the cloud. After all, my home isn’t running a public server so how can I change the temp in my home from the baseball game (keep other items in mind like connected door locks and appliances, a dishwasher that broadcast a push notification when dishes are done). As a result I can see more of these “appliance” clouds coming online. How do they recoup the cost is up in the air. It’s still too early. Maybe they charge directly or sell the data. They will find a way.
Anyways, here you have all these appliances connected to different clouds talking to different apps on your phone. But wait, how do they communicate? The web! These connected clouds are basically web apps without a user interface. We both know web apps can be hacked. So instead of your phone making a perfectly normal API (application program interface) call to the Nest cloud, you start fuzzing it. Find vulnerabilities. This actually happened to a lot of social site iPhone apps (Facebook, Etsy, etc…). Researchers were intercepting the API calls and substituting different fields to see what happened. The developers took for granted the lack of a traditional user interface (a phone) and were caught.
If you saw my Belkin hack earlier this year that is basically what I did. I took a response from the Belkin cloud and modified it. The call was to update its firmware. I redirected the device and told it to get the firmware from my website. I was then able to sign the firmware and make it look legitimate because Belkin left the global encryption keys on all the devices. This was huge. If I really wanted to. I could have found a way to break into the Belkin cloud and issue an update that would make it impossible for them to regain control. I wouldn’t even have to hack Belkin. Just social engineer a DNS registrar (like what the KDMS team did with Rapid7.) All the Belkin devices could point to my IP instead of the legitimate one.
But it gets better. So now we are in a situation where you have web apps (which are vulnerable, just look at all the bug bounties that are out) that don’t have a GUI. Developers are less likely to use secure coding practices, there aren’t any buttons to click (or forms to input malicious data). But lets give other external entities an API. After all, we need these different appliance clouds to communicate (this is what Nest just announced). Here is another attack vector.
Security Ledger: What do we understand about Nest’s environmental monitoring features, especially the motion detector, etc.?
Daniel: I sort of hinted at this earlier. But the software/hardware is smart. Take for example the Nest Protect, It has to take into account a waving hand telling it to “hush” and people running from a fire. Assuming it’s hyper accurate, it makes sense to do what Nest is doing. Make one product feed the other. They have already gone on record and said the thermostat will use the protect to detect when someone is home. Me personally, I love it. Me as a privacy/security advocate. This is scary.
Security Ledger: Thanks for taking the time to speak to Security Ledger, Daniel! We’re looking forward to reading about more of your research!
Daniel: Wow…Im mentally drained (good questions!). If you have any followup questions feel free to ask. If I caused any confusion, please let me know. Thank you.