Smart Nest Thermostat:A Smart Spy in Your Home Grant Hernandez1,Orlando Arias1,Daniel Buentello2,and Yier Jin1
1Security in Silicon Laboratory,University of Central Florida
2Independent Researcher
yier.jin@eecs.ucf.edu
Abstract
The Nest Thermostat is a smart home automation device that aims to learn a user’s heating and cooling habits to help optimize scheduling and power usage.With its debut in2011,Nest
has proven to be such a success that Google spent$3.2B to acquire the company.However,
the complexity of the infrastructure in the Nest Thermostat provides a breeding ground for
security vulnerabilities similar to those found in other computer systems.To mitigate this
issue,Nest signsfirmware updates sent to the device,but the hardware infrastructure lacks
proper protection,allowing attackers to install malicious software into the unit.Through a USB
connection,we demonstrate how thefirmware verification done by the Nest software stack can
be bypassed,providing the means to completely alter the behavior of the unit.The compromised
Nest Thermostat will then act as a beachhead to attack other nodes within the local network.
Also,any information stored within the unit is now available to the attacker,who no longer has
to have physical access to the device.Finally,we present a solution to smart device architects
and manufacturers aiding the development and deployment of a secure hardware platform.
1Introduction
The concept of Internet of Things(IoT)and wearable devices has been widely accepted in the last few years with an increasing amount of smart devices being designed,fabricated,and deployed. It is estimated that there will be more than50billion network connected devices by2020,the majority of which will be IoT and wearable devices1.The once sciencefiction scenes that showed our refrigerator
s ordering us milk and our washing machines messaging us when laundry needs to be done are now reality.
The convenience provided by networked smart devices also breeds security and privacy concerns. Nest founder Tony Fadell claimed in an interview,“We have bank-level security,we encrypt updates, and we have an internal hacker team testing [the Nest Thermostat]will never take offif people don’t trust it.”However,a deep look into the current IoT and wearable device designflow revealed to us that most of the current security considerations,if any,are put on the application and network level.That is,designers often treat IoT and wearable devices as standard networked devices and try to apply the security protections developed for regular,everyday use computing devices.It is rare tofind any work done beyondfirmware authentication or encryption.Most IoT and wearable devices collect usage information and other data and send it to a service provider, leading to privacy concerns.Full disclosure of the what is collected is rare,and anything that is actually published is often hidden in the legalese that is the privacy policies and terms of services of the unit.
1www.cisco/web/about/ac79/docs/innov/IoT IBSG0411FINAL.pdf
In the rest of the paper,we will introduce our work identifying a security vulnerability in the Nest Ther
mostat,targeting the hardware infrastructure and the hardware-software boundary.We will demonstrate that attackers who understand the hardware can change the boot process of the device in order to upload maliciousfirmware,effectively bypassing thefirmware update verification done by the software.From a positive angle,however,we argue that this same vulnerability offers legitimate users a way to defend themselves against the collection of data thus protecting their privacy and to extend the functionality of the device.
2The Nest Thermostat
The Nest Thermostat is a smart device designed to control a central air conditioning unit based on heuristics and learned behavior.Coupled with a WiFi module,the Nest Thermostat is able connect to the user’s home or office network and interface with the Nest Cloud,thereby allowing for remote control of the unit.It also exhibits a ZigBee module for communication with other Nest devices,but has remained dormant forfirmware versions up to the now current4.2.x series.
The Nest Thermostat runs a Linux kernel,coupled with some GNU userland tools,Busybox, other miscellaneous utilities supporting a proprietary stack by Nest Labs.To remain GPL compli-ant,the modified source code used within the device has been published and is available for down-load from
Nest Lab’s Open Source Compliance page at nest/legal/compliance, with the notable exception of the C library.A toolchain to build these sources is not provided either.
2.1User Privacy
The Nest Thermostat will collect usage statistics of the device and environmental data and thus “learn”the user’s behavior.This is stored within the unit and also uploaded to the Nest Cloud once the thermostat connects to a network.Not only usage statistics are uploaded,but also system logs and Nest software logs,which contains information such as the user’s Zip Code,device settings, HVAC settings,and wiring configuration.Forensic analysis of the device also yields that the Nest Thermostat has code to prompt the user for information about their place of residence or office. Reports indicate that Nest plans to share this information with energy providers in order to generate energy more efficiently.
2.2Architecture Overview
As a device itself,the Nest Thermostat is divided into two components,a backplate which directly interfaces with the air conditioning unit and a front panel with a screen,a button,a rotary dial and a motion sensor.The operating system runs on the front plate.
The backplate contains a STMicroelectronics low power ARM Cortex-M3microcontroller with 128KiB offlash storage and16KiB of RAM,coupled with a few driver circuits and an SHT20 temperature and humidity sensor.The backplate communicates with the front plate using a UART.吸塑片材
The front panel offers a Texas Instruments(TI)Sitara AM3703microprocessor,64MiB of SDRAM,2Gibit(256MiB)of ECC NANDflash,a ZigBee module and a WiFi module support-ing802.11b/g/n.The board for this device also offers a Texas Instruments TPS65921B power management module with HS USB capabilities.This part of the Nest has been the target of our research so far,as it contains the most hardware and handles all user data and input.
Figure1:Front and back plates of a Nest Thermostat(credit:Nest)
2.3Boot Process
Upon normal power on conditions,the Sitara AM3703starts to execute the code in its internal ROM.This code initializes the most basic peripherals,including the General Purpose Memory Controller(GPMC).It then looks for thefirst stage bootloader,x-loader,and places it into SRAM. Once this operationfinishes,the ROM code jumps into x-loader,which proceeds to initialize other peripherals and SDRAM.Afterwards,it copies the second stage bootloader,u-boot,into SDRAM and proceeds to execute it.At this point,u-boot proceeds to initialize the remaining subsystems and executes the uImage in NAND with the configured environment.The systemfinishes booting from NAND as initialization scripts are executed,services are run,culminating with the loading of the Nest Thermostat proprietary software stack.Figure2shows the normal boot process of the
device.
Figure2:Standard Nest Thermostat boot process
3The AM3703-A Closer Look
The TI AM3703microprocessor is composed of a32Channel DMA controller,a dual-output three-
layer display processor,High Speed USB controller with USB OTG capabilities,an emulation
module for debugging,a General Purpose Memory Controller(GPMC)to handle NAND/NOR
flash,an SDRAM memory scheduler and controller,an112KiB on-chip ROM which contains boot
code,a64KiB on-chip SRAM all connected by a Level3(L3)interconnect which runs at200MHz.
sys boot[5:0]
First Second Third Fourth Fifth 001101
勇猛的圣灵肩垫XIP USB UART3MMC1001110 XIPwait DOC USB UART3MMC1001111
NAND USB UART3MMC1101101
管式直线电机
USB UART3MMC1XIP 101110 无线数据传输USB UART3MMC1XIPwait DOC
101111USB UART3MMC1NAND Table 1:Selected boot configurations.
The ARM core within the MPU subsystem uses a 256KiB cache to reach the L3interconnect.Furthermore,a Level 4interconnect adds the peripheral module to the memory map.This periph-eral module handles the GPIO,UARTs,high speed multimaster I 2C bus,memory card controller,memory stick pro controller,watchdog timer,general purpose timers and other miscellaneous sub-systems.
The ARM subchip integrates an ARM Cortex-A8core,with Version 7of the instruction set ar-chitecture,providing standard ARM instructions and Thumb-2mode,the JazelleX Java accelerator and
media extensions.It also integrates an ARM NEON core SIMD coprocessor.It connects to a 32KiB/32KiB instruction/data caches which proceeds to interface with a 256KiB 8-way associative cache supporting parity and ECC.The core also provides integrated trace and debug features.A simplified memory map of the device is shown in Figure 3.SDRC/SMS
0x 7
00
00
0SDRAM/CS00x 80000000SDRAM/CS10x a 0000000Reserved 0x c 0000000SDRC/SMS
0x e 0000000
x 40000000x 4001c 000x 40100000x 40200000x 40210000x
000
000
0x f f f f f f f f Figure 3:Simplified memory map (shaded areas are internal to the AM3703)3.1Device initialization
Power connections,clock and reset signals must be properly initialized before the AM3703boots.The device boot configuration is given by six external pins,sys boot[5:0].After power-on reset,the value on these pins are latched into the CONTROL.CONTROL STATUS register.Table 1describes the boot selection process for select configurations.
After performing basic initialization tasks,the on-chip ROM may jump into a connected execute in place (XIP)memory,if the sys boot pins are configured as such.This boot mode is executed as a blind jump to the external addressable memory as soon as it is available.Otherwise,the ROM constructs a boot device list to be searched for boot images and stores it in the first location of available scratchpad memory.The construction of this list depends on whether or not the device is
booting from a power-on reset state.If the device is booting from a power-on reset,the boot con-figuration is read directly from the sys boot pins and latched into the CONTROL.CONTROL STATUS register.Otherwise,the ROM will look in the scratchpad area of SRAM for a valid boot configura-tion,if itfinds one,it will utilize it,otherwise it will build one from permanent devices as configured in the sys boot pins.
adma
Closer scrutiny of this process yields that under some circumstances,it is possible to boot the processor from a peripheral device,such as UART or USB.This is the method we are using to insert our code into the Nest Thermostat long before thefirmware verification can take action.
4Attack Vector
A global reset of the device can be triggered by pressing its button for about10seconds.Among other things,this causes the sys boot5pin to go high,triggering peripheral booting.Coincidentally, the sys boot5pin is directly exposed in an unpopulated header within the main circuit board,which can be utilized to directly trigger the US
B booting behavior.Since the ROM does no cryptographic checks of the code being loaded,it freely executes this code,allowing total control of the device.
A few limitations to this process must be observed.There is a strict timing window in which the ROM will be listening for any incoming program data,the initial payload must be x-loader,which is copied to SRAM and must initialize all remaining subsystems.Subsequent payloads must be able tofit and execute in SDRAM.
4.1Initial attack
Our initial attack consisted of sending x-loader to the device by means of USB booting along with a custom u-boot image and a ramdisk with ourfinal payload.Our u-boot was configured to boot the on-board kernel,utilizing the ramdisk as an initial rootfilesystem enabling us to automate our backdooring of Nest’s rootfilesystem.The payload mounted the device’sfilesystem and using an already existing netcat binary we created a way to obtain a shell by modifying the boot scripts of the Nest Thermostat.This was demonstrated in our video which can be viewed at utube/watch?v=7AnvTgAKa-g.
Using this backdoor,we were able to start exploring thefilesystem of the device,attempting to reconstruct some“missing”items from userland,namely,the version of the C library used and any information on the toolchain used to build it.This information became available once the C library on the system was found and explored.Once the toolchain was rebuilt,we were able to run our own software on the device.Loading the software into the device was done using one of three ways:either using netcat,a custom ramdisk that executed the aforementioned attack,or the fact that the Nest Thermostat will identify and be treated as a USB mass storage device once fully booted and connected to a PC.
4.2Refining a Backdoor
With a toolchain at hand,we cross-compiled dropbear,an SSH server,and installed it on the device.A user account was added to the unit by performing the required modifications in the /etc/passwd,/etc/shadow and/etc/groupsfiles.On modifying the initialization scripts,we noticed that the Nest Thermostat attempts to start a secure shell server on its own,the binaries for which is not present within thefilesystem.Further forensic analysis on this path yielded a pair of RSA and DSA host keys that were generated at some point.Checking multiple units showed that these keys are unique.
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议