IoT Security: Understanding my Connected Thermostat

Today, I wanted to share a post from a guest author. My friend Jason Garbis (@jasongarbis) created this piece about IoT and your home thermostat. It is a great read and the research is really interesting! I know many folks that are adopting IoT devices in their homes, and likely will not put the level of effort that Jason went through to understand their security. Good news in this case - he did it for you!

I’m a technical guy, and I like understanding how things work. Because I’m employed at a network security company, I’ve been doing a lot of reading and writing about network security, the (in)security of connected devices, and attacks such as the Mirai botnet.

Which brings me to my connected home Thermostat, a Trane model which uses the Nexia home automation platform. I wanted to understand the network model for this device. I can use the Nexia app on my phone to control the thermostat from anywhere, but how does this work? Does my device have an open connection to a service in the cloud? Or is there (shudder) an inbound connection to it?

I’ve been able to answer these questions with some research, but this was harder than it should be, and there’s little hope for less-technical people to be able to figure these kinds of things out for their home automation systems.

So let’s get started!

One note: For privacy purposes, I have redacted my home IP address throughout this document.

The thermostat is on my home wireless network, with an IP address assigned to it from my wireless router: 192.168.1.7.

I performed a quick port scan with two different tools – nmap running on a local machine, and fing running on my phone – and they both showed no open ports on the device. This is a good first result from a security perspective! (Note that I’ve also configured my wireless router to not have any open ports, or to allow any incoming network connections, so even if the thermostat had an open port, it would only have been accessible on the wireless network, and not from the Internet. And yes, UPnP is also disabled on the router!).

Let’s take a look at the device itself – it’s a Trane XL824, which shows up on the network as a Murata Manufacturing device. This device displays a local weather forecast, and is controllable from a smartphone app.

It’s clear that the thermostat is making an outbound connection to a server, and obtaining data such as the weather forecast, and commands such as temperature setting changes from the phone app over this connection [note that while some systems might use a peer-to-peer connection over the local wifi, that’s not how this system operates]. In particular, I’m very interested in understanding the command model, and the security around this. How are changes to my thermostat settings performed? What’s the data flow from the phone app to my thermostat?

My standard-issue home wireless router offers very little in terms of actual network monitoring features. If you dig through the painfully slow admin UI, it does offer a crude security log with a shockingly small capacity of 16KB. This corresponds to only a few seconds of traffic, apparently, before we see:

Fortuitously, in this brief snippet of log I discovered an outbound connection from the thermostat’s private IP address (192.168.1.7) out to a remote system, at IP address 23.194.182.156 on port 80.

This IP address is operated by Akamai – it’s not surprising that the Nexia folks, with probably hundreds of thousands of thermostats running 24x7, would make use of a CDN to farm out content to nearby nodes. But, I still have a few questions about this.

Why is it using port 80 rather than 443? A simple port scan shows that the target IP address has both ports 80 and 443 open. Should I be concerned about this traffic being unencrypted?

Trying this IP address in my browser results in a web server error –

So, let’s try HTTPS:

 Aha! Look at the domain associated with the certificate. This is a site providing the weather forecast data to the thermostat. Presumably it makes regular outbound calls to the Akamai-hosted CDN site to obtain this data.

I happened to catch an outbound call to this service in that brief log snippet. I’m guessing that it was preceded by a DNS lookup, which returned this nearby Akamai IP address based on my geolocation. Obtaining weather data over HTTP rather than HTTPS may seem fairly benign, but does introduce a potential vulnerability. A man-in-the-middle or DNS hijacking attack could pretty easily serve up bogus or malformed weather data, and this malformed data could be used to perform an attack and obtain a foothold on the thermostat, for example via a buffer overflow. So I need to give Nexia a small demerit for this. Ideally they’d use HTTPS to preserve the integrity of the data, and also perform a certificate revocation check.

Back to the task at hand, it’s clear that I need more comprehensive logging of my home network. Despite my wireless router’s limitations, it does support the ability to log to a remote system:

I have an old laptop at home on which I’ve installed Linux, so I got this fired up and configured to listen for SYSLOG data coming from the router.




Ok…lots of data to parse. Let’s filter it a bit…



And (reformatted for clarity) a basic pattern emerges:


Looks like the thermostat is calling out to the Weather service every 5 minutes. This pattern is quite regular:

• Generally the outbound connections are going to either 23.194.182.156 or 23.192.142.167. These are both Akamai IP addresses, so I’m guessing that DNS is returning these as part of a load-balanced set.
• These calls are all preceded by a DNS call using UDP port 53. The log shows these going first to the router (192.168.1.1), which then sends them along to the external DNS server. 

But wait – there’s an odd set of outbound connections going to port 443!



These are not only off-cycle from the other connections, they’re also the only ones going out from the thermostat to port 443.

