Nest, a company recently acquired by Google, offers a variety of popular network enabled home utilities. The most popular of which is a thermostat that allows a user to control their household temperature remotely from their smart phone. This device, although seemingly useful, if not well protected can allow an attacker the ability to remotely monitor user’s habits or network traffic. Below, we will go into a method of attacking Nest brand thermostats by leveraging the device’s DFU mode to boot unsigned code at the boot-loader level. What this means in layman’s terms is that we are able to hijack the device’s code flow very early on, allowing us to make changes without ANY restrictions. Below we will describe the attack, our method of exploiting it, and our proof of concept code which allows a user to backdoor a Nest thermostat.
The Nest uses a CPU similar to the OMAP3630 series. This CPU features a Device Firmware Update (DFU) mode that can be accessed by holding down the Nest’s screen while off. This mode is intended for the manufacturer to easily diagnose and repair the device. Unfortunately, in the case of the Nest, this mode also allows us to modify the device without restriction.
Our attack on the Nest thermostat is simple, we use the device’s recovery mode to run our own modified boot-loader (stage one and two). We then use our loaded boot-loaders to initiate a Linux kernel that is used to modify the file system on the Nest. We then add a SSH server running as root as well as functionality to create a reverse SSH tunnel to a specified host using the Nest’s virtual drive.
NestAttack Rooting a Nest.
The attack is all played out within the Nest’s DFU mode which is briefly mentioned above. This mode allows a user to push a set of images and addresses to be loaded through the device’s USB port with a utility called “omap3_loader”. DFU mode is only intended as a catalyst to load the next stages of code, the first of which in our case is the x-loader binary. X-loader is a stage 1 boot-loader that is used on the Nest as the initial loading point for the system. X-loader handles getting the device ready to execute the second stage boot-loader that is responsible for loading up the Linux kernel. On the Nest, the second stage boot-loader is an open source piece of software widely used on embedded devices known as “U-Boot”. We use our own custom modified version of U-Boot that is based on the GPL released Nest version to boot a Linux kernel. This Linux kernel is only used to access the Nest’s file system and add a cross compiled SSH server called Dropbear. This allows a user to connect to their Nest and obtain root access on their thermostat. After installing the SSH server, we move on to adding a SH script which checks the Nest’s virtual disk every 10 minutes for 2 files, a “host.txt” which contains a username and host in the “username@ipaddress” format as well as a “key.txt” which contains the RSA key for the SSH connection. If these files are found, the device connects out to a remote attacker at the specified address in the “host.txt” file and makes a reverse SSH connection. This allows remote access to a user’s thermostat and home network bypassing most firewalls. This process can be stopped at any time by placing an empty file with the name “stop.txt” within the root of the Nest’s virtual USB disk.
Google Nest DFU Attack
The exploit process is a single stage depending on your operating system:
For Linux, run “NestAttack-Linux.sh”
These files push the built binaries to the Nest and handle rooting the device. This process takes less than a minute.
We found this “feature” back in November 2013, and mentioned it publicly on December 5th, 2013 (see this tweet). Initially, we planned on releasing our findings at a conference this summer (along with new root methods for the Chromecast and Roku), but our talk was declined. Their loss!
We will, however, be speaking this year at DEF CON 22! Our talk, entitled Hack All The Things: 20 Devices in 45 Minutes, will feature unreleased exploits for 20 devices being released in a 45 minute period. If you are in Las Vegas this August, make sure to stop in!
Download package (Supports: Linux support only (more coming soon.)).
Run the appropriate attack script depending on your OS. Follow instructions after executing.
You can get our pre-built packages for easy exploitation by using the following link.
On Wednesday, July 24th Google launched the Chromecast. As soon as the source code hit we began our audit. Within a short period of time we had multiple items to look at for when our devices arrived. Then we received our Chromecasts the following day and were able to confirm that one of the bugs existed in the build Chromecast shipped with. From that point on we began building what you are now seeing as our public release package.
Our Chromecast exploit package will modify the system to spawn a root shell on port 23. This will allow researchers to better investigate the environment as well as give developers a chance to build and test software on their Chromecasts. For the normal user this release will probably be of no use, for the rest of the community this is just the first step in opening up what has just been a mysterious stick up to this point. We hope that following this release the community will have the tools they need to improve on the shortfalls of this device and make better use of the hardware.
Is it really ChromeOS?
No, it’s not. We had a lot of internal discussion on this, and have concluded that it’s more Android than ChromeOS. To be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast. Since the Marvell DE3005 SOC running this is a single core variant of the 88DE3100, most of the Google TV code was reused. So, although it’s not going to let you install an APK or anything, its origins: the bootloader, kernel, init scripts, binaries, are all from the Google TV.
We are not ruling out the ability for this to become a Google TV “stick”.
Lucky for us, Google was kind enough to GPL the bootloader source code for the device. So we can identify the exact flaw that allows us to boot the unsigned kernel. By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, we can execute any code at will.
ret = VerifyImage((unsigned int)k_buff, cpu_img_siz, (unsigned int)k_buff);
The example above shows the call made to verify the image, the value stored in ret is never actually verified to ensure that the call to “VerifyImage” succeeded. From that, we are able to execute our own kernel. Hilariously, this was harder to do than our initial analysis of exploitation suggested. This was due to the USB booted kernel needing extra modifications to allow us to modify /system as well as a few other tweaks.
We then built a custom ramdisk which, when started, began the process of modifying the system by performing the following steps:
Mount the USB drive plugged in to the chromecast.
Erase the /system partition (mtd3).
Write the new custom system image.
Note: /system is squashfs as opposed to normally seen EXT4/YAFFS2.
The system image installed from our package is a copy of the original with a modified /bin/clear_crash_counter binary. This binary was modified to perform its original action as well as spawn a telnet server as root.
After the above process, the only modification to the device is done to spawn a root shell. No update mitigations are performed which means that theoretically, an update could be pushed at any moment patching our exploit. Even with that knowledge, having an internal look at the device is priceless and we hope that the community will be able to leverage this bug in time.
A little over 2 years ago a band of miscreants came together from an XDA developers forum post and started working together to get privileged code execution on the Google TV. Little did we know that the challenges would be greater than anyone could imagine.
When the Google TV was released it was easily one of the most locked down Android devices containing a signature enforced bootloader which established a “chain of trust” between it and every component loaded thereafter. The hardened state of the kernel the device came with made things even worse, with the kernel enforcing module signing as well as lacking most of the popular Android vulnerabilities that were plaguing the mobile world. This Android device was truly unlike most others.
So we began work attempting to win an advertised cash bounty for being the first to gain root access on the newly released device. After some work, we posted the first root method for the Logitech Revue, winning a $500 prize. Since then it has been our goal to make Google TV an open platform by unlocking each released device. There were plenty of challenges along the way, in the form of long nights reversing code and many bricked devices. But along with the challenges there have also been many triumphs in the form of releases.
Going over some of our biggest acheivements in the last 2 years:
Found and released a hardware root method for the Logitech Revue and assisted Dr. Dan Rosenberg in finding a software root exploit.
Found and released multiple exploits for the Sony NSZ-GT1 and Sony Google TV television line, breaking the established chain of trust.
Received a secret message from Logitech within the stock recovery on the Logitech Revue.
We released a modification package for the Hisense Pulse which leveraged the intial debug configuration of the device for root, disabled automatic updates, and modified the flash plug-in allowing you to watch Hulu and other previously blocked content providers.
In regards to the future of GTVHacker, over the past month we found and have been developing an exploit which will allow for custom kernels to be run on most of the newest generation of Google TV devices. We’ve also (cj_000 specifically) been busy making a custom recovery specifically designed for the Google TV. You may already know this but, there are a number of differences between the Google TV and other Android devices and these difference make it impossible to simply build a popular AOSP based recovery or kernel image. Due to these differences, we had to make our own recovery from scratch. At the time of writing this it’s still in a beta phase and rather simple. It only allows for installation of an update.zip package from usb. This can be a modified update, a superuser binary and apk or whatever else you wish. We’ve also started adb over ethernet to allow for custom system changes that may require more interaction than a update package.
Below is a quick demo of the custom recovery mentioned above being tested on a Sony NSZ-GS7 Google TV device. We currently don’t have a release date set as we are trying to keep most of the specifics private in order to avoid an update that could patch the exploit before the community gets to utilize it. We just wanted to give the community a sneak peek at what we’ve been working on privately over the last few months. So sit tight, 2013 will be a great year for the Google TV and GTVHacker!
The GTVHacker team had heard rumors of a Netgear Google TV device for a while, but the rumors were confirmed recently when GTVHacker team member cj_000 found FCC documentation for the new device. We waited to see if any of the big news sites would find the documentation and pictures, but since the community has yet to find them – here you go: A look at the Netgear NeoTV Prime (GTV100)!
Netgear GTV100 Remote
This is a generation 2 Google TV box, it will probably look fairly close to the Vizio Co-Star (hardware wise) but with a different case. There is also more than likely going to be a custom UI to help separate the NeoTV Prime from Google TV competitors but we have yet to have that information confirmed. For more on the NeoTV Prime, check out the remote, and WiFi module: NeoTV Prime Remote via the FCC / NeoTV Prime Wifi Module via the FCC.
Asus Qube Remote Dongle
That brings us to the Asus Qube, which is a Google TV box that had its remote module hit the FCC yesterday. In regards to hardware and software, the Qube should be a similar device. We’re not expecting any major surprises here, every generation 2 Google TV device (excluding the LG G2) has used the same Marvell 88DE3100 series chipset. It is worth mentioning that some are reporting this to be a USB stick. The sheer size of cooling needed for the Marvell 88DE3100 series (Armada 1500) chip makes this theory unlikely.
For instance, take a look at our Sony NSZ-GS7 teardown or the internals of the Vizio Co-Star. Both need quite a bit of cooling due to the Marvell CPU which would be near impossible with a USB powered “dongle”.
Below are direct links to the FCC information on the Asus Qube as well as the app mentioned in the Engadget article that originally broke the story on the Qube.