The Internet of Things (IoT) continues to explode in the consumer market as demand for network connected devices has spread to all kinds non-traditional network connected systems from toasters to toilets and from refrigerators to lamps. Unfortunately this rush to market often leaves security concerns unanswered and IoT devices are quickly earning a reputation as security hazards. Not every IoT device is equally vulnerable or dangerous. Some companies have even participated in bug bounty programs for their devices and services to help weed out security issues and protect customers.
One of the most common IoT devices is a house thermostat. When I suffered a failure in my home's furnace this past winter virtually all the replacements my local dealer offered me came packaged with IoT thermostats hosting impressive features. My choice was a Trane furnace paired with a Trane residential Comfortlink XL850 thermostat. The XL850 supports WiFi connectivity, remote service, remote control and ZWave features. Trane has partnered with Nexia to produce a monthly service where customers can use either a website or a mobile app to remotely control their home's heating and cooling schedule and set the temperature whenever they please. The XL850 supports these features through Internet connectivity and, unfortunately, I found that it is also vulnerable by default when installed even without special features enabled.
Trane ComfortLink XL850 thermostats running firmware version 3.1 or lower are vulnerable to information disclosure and remote access due to a weak authentication mechanism and hardcoded credentials. The device uses a custom protocol and a predictable port number to administer remote access to virtually all of the device functions. When you combine hardcoded credentials with a network accessible port, you have a device ripe for attack from the network or even an attack from the Internet if the thermostat is exposed through the router.
Since my research began on this device when it entered my home in December 2015 I have been checking regularly to see how many are accessible from the Internet. Since then I have seen the number of publicly available thermostats listed from the samplings of just 1 source increased from 24 to approximately 50 at the time of this writing. The devices seem to be concentrated in North America where IoT is popular and both Trane and Nexia are located.
Once an attacker has gained access they can quickly extract all information from the device including the home heating and cooling schedule, current operation mode, current temperature, chat and alarm history, serial number, active socket connections, trusted URLs, secret IDs, software version info and detailed address and installer information.
The most obvious danger is from home invaders who can gain easy access to the wake up and work schedule for an entire household. Knowing when a home or commercial building is intended to be empty is sensitive information. Additional dangers include combining the highly detailed service information with social engineering and access to the device in general.
What's more concerning than the information extraction is the fact that active commands are available that allow attackers to perform a number of dangerous operations. This includes forcing the device to maintain the maximum heating setting or disabling the device continuously thereby overriding user input. Attackers can also remove and create trusted server connections permanently disconnecting the device from the corporate command and control servers. The most obvious consequence of this would be overheating a building or damaging it by disabling the heat in winter conditions. The video below shows the exploit in action and the effect it can have on the device. The "Get Connected" banner at the top of the screen is a marketing prompt indicating that the device is not enrolled in any remote services or special features.
This video includes no audio.
Trustwave SpiderLabs had multiple issues in our attempts to communicate these vulnerabilities to Trane. This story is probably old hat to anyone who has been involved with vulnerability disclosure but luckily this one has a happy ending. Our initial attempts at contacting Trane resulted in silence and bounced emails. This included multiple attempts to contact them directly, through their web contact form, and cold emailing them and their parent company. A call to tech support resulted in confusion since we weren't officially a "customer". Instead they recommended we call a local distributor and see if we couldn't work our way "up the chain" that way. This resulted in skepticism (the local distrubtor assumed we were trying to sell them something despite my claims otherwise) and it resulted in dismissiveness. In one email we received the contact stated: "I appreciate your concern, but it seems that Trane already has a dedicated team for security risks and the like, so I think it would be a good idea to let them handle this and any future vulnerabilities." Finally, our email got to the right contact a little over two months later. Luckily that contact was more than willing to work with us and we are happy to announce that Trane was able to remediate these vulnerabilities in a very short amount of time. Impressively, Trane also has the capability to update the XL850 firmware automatically for connected devices and has been pushing out updates to their customers since the beginning of July.
In addition to the issues with the XL850 itself there were other issues that were a cause for concern around the service itself. Nexia, a partner company of Trane and the mobile app used to control the XL850, was also notified during this research that a number of their github repositories were publicly available. These repositories centered on the backend command and control services for these thermostats. What makes this worse is that a number of configuration files, encryption salts and secret keys were present in the repositories increasing the risk to customers. Replies from two separate contacts at Trane stated that, while they would look into it, it was their understanding that these repositories were forked from public code and were meant to be public. However, when the proper contact was finally reached, steps were taken to clean up the publicly exposed confidential code.
Not every IoT security story results in a patch and there are bound to be many more. If you are concerned about the security of your IoT device you might consider hosting a dedicated WiFi network for IoT devices that limits internet access or removes it entirely. In a worst case scenario you might want to disable network access entirely. Organizations concerned about being exposed to greater risk due to IoT devices should be performing regular network scans and vulnerability assessments. Proper network inventory should uncover strange or new IP addresses which may be IoT devices.
There are a couple of lessons to be learned here. First is that IoT deserves the security magnifying glass that is currently on it. Too many of these products are being pushed out without concern for the security implications. Secondly this magnifying glass is only going to bring more independent researchers poking and probing these products. We encourage more IoT vendors to make some of the important internal changes that Trane has to facilitate this communication. You don't necessarily need a full Product Security Incident Response Team. Even small steps like training your support team on the proper method to escalate vulnerability reports or verifying that your company's "security@" email alias routes to someone that expects such reports can go a long way. Embracing vulnerability disclosure and independent research is guaranteed to help secure both your products and their customers.
