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!