Based on a reverse DNS lookup, these servers are running in AWS – and map to an EC2 instance and an S3 bucket. These are presumably the control mechanisms for the thermostat.

Let’s see what these services are: 52.1.236.158 has ports 80 and 443 open, so loading this in a browser leads us to…

the Nexia site (properly redirecting to HTTPS).

The other two destinations for port 443 correspond to S3 buckets, which don’t offer a Web interface without authentication, and without permission I’m not going to poke around them in any case.

Just for kicks, let’s do a DNS lookup on the mynexia.com domain:

And there it is, 52.1.236.158. Hosted in AWS and assigned to mynexia.com. This is clearly the connection we’ve been looking for! Let’s think about the system behavior for a moment – I can use the Nexia iPhone app to adjust my thermostat, and these changes take place essentially immediately – within ~5 seconds based on my handful of tests.

This implies near-real time communications over an existing network connection, not something that’s polling-based. And because we’ve established that there are no inbound connections to the thermostat, this outbound connection to the Nexia system must be long-lived.

Let’s take a look at the log files to see what else we can discover. We can see several connections outbound to port 443 on the Nexia server.



And looking at a DNS log I set up – I used BIND and configured my router to use my Linux laptop as its DNS server -- we can see the mynexia.com domain resolution request:



Some of these connections are only open for a few seconds – for example the one outbound on port 44318 is opened at 15:57:09, and closed at 15:57:12. But the connection on port 50216 – opened at 15:27:41 – remains open for a long period (beyond the horizon of when I turned off the logging server that day).

This is exactly what we’d expect from the observed behavior! A long-lived outbound connection from the thermostat to the Nexia server, used to communicate commands in near real-time.

Is this secure? Let’s asses – it’s using HTTPS for the connection, which is clearly a good foundation. I can’t tell whether it’s doing any certificate validation on the mynexia.com domain. Doing so would require deploying a firewall and performing HTTPS inspection, which is beyond the scope of this article.

So let’s summarize what we learned here, and assess its security. The thermostat is only making outbound connections, and doesn’t require either an open port or (the horror of) UPnP. It’s making an HTTPS connection to its command & control system, hosted at a recognizable domain. These are all sound security approaches.

My only criticism is that it’s making an unsecured call to a Weather.com server over HTTP. This is a small but real vulnerability, since it’s subject to an MITM attack that could exploit a buffer overflow of some sort. I’m not terribly worried about upstream attackers at the ISP, but someone could create a rogue wireless access point and capture the outbound calls to the weather forecast server. Or in theory hijack my DNS, redirect the thermostat to a bogus weather forecast server, and deliver malformed data. Again – these are real but unlikely attacks.

Overall, I’m satisfied with the security of this device. I learned a lot doing this research, and I hope that you’ve found this writeup useful. Let me know what you think – I’m reachable on Twitter @JasonGarbis 

Thanks!

Why Cloud Security Expert Christopher Steffen Joined Cryptzone...

Apart from the title being slightly self serving, I wanted to share this first "official" blog that I wrote for my new company Cryptzone. You can see the original post here, and you can learn more about Cryptzone here.  Enjoy!

Over the weekend, I shared how excited I was to join the Cryptzone team as a Technical Director. I wanted to share a few insights into my move, and why I chose Cryptzone as my new home away from home.

Technology: There are literally thousands of technology companies out there, and many of them have a focus (or at least pay attention to) the issues that I particularly like to advocate: information security and compliance. Cryptzone is a company dedicated to these issues, and takes a unique approach to all of them. AppGate is the industry leader in the emerging Software Defined Perimeter (SDP) space, providing security solutions with identity centric security controls to the enterprise while protecting resources from internal and external threats. Security Sheriff is a product that helps enforce compliance and data security policies for many of your compliance controls. Compliance Sheriff provides users with a means to monitor online content for potential compliance issues across digital environments – keeping information safe, appropriate and within regulatory guidelines. These products are leaders in their respective spaces, used by private and public sector customers to address security and compliance needs.

Innovation: If you follow the information security industry at all, you know that there are dozens of security products to address every potential security concern an enterprise may have. Cryptzone may have been dismissed before as just another vendor in the already crowded security software space.

Until you actually look at what they do.

The Software-Defined Perimeter paradigm is a radically different approach to network and identity centric security. The entire AppGate concept is different enough – authenticating the user before they have access to ANY resources at all – that it often takes a couple of explanations to get it, even to the most seasoned security or network professional. Once they *DO* understand the concept, the first question usually is “Where has this been all my life?” I can happily share examples of the technical overview with you, but it blew my mind the first time I saw it. Enough so that I knew then that I was EXTREMELY interested in the revolution that was SDP and Cryptzone.

