 My name is Jeff Kitson. I'm a Securities Researcher with Spider Labs Trustwave. My presentation today is trainwreck. Today is not only my first time at DEF CON, but it's also my first presentation of this type. So I think we'll do all right. If I have to take a couple of breaths, bear with me. So what I want to talk to you about today is the device that, of course, we're focusing on how I found this device, how it sort of entered my realm of knowledge, the vulnerability that I found, how we got the vendor to fix it, and then the tools that I'm going to distribute to you guys so that you guys can actually test these yourself and keep the pressure on this manufacturer to make sure that they stay up on their security stamps. So how all this got started? It's a pretty personal story. On December 29th, my furnace failed. I'm a first time homeowner. It was a pretty big experience to have my furnace fail in the middle of a Michigan winter. I don't know how many of you are familiar with Michigan or just winter at all, but it sucks when your furnace fails. And it can be pretty dangerous, especially to the water pipes in your house. So I couldn't really delay on getting it fixed. I had to call up a manufacturer and have them come in and evaluate the situation. The problem that I actually had at the furnace was my heat exchanger failed and started developing cracks. And that's how you get carbon oxide in your house. So I'm actually kind of lucky I didn't die from this. Yeah. You can see it about two pipes. Well, not on the monitor, but later you'll be able to see them. So I had to get a new furnace. I felt a lot like this kid here in the photo. I called up the local dealer that had worked on my unit in my house before and they came out and really acknowledged that it wasn't safe to operate how it was failing. So by law they pretty much had to turn it off and I had to buy a new one. Now the model that I selected was a little bit more efficient than the last furnace because when you're looking at replacing a furnace or replacing a heat exchanger it's about a whole day's worth of labor to get the exchanger replaced or you can buy a new furnace which is more efficient and it's going to get you a couple rebates, better power bills, better gas bills so it was worth it to get the new furnace. The furnace that I chose was a trained furnace because this dealer was a trained dealer and it came with a smart IoT thermostat. It wasn't really an option. It came with it by default. They say, oh, you want one of our new furnaces. Well, our new packages come with smart IoT thermostats. So you get it because it's required for the device. And it's called an XL850. So what exactly did I buy? To be honest, the day of I wasn't really sure because it just sort of pushed on you. You're in an emergency situation where you have to buy a new furnace. You think you're making the best choice. One of the reasons that I made this decision also was because I knew it was an IoT device and that kind of whetted my chops a little bit and I didn't go for the model above this because on that one, this smart device actually modulates the gas valve. I didn't quite feel comfortable playing with that so I stuck in the area where I was comfortable. So if we want to get technical and we do, because this is DEF CON, the device is the ComfortLink 2 XL850. And this is one of about three or four models that Train pushes out with their different units. And you can see the manufacturer's page here and a couple of links that'll be pretty relevant. One of the things you'll notice on this page is that there is a download for software update. This manufacturer allows not only over-the-air updates but you can download it yourself, load it to USB, hook it into the device and then it'll evaluate it, see if it's valid, and boot the new image. Now if you go to that page today, you won't see that link there anymore. Apparently they decided the best way to deal with this notice when they got it was to quickly remove the ability for people to upload their own software. But the links still happen. So the features this thing has, it's got a lot of features, particularly it's got lots of internet. It speaks Z-Wave, so it works as a Z-Wave controller. This thing is meant to go out and touch the other things in your house and interact with your whole Z-Wave environment that you have working. It has an integrated Nexia bridge, so a Nexia bridge on its own is something that's meant to control a lot of different devices in your house and provide a lot of functionality. You can remotely set your heat schedules and your cooling schedules either from a phone, your web interface, or the Nexia admins can do it on their own if they really wanted to. It can also send notices, so let's say your furnace starts failing in a really bad way, like I had with my first one. It can dial out to Nexia and say, hey, there's a problem. It'll fire up an alarm on your device. And in certain cases it can actually shut off functionality until you have the installer come out and fix it. The service that you pay for, it's about $10 a month to get all access to all these Nexia features. And one of the main ones that you see on the device is you get a cool weather map and local weather updates. And those are all actually pulled from weather underground. And they don't really control the requests that just goes right out to weather underground. And one of the more interesting features for us is the device will do over-the-air updates. So it does request to Nexia to see if it's got, or to train, to see if it's got a new update package and it will download it and load it if it validates against all their checks. And then, like I mentioned before, you can download or you're supposed to. I think they intend to keep this feature. They say the new link is coming soon. But you can download the software package, load it onto USB, and when you plug that in, it pretty much does a quick evaluation and will boot it. And it's worth $4 a sign, whatever that means. I still to this day don't really know how much it costs because it comes as a bundle deal and you can't buy them separately on the Internet. I think roughly it's about 300 bucks, so I was hoping not to break it within my research, also because I just got the furnace replaced. So the first day that I have this, I poke around on it constantly. And the first thing I see is a RubyGems license in the about page. Thank you, open source. This let me know that I had some ground to work with because I'm a Ruby guy. Most of my daily work is done in like Ruby, Python, things of that type. And having this type of disclosure of the gems, awesome. And you can see there's about 187 pages of open source software licenses that are included on this about page on the device. That was awesome. I was really excited to see that. Now, I know this thing has code that I can work with if I can get into it, and I want to do a basic smell test to see what's available on the device. And there's a ton of ports open on this thing. Way more than you would expect if this thing had a good security policy. One of them in particular came back as Napster, according to Nmap. Well, the thermostat isn't running Napster. I wouldn't be surprised if it was based on the research that I found. But this port 9999 stood out to me as really the most interesting one of the ports that I was able to scan. So I start poking these things. We're just using basic NCAT commands and attacking these ports, and you can see there's two of them that just take command prompts. They say, hey, give me a command. You've connected. This is fantastic. Those aren't even included in this presentation. But there's lots of opportunity for it. But we go back to port 9999, and this thing is obviously issuing an authentication challenge. It's giving us a couple of random numbers and wants something back from us. All right. You still have my interest. So now this is the focus of my research, and I want to see if I can break into this code to find out how this port actually uses commands. So that tarball that I mentioned earlier, that you're supposed to be able to download from the manufacturer's website, but you can't right now, unless you get to the proper link, it's got a couple of cryptic files, no extensions on them. They're trying to hide this from basic people with no knowledge of files or security or anything like that. The number is pretty much a build number, and you can see the 850 there in the beginning of the number. That's the platform number, and that's pretty predictable based on what thermostat you're working with. We run the file commands to see what this actually contains, and we see a couple of things. One is the image, and a couple of ASCII text files. Well, the first thing that I did was I opened up this other tarball, and what it contained was a utility folder with all the verification checks for the software image. They come shipped with the new image in this folder. It could just be me, but I don't think that's a good way to package verification checks with the new image. It seems like you could really just as very least they give you good insight onto how they do the verification for the software. So it would be pretty easy to reverse those and try and boot your own image. Here's the manifest file. It's got a couple of things in here that are worth noting. At the bottom you'll notice it's got a switch for the boot message that says am I trained or American standard? Well, I was focused on this device being my device. Mine is a trained unit, you can see the check sums. It's really just sizes and a couple easy things that are pretty quick to pick out from the verification checks noticed in the other files. So this makes it really easy to understand how the software is packaged and how to build a new one. And like I said, it takes over there updates and USB uploads. My main focus turned toward the actual UBI image. There's a number of ways to mount it here to interact with it, but I was able to find this tool and if you guys know this guy or if he's here, I'd like to buy him a couple of beers at home. It made it really easy to do a point and click tool, tear out the file system, and then I had a folder containing all the entire file system. So it was a Linux file system with a bunch of Ruby gems and I had a busybox arm binary buried in there as well. So I had a file system exposed and this makes it pretty easy to search through it and look for key strings and vulnerable issues. I searched for things that you would think of right away. Passwords, users, enrollment, alarms, registrations. These are all things that I had a bunch of hits for. These weren't things that I tried. These are things that are very common in the source code. This slide is a little bit ugly for the eyes, like a regex matcher, overturn. You see a lot of calls for constants, the schedules, alarm histories, registration call out. This really lets you know how vulnerable these calls are to reverse engineering just by searching for these particular strings. You also find a lot of samples in passwords. Particularly they even have old commented out passwords. I don't know if this is some guy's dev password, or if this is a password still used on a production machine, but it seems like this is sort of a pretty common approach for how they would handle issues. I'm going to guess that this is probably their patch for a previous security problem. And hard coded passwords are obviously always a bad idea. And they definitely are. The command up there at the top, you'll notice is actually a sample command for how to set the heat. You can change it a little bit, so it's not copy and paste in order to be able to update the thermostat temperature or something like that, but it gives you a really good idea on where to start. Now like I said, this thing was written in Ruby. That means it comes with gems. Gems come with specs. Specs tell you what everything does. So in most of the instances, I could change into the director of the gem, do bundle install, and I was able to download all the production gems that they had on their basis. I can actually kick up those specs and recreate the protocols and all the faceplate messages. Anything that this did, and they wanted to check, it was included in these gems and it was reproducible simply by running specs. That's a good password, right? Now, their entire GitHub repository was pretty much open. They had a bunch of production repos on Nexia that were for ESX servers, production backbone servers that dealt with the faceplates and the different thermostats. These were all easily downloadable and they were wide open. We had to contact Nexia, who's a partner train, a partner with train, and actually tell them, hey, you've got database salts, production machine configs, and all this publicly available on your GitHub. The first response we got was, no, we intended that. And then we had to go back and be, are you sure? And then they actually pulled down a lot of the repositories and these are the ones that are actually still up there today. Not the ones that they pulled down. So we've got a good idea of what this thing does and all the features that we can probably get out of it. We know everything Nexia can do. We've had a good look at the source code. We found a lot of valuable information from the source code that we've been able to examine and it all sort of comes back to this language called smile or perhaps smell. I'm not too sure. I found examples of it in documentation on the internet. They loosely fit with how Nexia actually implements this protocol or this system. And it was the best correlation I could find, but as far as we're concerned for train and Nexia, they really use it in a way that we could consider proprietary. There's not too much correlation with outside sources that I found, so it's pretty loose correlation. Again, I'm not exactly sure what the next or what the acronym other than this stands for. I assume that this is the best correlation. It's the synchronized multimedia integration language. The RFCs in documentation I was able to find online point to XML files with really customizable nose and I found a few of those that actually have an inventory of all the features and models contained within this device. So what does it do? Everything. Everything this device can do, and that includes not just the stuff the user can do, but anything the remote administrators from Nexia can do is available from this protocol. And that's a lot. It was actually a bit disturbing to see how much other features were included in this device that weren't even visible from the user interface. And as a user, you would never know that it just sends analytic data no matter what. So this is one of their regex expressions for evaluating this plain text protocol that we saw in the challenge issued earlier. This is theirs, not mine. If it passes this test, the device will start evaluating it. That doesn't mean you're going to be able to necessarily fire a command simply by bypassing this check, but it will consider it and it will start considering it valid data and it will compare the information you give it to the models contained in the device. I would expect a little bit better checks than that. The constants file that they use, and they use constants everywhere, it's not just a pattern of having hard-coded passwords, hard-coded server endpoints. You can see here they have things for the alarm sessions, chat sessions, registration and enrollment. These are all the core features of this thermostat. And they go to all the features that you pay 10 bucks a month for a private git repository, like $7. So let's log in already. We know a lot about the port. We know a lot about the file system. We have a good idea of all the features we can do. Remember, you can remotely administrate everything on this from an app, from a website. You can change your temperature, change your schedules. If we can log in and start playing with this, we should be able to gain a lot of control over the device. So to get past the challenge that you saw earlier, it was actually pretty simple. Command up at the top is how Nexia manufactures the authentication command that it sends the device. So we do a SHA-1 hex digest of a couple of the values that we get back from that initial challenge, spit it back to the device and re-authenticate. It's hard-coded passwords done with a SHA-1. You spit it back and you're in. So this is the same for every single one of these thermostats running this version of the software. Hard-coded credentials always come back to bite you. And when you authenticate and you issue a basic command, you get flooded with data. You can see here that there's a number of different model IDs that we get back. There's a lot of different type of data. Some of it's plain text, some of it's wrapped in protocol buffers, and it's a little bit difficult to understand. Subscribe, true. This floored me. When I ran this command, of course, I was able to authenticate with the device. I know the basic model structure of how the IDs work and the type of commands that it expects, so I start from the bottom. I give it a 1, I give it subscribe, which I know is a valid command, and I put in true. I noticed a couple switches in the logic that seemed to evaluate whether or not true was the entire payload. What I found out was that if you give it true, it will dump every recursive element in every child node or the ID you give it. So this thing has sort of like a domain structure, so it'll be like 1, 1.2, you know, it goes on from there. So when you give it 1 subscribe, too, you see the type of mess that you saw on the last slide. It gives you everything. That includes all the plain text information about the device, sensor readings, dealer diagnostic data, alarm history, everything. I don't know why I would actually enable this on a device, other than simply for ease of use of their own use, but it was horrible. I was flooded with data after I actually fired this command, and when you do subscribe, you stay connected. So as far as this thing was concerned, I was now an authenticated valid server, and I was properly requesting all the information this thing had, and it was just constantly spitting it out to me. So I'm flooded with data. It's a good understanding of how these model IDs actually work. So what I did is I built a script, and I let it run for about a day or two, and I played with my thermostat, and I swallowed up every single payload that I got from this socket, and saved it to a Redis database, breaking apart with the Regex matches that I saw in their code. So now I have an overtime inventory of all the different permutations of the device IDs, at least a report from this port, and also the command payload. So I can go back and do analysis on how frequently a certain ID occurred, what type of commands are the most popular, and what type of payload structures are the most popular, or perhaps the most powerful. Because remember, we've got different levels of things we can access, like alarms, the temperature, chat history, also authenticated callouts. So the things that I, of course, tracked were the authentication IDs. Every time you connect with this device, you get a new auth ID. So those were worth tracking to see if they were predictable. The command IDs themselves, so that domain system that I mentioned earlier, that will recursively dump all of its elements. We tracked those as well. And then the command payloads. We want to know how these things are built, and this made it super easy. I mean, this really took a lot of the research out of it, simply by being able to interact with the device over a couple of days to get all that data as an inventory. And this is how we process that. This is really it all it takes to probe this socket, this 9999 socket, and get back intelligible data. So this is the Regex, and the method that I use to actually interact with the socket, get back the data, and save out the stuff that I got so that I could analyze it later. And I didn't really have to change it at all when I changed this to an active script, because it was so spot on and useful. This is what everyone wants, right? We're dealing with an IoT thermostat. We want to know if we can change the temperature, heat point, cold point. And if, like I mentioned earlier, I'm in Michigan. So if someone plays with my thermostat and sets off my heat to zero in the middle of winter, I'm screwed. When your pipe's free, it's a really expensive problem. And when your house burns down, it's a more expensive problem. And we saw earlier with how my pass furnace the heat exchanger failed. It could even be a deadly problem before your house burns down. If someone keeps your burner going and it's constantly working on the heat exchanger, that might fail and start pumping carbon oxide into the house. And if you have controls over the alarms that set off on this device, you could prevent it from actually raising an error or dialing out to back home. You guys probably remember this command that we saw earlier, this sample. It's a good indication that we can set the type of IDs that we've been talking about already and then the set hold command. And I was able to track this down to the models included in the XML file that I referenced earlier and start analyzing their structure in order to recreate this command. This command here at the bottom is the one that I actually used to set the heat and the cold. And it works. Every single function on this device is set up in this file. Anything that's can possibly do is set up in this file. And there's a couple of interesting things that illustrate why the Redis script that stored all that data was relevant. You notice the N here in the model ID. They use dynamic IDs for a number of elements in this device. So you can't just really copy and paste. You have to have intelligence on what you're actually working with. And to be able to process the data you get back, identify certain parameters and then you can use that to actually set these update commands. So to get this command to work, you actually have to query for the zone that you want to update. You can't just say, set the heat. You have to say, well, what do you even have? Do you have one zone? Do you have two? Because these things are definitely in a bunch of homes, private homes, which is pretty scary. But they're also in a lot of commercial buildings, transportation hubs. Pretty much everywhere you wouldn't want them to be. And this is the code that actually does that. So you can see we have the set points code and then we have a couple of other methods as well. We have the derail and the re-rail. One of the functions that we have on this device is we can set and remove authenticated servers. An authenticated server is Nexia. This thing has backbone. It will dial home and set off alarms, for support, all this. And it stores its trusted server as Nexia as one of these values. So you can get in there and you can actually pluck out Nexia. And this is all using the same structure that we've already used. And you can put in your own persistent connection. So let's see it in action. Hopefully you can see it well. We get the challenge. We smash it together with the default credentials. And then we start issuing a set hold command for the native zone that we got back every second. This thing doesn't have rate limiting. It has a fire and forget model. So whatever the most recent command was takes precedent. And as you can see, it doesn't matter if you're standing in front of it hitting the button, you're less important than the command that's receiving. So now you're stuck in front of your expensive IoT thermostat trying to change your temperature and it's not listening to you. It doesn't care. It's pretty much vulnerable out of the box. This is bit frightening. And again, it doesn't matter how many buttons you click or what functions you try to enable from the device interface, you will never be more powerful than the command that it's receiving. Because as far as this thing is concerned, the administrative that it commands that it gets remotely are the end all be all. We'll let it finish up. I think eventually the furnace itself will hold on. My burner is building up with gas or something like that. But it will always go back to heat mode. And you can set it to 90 degrees. You can set it to pretty much have the heat shut off and these are both like life-threatening problems depending on where you live in the world. If you live in Las Vegas and I set your heat to 90 degrees, that's a problem, right? If you live in Michigan and I turn off your heat, that's a bigger problem. Okay. So this method of issuing commands works for everything, like I said. And it works for all the different models that are included in the device. And that includes sensitive information. So, yeah, I can update your heat. I can shut off your heat. But I can also find out what your heating schedule is, so when you leave for work, when you get back from work, what the authenticated IDs for your device are, your serial numbers, you can check up on you as Mr. Bad Guy and see if my commands are actually doing what I expect them to do. And then, of course, active trusted connections and active trusted servers. So we can query this thing for read-only data and find out all the sensitive information. And it's pretty scary. And that includes chat logs, too. So you have the ability to actually chat with an exe rep, I believe, over this device to remotely provide service and control. They can actually enable SSH, if they want to, to get in your device and see what's going on. And that's all accessible. So we can read chat logs, the platform information, everything we need. And this one particular element, the AUID, that's a privileged ID that they generate off of the device's MAC address and a couple other factors is encrypted with this ID. And this ID is queryable from this port that uses a plain text protocol. Okay, well, clearly I've been able to write a couple of scripts for this and I want to make sure that people are able to audit these devices and have the ability to see if a device is vulnerable. So, building the new tool. Building a point-and-click tool after all this research was pretty easy. Obviously, the research itself was pretty much building these tools with this protocol. Mess with it, set the heat. Set your own server as a trusted server so that it never contacts Nexia. This is all available within the couple tools that I was able to build. And I've split them into two sections so that you actually have a safe read-only script that if you're a homeowner or perhaps a pen tester working with a client and you don't want to burn down their corporate building, all the information from it improve, yeah, this is vulnerable. And I still know when you guys are away from the building or at work, but I didn't change your heat. I didn't, you know, disconnect you permanently from Nexia. But we've proven that you're vulnerable. It's called trainwreck. The GitHub repository was opened up about an hour or two ago. So these tools are publicly available right now for you. And trainwreck is a Ruby script. And I included a gem file. So even if you're not a Ruby guy and you don't have Ruby installed in your system, it's pretty easy. You install Ruby. Second step is you do a bundle install. You'll have to install maybe a gem or two. And then after that, you're good to use command line scripts to execute these functions against the device. And these things, a lot of them are publicly available. Remember, these are ports that are used to communicate with the back end service. So I didn't just find this one on my own home network, but they're available throughout the country. This is how you use the more safe script, the one that just pulls queryable information. This will let you know that a device is vulnerable without threatening your house or your business or your client. And I think it's probably the one that most people will use. It's really, really easy. I should explain the stay command. So you just give it a target IP and then you can set it to stay subscribed. We have the subscribe command that will constantly feed us data. So this will connect to a device, parse out all the information that I listed before, and then if you want it to stay subscribed, you can maintain that connection and either, I don't know, output it to a file if you want or send it to a Redis database, at that point it's really up to you. But you can do additional research simply by having all this extra data. And then derailer is the script that's a bit more fun. And I say fun, I should say dangerous. The functions that are included in this, you can set the heat point, you can set the cold point, and you can actually derail or re-rail which means you can remove Nexia as a trusted server from the device. So this thing essentially goes dark from the backbone servers that are meant to control it from Nexia and train. So this thing will never set off an alarm to the home server. It will never call and raise a problem. You'll never be able to get tech support if it's disconnected from this server because it will have no knowledge of it. And I was able to set one of my computers at home as a trusted server. And this thing just started spitting data to it. Now, that's bad. And you can actually set different parameters for whether or not you want the data connection to be encrypted with that idea I mentioned earlier or not. Not that that's the best level of encryption, but you have that ability. And I preface this. This is a pretty dangerous one. Of course, you only want to use the sign devices you own or that you have the permission to test simply because you're using default login credentials as a part of this script and that's something to be considering or something to consider. So the scope of the problem and more problems. Why do we really care? Well, there's a number of things that are really bad about this. First, you can pretty much set the heat and cold for somebody's private house or a corporate building. That's bad. I mean, that's bad enough. That's a lot of people's worst nightmare. In addition to that, you get the privileged information of when your family's gone from their house or when the corporate building is empty. And there's a couple of other things that are cause for concern. This is also shipped with private keys for the backbone server. So the package that you download from train, this thing actually calls back to train and says, hey, here's my port. How to communicate with me? It will SSH back to their corporate server. It will then execute a shell script giving it a port number and then it will dial back and try and connect through that port number. So there's private keys hidden in this software package and that's a problem. And there's a lot of social engineering stuff that comes with having access to really specific privileged information like the hardware serial numbers and I don't mean just the device. You can also get information on the electronic relays and the furnace. You can update the functionality like I said. So it would be really easy to silence the device from the corporate server, make your server, your authenticated server, change it so that it's not operating correctly, silence the alarms and then you can show up as helpful Mr. Handyman and say, hey, what's this? And your temperature is out of whack? I'm here to fix it for you. Because that's a feature that this is supposed to have. You're supposed to be able to fax or dial out to the people that actually installed your furnace and that information is available in the scripts also. So you could just show up and mimic these people. In addition to that, we're all familiar with ransomware, right? What if your house gets ransom? We now have the ability to cut this off from the corporate network. We can set the heat and we can actually set messages, remember the banner in the top. We can set our own alarms. So you really could say, all right, you're no longer connected to Nexia. Your heat is 90 degrees and until you deposit this bitcoin address, your heat doesn't get turned back on. So now we've taken ransomware into actual physical implementation. It's pretty scary. Now the vendor claims that this was patched. We did disclose this to the vendor. It's been a good process. I had some help from good folks at work like Carl and they claim everything that's connected to their backbone system is patched. But remember the passwords that we saw commented out earlier? What we heard was that they simply disabled this port and we've evaluated that there's a lot of problems with this device. So knowing that these things are everywhere and that they've patched it, probably how they have patched other problems in the past doesn't really give me much much comfort at all. And remember with the basic insecure structure of this device or the lack of a good security bedrock in their approach, every other feature listed here is ripe for exploit. So you've got software updates that can be pushed over the wire and you can also do DNS spoofing. It pulls from servers that aren't really under the control of Nexia or train like weather underground. So you have third party servers that could be exploited or compromised and then they represent a way into the device. Like I said it ships with private keys for corporate servers. That's usually a very bad thing. And then the Nexia backbone itself touches a lot. So Nexia's service or Nexia's business is being in your business. They want to touch and integrate with as many things as they can so their backbone servers are meant to interface with door locks, light switches, cameras, thermostats. So if there's devices shipped with things that make it easier to compromise those systems it has a ripple effect that could affect a lot more devices. There's more every day. So this is a quick search from Shodan a little while ago when I first started the research. And it's pretty easy to find these things. What we got? Those show up really easy on Shodan. And you find these things like I said really everywhere you wouldn't want them to be. So private homes is scary enough but they're also in corporate buildings transportation areas probably utility areas it's pretty frightening and they're really easy to locate. So a bad guy could just walk around poke on Shodan and look for a target and they've been getting noisy. So when I first started the research it wasn't this bad. You weren't getting massive data dumps output of JSON data on a different port but it seems like since the patch has arrived or been deployed that these things are really just dumping the data out. So this poor guy we can read what his temperature is set at if he's enrolled in Nexia a bunch of other pieces of information that we should not have access to available online. It shouldn't be. At the very least it seems like encrypting this information would go a long way. There's a lot of other problems in the device that are problems in themselves but protecting your customers data is really key especially when everyone's paying 10 bucks a month for features that they never really asked for. Like I said there's a lot more opportunity. The problem is that these things are really everywhere and the people that have built this package with an idea of what can we do rather than how can we do it properly and have our customers ask for this they touch a lot of other devices Schlag door locks thermostats lighting modules security sensors, alarms and then train itself is owned by a parent company Ingersoll RAN which owns Thermo King a lot of air conditioning services golf carts for X-Play and like I mentioned before these insecure devices are shipped with things that could make it possible to compromise the corporate structures that administer these devices So we might have a vulnerable thermostat but that could end up at a compromised backbone and the backbone interfaces with all these devices So when I started googling for some of these hardware numbers that I found when querying information from the device I found that actually their secure area is directory indexed on Google and by the way I found this pretty innocent because I found the hardware numbers for the tools in use on my actual device and I started googling them looking for simply what they were and all these PDFs from the secure area started popping up and I realized that their entire directories were indexed and that represents a pretty bad security posture and it's another example of how some part of the company can have a bad problem of security and that will affect the rest of the company Remember we had Nexia they had open GitHub repositories with database salts, database passwords it was bad you have all these different companies in play and working with each other because everyone wants to integrate and you really have the weakest link of the chain is where it's going to break So here's the GitHub repository for the tools I hope you guys make use of them for everyone to use in their audits check out your own home thermostats that's why I made this safe one so that people can actually look at their own thermostat and see if it's vulnerable without risking their home or their furnace and then so you guys can contact me here's my Twitter I'm also on Keybase so if you have any feedback any ideas or if you get to test these in the wild on your own devices or ones you have permission to use I would love to hear how they work if you have any features or pull requests from anyone who submits them and that's it so if anybody has any questions I can try to answer them now so first off great talk you saw a lot of logic type problems inside the Ruby scripts did you find any other secure methods like eval being used any other ways to get access to devices besides just probing the temperature in that case I used a couple tools to try and evaluate it like Flay and some other syntax evaluators but I didn't find anything that it raised really as a red flag if you have some idea of particularly things we should look for I would love to hear that and we can definitely go back and take a look so you managed to derail the thermostat from makeshift backbone what about the other way can you authenticate yourself to the backbone and the impersonate another thermostat is that reasonable though I didn't in my research I didn't take the step to spoof information or really go far into the backbone servers because that was sort of territory I wasn't really comfortable with but given what I saw I have no reason to believe that wouldn't be possible because really you're using a private key and a hard coded user to authenticate with the backbone server and you're really just providing commands all available right there in the code so there's no reason why you couldn't have the server dialed to your port expecting to connect to a thermostat and getting something else instead yep I would expect that to be possible certainly I saw that there was some work done on a different software package on the XL950 that dealt with a buffer overflow but we were really focused on exploiting the heating, cooling, and the actual functions of the thermostat itself but I did notice that I noticed that some of these default passwords were included in a blog post from a number of years ago but I did take knowledge of that I just tried to take a different route so we could get additional research the device is wirelessly connected and some of them have the ability to be connected to the Ethernet cord so when you get this the first thing the installer will do is ask for your wifi password they'll put it in and hook this thing up to your network if you don't want to do that you either have to have it signed up on your own so there's a whole network interface on the device and you can select which wifi network to attach it to or you could really take the thing off the wall and hook it in with an Ethernet cord and I think some of them from what I read are built more to work often Ethernet cord exclusively but pretty much everything seems to have wifi capability as well neither one of them I expect to really protect this feature I didn't have time to finish that part of the research but everything I've seen makes me think that that's really possible you could force your own package on it yep and like I said the validation scripts are shipped with the package and you can also hot plug it via USB so even if someone has a strict security posture where this isn't even hooked up to the internet and it's air gapped you could walk in and hook up a USB and if you had the right checks it would validate and upload yeah I had a question was there any built in thresholds for the temperatures like what if I wanted to set an arbitrary value of 800 degrees yeah so 90 degrees was the heat threshold and uh I think it was probably around 50 I'm not exactly sure for the low one but yeah 90 degrees was definitely the highest that you can set it at but that's still on a hot day something I would consider like a failing temperature if you're set to a constant hold of 90 degrees sorry just a little follow up on that did you try if you said like something like 800 degrees would it just truncate it to 90 or just flat out reject it it rejects it or it labels it as like a dead band so if you send it invalid parameters it'll actually say like I'm gonna be running the air conditioning and the heating at the same time this doesn't make sense so it has some attempts to validate the temperatures you send in but the ranges given natural environments are still pretty dangerous the vendors response it took them a while to actually take us seriously so we uh Carl Sigler, a guy that I work with reached out to them and let them know hey we've got a security researcher who found a vulnerability in this so I'm going to work with you on fixing it the first responses we got back include our research and development department is so big there's no possible way that you found a vulnerability in our thermostat after that and we started sending them things like that video we got their attention pretty quickly they still haven't provided me the patch to test although they say that they've patched 100% of the devices that they have access to which itself means that not all of the devices are patched it was a struggle to get a good relationship with them in order to get the thing fixed and to this day I'm still not confident this completely addressed and that's part of the reason that I put tools out to help and apply pressure to make sure that research on this continues so you mentioned they fixed part of it or potentially fixed part of it but don't have much confidence considering some of the bad comments and so forth is this in your opinion ultimately fixable or I mean is it so riddled that it's just right from scratch that's a good question I saw a number, I mean we went over a number of problems that this thing has and these all developed from really thinking first about what you can do instead of thinking about security it would definitely be much more of a nightmare going back and retrofitting this to a secure position today rather than it'd probably be cheaper to start from scratch and have this thing written as a secure code but it may be possible, I'd never say never I started reverse engineering the code and looking into these ports as soon as I got the thermostat and as soon as I got the furnace back in December but to be honest considering I just replaced one furnace and it was still the middle of winter in Michigan I waited a while before trying to exploit the actual set heat commands I didn't want to have to call up people to just install new furnace and say hey I broke it, come give me a new one Can we read my answers? After watching that show after I started this research and I was thrilled to see that episode So those ports are clearly a different service and it's not included in this research but it does have validation so these are these are ports that are wrapped up in the busybox binary that they're not included in the general source code package and they have validation on them so they will definitely kick back commands and say no that's not valid In fact everything that I tried fuzzing it was like no, no, no I didn't try a straight out buffer overflow I was trying to actually get within their proprietary protocols and such but having a plain text port that says enter command is just asking for trouble Disconnect from the network Do you lose enough functionality that it's no longer worth the premium price or whatever and does that ultimately keep you kind of secure well even if you disconnect from the backbone server this port and the service will still be available because it's available either locally or remotely depending on your network configuration you probably won't lose every service on the device though because like I said it calls out to third-party servers that aren't affiliated with Nexity at all If you never configured it to work with your wi-fi in the first place there wouldn't really be as much opportunity to exploit it anyways The only opportunity to exploit the thermostat at that point would be to hot plug a USB with a poison package simply because these ports aren't available Would you then lose so much functionality that it's kind of not worth having that If you were able to lower your own software package, yeah, we can assume you lose everything Anyone else? Most real world appliances with just constant areas wherever the installers are actually instructed to connect it as part of the installation process but you could totally request that hey, don't connect this to the internet Everything about this is intended to basically force you to connect the device though You really are required to use this device to have the furnace work correctly and every feature on it is expecting that you're hooked up to the internet It won't even give you the weather from a weather underground or your local temperature which isn't from Nexia until you sign up for their $10 month service So every chance they get they want you to sign up for their integration Anyone else? Alright, thanks guys