Mirai has been popping on and off the news and is becoming a commodity resource for large scale DDoS attacks. Although most of the security community have been debating and warning about the IoT threat, there is only evidence for a very specific class of devices being involved in the Mirai attacks. As we came to know the source code and security researchers started to investigate the victimized devices, it was clear that a common class of devices stood out in the list compiled by Krebs: IP cameras, DVRs and a handful of routers. What made them better candidates than your smart toaster or your cloud connected thermostat? The fact that routers are in the list should not be surprising, those devices are per definition connected to the internet and are clearly #1 on the pwning list, which was proven again recently when 900,000 routers from DT where taken offline for service as a result of what is supposed to be an adapted version of Mirai using a remote code execution (RCE) vulnerability through the TR-069 CPE WAN management protocol.
Why IP cameras and DVRs?
Consumers expect their IP cameras and DVRs to be accessible from anywhere, consuming their favorite programs from the comfort of their hotel when traveling and monitoring the state of the house through mobile phone when on the road. To realize what we came to expect from these devices, they need to be accessible from the internet. The kind of information shared by these devices is very different than let’s say an energy meter or weather station which periodically upload sensor values to a cloud platform which provides a user anytime, anywhere access to their history without the need for direct access to in-house devices. With DVRs and IP cameras however, the information that needs to be shared comes in the form of large video and audio streams and unless for cloud storing DVRs and IP surveillance platforms, that are typically more expensive to host because of their important storage needs, the devices need to be accessible directly from the client which is connected somewhere on the internet. Some (not to say a lot) of enterprises deploy their security cams in a purpose built DMZ, which is good practice to isolate them from the LAN and prevent lateral movement in case of devices being compromised, if it was not for opening up the whole DMZ and exposing all the cams directly to the internet. Sometimes surveillance requires remotely located cams and these have been in some cases directly connected to the internet because introducing one more device, a firewall, would create one more single point of failure with a net result of doubling the failure probability. In the end, the camera is supposedly secure because the default admin password was changed using a strong password through the IP camera’s web interface and brute-forcing access through the web would take over a decade to succeed. Which could be true if not taken into account vulnerabilities and in the particular case of Mirai the default credentials for shell access and the by default enabled telnet and SSH services. With no evidence of these enabled services or the separate credentials in the web interface of the device it is not too much to assume that these might never get changed…
UPnP-IGD seamlessly exposing a device to the internet
Users expect an easy and seamless deployment of consumer devices, a one-page quick start is the most that you could expect from them to read. A device manufacturer wants to provide a great user experience and not limit his addressable market to professionals or tech savvy geeks. Imagine an excited consumer unwrapping his new toy only to find 20-page instructions on how to securely enable port forwarding in his router – in the best case the user knows he has a router! A solution was found through a nifty set of protocols called Universal Plug and Play (UPnP). UPnP allows networked devices, such as personal computers, printers, internet gateways, WiFi access points and mobile devices to seamlessly discover each other on the network and establish functional network services for sharing data. For DVRs and IP cameras, the UPnP Internet Gateway Device Protocol (UPnP-IGD -) provides a means of dynamically punching holes in the router’s security policy, making them accessible from the internet without the consumer even knowing about what is happening. Combined with a cloud service that provides dynamic DNS the user is redirected directly to his in-home device enabling him to watch his recorded programs, schedule new recordings or monitor his home. Moreover, the data never passes through thirds parties providing best user experience and guaranteed privacy. The drawback to all this niceness and great user experience? As the device is directly exposed on the internet, the smallest vulnerability or misconfiguration can lead to a compromised device and before you know it your DVR or IP camera becomes an involuntary soldier in a large bot army attacking innocent targets and causing financial loss all over the world.
At this point you might come to ask yourself how does this relate to my intelligent thermostat becoming the next device to participate in large DDoS attacks? The risk profile of a thermostat does not compare to that of an IP camera or a DVR. An intelligent, cloud connected thermostat that leverages big data and machine learning in the cloud does not need to be made directly accessible from the interwebs. Periodic checks initiated from the device to the cloud to share its sensor information and receive optimized heating profiles are all that is needed in order to substantially increase your comfort all the while you make important savings on your next energy bill.
DDoS shuts down heating in 2 apartment buildings
Imagine walking into your home and it’s freezing inside. You run to the thermostat turn it up but there is no heat coming from the system. This happened not so long ago in Lappeenranta in Finland. A hacker performed a DDoS attack on a heating distribution system that controls the heating of 2 large apartment blocks. The distribution system is a SCADA (Supervisory Control and Data Acquisition) system, the industrial sibling of IoT systems. SCADA systems have been around for decades and while they used to be rather isolated systems, more recently they started being connected and device protocols enabled for IP, making those systems accessible from the internet. Security was not a consideration when connecting those systems and reaping the benefits of the cloud for supervisory control. The DDoS on the Finish heating system was very limited in time, but lasted long enough to cause the system to go offline and shut down heating for more than 3 days. While under attack, the system reacted by rebooting itself, causing the it to go in an endless loop of reboots until devices eventually stopped working. Remote access to the system was cut off so experts had to go on site to recover the system and eventually the heating in the apartments. The buildings were without heating for over 3 days.
While this attack was not directly related to Mirai, it was mentioned in the original report that Mirai could be an example of a botnet that would perform such attack. The threat landscape is changing, partly through Mirai. Attackers have access to a level of sophistication they didn’t have before to perform large volumetric attacks.
State of the Thermostat
The building blocks of smart thermostats are not fundamentally different from those used in IP cameras, DVRs or routers. The Nest Thermostat for examples consists of a low power ARM Cortex-M3 processor with 16KB RAM and 128KB of flash storage, running a stripped version of the Linux kernel couple with some basic utilities and BusyBox. Linking back to an earlier blog I wrote on the Deplorable State of IoT Security, the IoT devices targeted by Mirai are BusyBox based running a stripped version on the Linux kernel on low power ARM architectures.
To illustrate the similarity with the devices from the Mirai list, take for example the study performed by Talos on the Trane ComfortLink II thermostats. The vulnerabilities that were exposed through this study included a hard-coded credential vulnerability where the Trane installs two sets of user credentials with hardcoded passwords upon system boot. These credentials can be used to remotely log into the system over SSH and once logged in the user is given access to a fully functional BusyBox environment giving him full control of the device including the possibility to download, compile and execute arbitrary code. Other vulnerabilities reported included remote code execution vulnerabilities through buffer overflows. Talos contacted Trane and delivered advisories for these vulnerabilities in the first half of 2014, while they have been addressed by Trane with a firmware update released January 26, 2016. The update guidelines from the manufacturer include having a blank SD card to be flashed from a computer and then inserted in the thermostat and performing a reboot. A non-trivial procedure for consumers, if they have a compatible SD card within easy reach.
The threat from within
As mentioned earlier, there is no good reason for a thermostat to expose itself to the internet through eg UPnP-IGD. As such, we could assume that UPnP-IGD is not enabled on such class of devices and by consequence one would not be able to compromise the device through the internet. Now consider for moment that on the same network of the smart thermostat there is a smart device that can be infected by Mirai, using the same technique as used by the DT attack’s hackers, a slightly adapted version of Mirai that is exploiting laterally in the network and leverages the earlier mentioned vulnerabilities could compromise thermostat and make it fall victim to a Mirai-alike bot.
Even if no one infects your thermostat remotely, it has been proven that for example the Nest can be compromised within 15 seconds when the attacker has physical access to the device. What stops a bad actor from intercepting a shipment or transport? What if the attacker buys them in bulk and offers compromised devices in a good deal off eBay?
Then there is the threat of social engineering as some thermostats allow their owners to extend their functionality by loading new apps or customize their background through uploading images, either through the network or through SD Cards/USB sticks. It is only a matter of time until a vulnerability is discovered in the application sandbox or a buffer overflow in the image loading code that.
How many users fell victim to malicious apps sending private information from android devices by downloading the wrong app from the app Store? Imagine if you had the latest Pokémon go app for your thermostat, how cool would that be?
Is it so improbable that your thermostat will be the next recruit for the bot armies being formed around the internet? And while dedicated to its new mission, your thermostat is using all of its limited resources for the attack, pretty much rendering it useless and you without heating…
One more thing…
While you may expect important savings on your energy bill through adopting a smart thermostat, these savings are quickly undone when your thermostat falls victim to ransomware and you have the option of either paying up or increase the number of sweaters until you get the thermostat replaced. Not so long ago, during Def Con 24 PenTestPartners demonstrated how easy it is to create ransomware for a smart thermostat and lock the user out until they pay up.
Download Radware’s DDoS Handbook to get expert advice, actionable tools and tips to help detect and stop DDoS attacks.
As the EMEA Cyber Security Evangelist for Radware, Pascal helps execute the company's thought leadership on today's security threat landscape. Pascal brings over two decades of experience in many aspects of Information Technology and holds a degree in Civil Engineering from the Free University of Brussels. As part of the Radware Security Research team Pascal develops and maintains the IoT honeypots and actively researches IoT malware. He discovered BrickerBot, provided the updated Hajime report and follows closely any development and new threats in the IoT landscape. Prior to Radware, Pascal worked with the largest EMEA cloud providers on their SDN and next gen data center strategies as a consulting engineer for Juniper. As an independent consultant Pascal architected sensor networks, automated and developed PLC systems and lead security infrastructure and software auditing projects. At the start of his career he was a regular presenter at IBM conferences for Perl and Unix kernel development.