Message: Cryptzone is unique in the security industry. Often you hear the tales of doom and gloom that accompany most security services and product sells – buy our stuff or your company will be hacked out of existence! The fear marketing happens at nearly every company, and I guess it must work, to some extent. Cryptzone takes a different approach – providing a security solution and support to a customer partner trying to address security and compliance challenges to protect their enterprise. REFRESHING!! As an industry, I think we need to move away from the scare tactics and focus on solutions. While I was able to do this to some degree in my previous professional endeavors, Cryptzone embraces the concept.

Culture: I walk into a room with co-workers for the very first time, and the first comment that I was greeted with was “I had better step up my beard game.” No, I do not make employment decisions based on the beards in the room (though that may not be a terrible criteria), but it speaks to the welcoming and collegial atmosphere of the company. My previous professional experiences have varied – from the large, Fortune 50 technical company, to the small manufacturing company, to the small financial services company, to the public sector. Each has been different, and each has their positives and negatives.

Cryptzone is an established “start-up”, though it is different than any start-up I have seen or been a part of. It is established and funded, has mature products, industry leadership and all of the usual infrastructure that you would expect from a well-run company. Yet there is definitely a start-up vibe – excited, driven, innovative, and fun. I have been immediately embraced as a person, not just another employee, engaged at every level about my ideas and suggestions. It is the dream of every person to work in an environment where they are valued. Cryptzone convinced me of this on the very first day (actually long before that).

I blog ALL THE TIME – this is the first of MANY blogs that I will create for Cryptzone. I am planning a series on a recent Forrester Research report that you should be able to read soon, as well as thought leadership content on Cryptzone and information security topics.

You can find more information about Cryptzone here. The Forrester Research whitepaper “Forrester – "No More Chewy Centers: The Zero Trust Model of Information Security" can be found here. You can also read additional Cryptzone blogs by going here.

Old Skool...

Welcome to The Security Beard!

There will be a ton of original content coming here in the future. But until then, I wanted to share some of my favorite blogs that I have written in the past few months, mainly from my Medium blog. Stay tuned for some additional content soon!

A friend and colleague of mine recently mentioned that I was “Old School IT” — actually several times. I have been thinking on it most of the weekend, and thought it might be worthwhile to share some of those thoughts.

Let’s start with a definition: In this case, old skool refers to a technology enthusiast that probably has 20+ years experience, and, at one point in their careers, has pretty much seen and done it all when it comes to information technology: system administration, wire monkey, help desk, network Jedi (or Sith, depending on your affiliation), database admin, and/or printer paper filler. You might have even had that title-of-titles: COMPUTER GUY.

In all likelihood, at this point in their careers, they are a specialist or expert — having done many of the various aspects of IT and settled into a specialty (for me it has been information security, or — even more specifically — information security and compliance in the various cloud architectures).

They may even be a member of management — using those skills gained over the last decade plus to educate and train others in the technical field. In some rare cases, the old skool tech has become an executive, using their experiences to drive a technical vision and direction for an enterprise or the industry. In my years of tech, I have been privileged to know and even work with a few of these. It is a truly amazing thing to see experienced technical innovators at work — the right combination of business acumen with technical kung fu.

Now to really age myself — Part of being old skool is remembering and working in a time where technology was NOT ubiquitous, the Internet was a very small collection of web pages, and the only thing that Apple had released as a portable mobile device was a Newton (and no — a Mac Portable does NOT count).

15 years too soon, Steve...

Point being — I remember the trial and error in building computers (jumper combos and dip switches), programming EPROMs, coding using the VI editor in some flavor of Unix and making a Macaquarium out of my Mac SE/30 (still wish I had that thing). Answers came in books and manuals (RTFM), not Google searches (anyone remember setting up Sendmail using the Bat Book?). It isn’t to say that the twenty somethings that are the techies of today are not qualified, but it is a very different beast than it was when I started (one could say the same thing about programming with punch cards or even worse — in Fortran — but I am not THAT old).

Being old skool has made me a better technologist: instead of jumping into management and executive positions with no experience, I have been there and done that in the technical world. I can honestly relate to those that I am talking to at *ANY* level. A significant part of my job is talking to people about cloud security, and I have the confidence and the experience to relate directly to the audience — from the C-Table to the security engineer — because I have been there and done that. For example, when attending a technical conference, which was better: the sessions where someone drones on and on about technology (think PowerPoint of Death), or the sessions led by someone who is a technical expert in his/her subject (think technical demos or just Q/A)?

I never really intended to have a career in the technology industry — it just sort of happened. But I kept coming back to it, despite diversions in politics and non-profits. Sure, it pays the bills. But there is more to it. The constant challenge of learning may not be unique in any particular vertical, but in the technology world, and even more so in the information security and cloud spaces, the technology and uses are evolving right in front of us.

Old skool technologists — then — are those that have evolved as the technology has evolved. They have stayed relevant with their skills, applying their experiences to better understand the next evolution — revolution.

I am proud to be considered old skool…

(BTW — I am not so “old school” as to not know how it is really spelled…)