Posted: March 4th, 2017 | Author: zenofex | Filed under: NAS, Western Digital | 16 Comments »
Sometimes at Exploitee.rs, we look for fun devices to hack and sometimes the devices find us. Today we’re going to talk about a recent time where we found ourselves in the latter situation and our experience with the Western Digital series of Networked Attached Storage devices.
In the middle of last year I (Zenofex) began looking for a NAS that provided hardware decoding through my currently prefered media player, Plex. After a bit of research I ordered a Western Digital “MyCloud” PR4100. This device met all the requirements of what I was looking for and came highly recommended by a friend. After adding the NAS to my network and visiting the device’s admin page for the first time, I grew weary of adding a new device to my network without giving it a proper audit. So, I logged in, enabled SSH access, and looked at how the web server functionality of the device worked.
I quickly found the first bug that shocked me, this bug was based on code that performed a user login check but did so using cookies or PHP session variables. Using cookies for authentication isn’t necessarily a bad thing, but the way that the Western Digital MyCloud interface uses them is the problem. Examine the code below.
$ret = 0;
if (isset($_SESSION['username']) && $_SESSION['username'] != "")
$ret = 2; //login, normal user
if ($_SESSION['isAdmin'] == 1)
$ret = 1; //login, admin
else if (isset($_COOKIE['username']))
if (isset($_COOKIE['username']) && $_COOKIE['username'] != "")
$ret = 2; //login, normal user
if ($_COOKIE['isAdmin'] == 1)
$ret = 1; //login, admin
“username” variable is set and is not empty – User is logged in as a normal privileged user.
“isAdmin” variable is set to 1 – User is logged in as an administrator.
This means that any time there is a login check within the PHP scripts, an attacker is able to bypass the check by supplying 2 specially crafted cookie values.
During the process of writing up my findings a new firmware was rolled out patching the above bug. However, this patch introduced a new vulnerability which had the same consequences as the original (prior to the update). Below is the current version including the fixed code.
20 function login_check()
22 $ret = 0;
24 if (isset($_SESSION['username']))
26 if (isset($_SESSION['username']) && $_SESSION['username'] != "")
27 $ret = 2; //login, normal user
29 if ($_SESSION['isAdmin'] == 1)
30 $ret = 1; //login, admin
32 else if (isset($_COOKIE['username']))
34 if (isset($_COOKIE['username']) && $_COOKIE['username'] != "")
35 $ret = 2; //login, normal user
37 if ($_COOKIE['isAdmin'] == 1)
38 $ret = 1; //login, admin
40 if (wto_check($_COOKIE['username']) === 0) //wto check fail
41 $ret = 0;
44 return $ret;
In the updated version of the code, a call to the new method “wto_check()” is made (line 40). This function runs a binary on the device with the client supplied username as an argument along with the user’s IP address. If the user is currently logged in and hasn’t timed out the value 1 is returned, otherwise 0 is returned (indicating the user isn’t logged in). The code for the “wto_check()” method can be found below.
4 return value: 1: Login, 0: No login
6 function wto_check($username)
8 if (empty($username))
9 return 0;
11 exec(sprintf("wto -n \"%s\" -i '%s' -c", escapeshellcmd($username), $_SERVER["REMOTE_ADDR"]), $login_status);
12 if ($login_status === "WTO CHECK OK")
13 return 1;
15 return 0;
18 /* ret: 0: no login, 1: login, admin, 2: login, normal user */
In the above you can see that on line 11 the command is formatted to include the username and IP address as arguments to the “wto” binary. The problem with the above is the incorrect use of the PHP method “escapeshellcmd()” which, in its intended usage, handles an entire command string, and not just an argument. This is because the “escapeshellcmd()” function does not escape quotes and therefore allows an attacker the ability to break out of the encapsulating quotes (in our case for the “-n” argument), allowing for new arguments to be supplied to the binary. Because of this, instead of actually checking if the user is logged in, we can add new arguments and log the user in ourselves. Although we do not believe simply verifying that the user is already logged in by checking an IP address and login timeout is sufficient. The programmer who wrote this code should have used “escapeshellarg()”, which is intended to filter independent binary arguments and which does filter out quotes. Using “escapeshellarg()” as opposed to the currently used “escapeshellcmd()” would have at least prevented this attack from working.
Command Injection Bugs
A majority of the functionality of the WDCloud web interface is actually handled by CGI scripts on the device. Most of the binaries use the same pattern, they obtain post/get/cookie values from the request, and then use the values within PHP calls to execute shell commands. In most cases, these commands will use the user supplied data with little or no sanitization. For example, consider the following code from the device.
15 $username = $_COOKIE['username'];
16 exec("wto -n \"$username\" -g", $ret);
The code above assigns a value from the COOKIE superglobal variable, which contains array indexes for cookies submitted from the request, to the local variable “$username”. This value is then immediately used in a PHP “exec()” call as an argument to the local “wto” binary. Since there is no sanitization, using a username value like
turns the existing exec command into
wto -n "$(touch /tmp/1)" -g
and executes the user supplied command within.
Because the argument is encapsulated with double quotes and we use the “$(COMMANDHERE)” syntax, the command “touch /tmp/1” is executed prior to the execution of the “wto” binary and the return value of which is used as its “-n” argument. This basic pattern resulting in a command injection vulnerability is used multiple times within the many scripts used by the web interface. While some may have normally been prevented by authentication being required, that restriction is overcome by the authentication bypass mentioned above. Also, it is important to note that all commands executed through the web interface are done so as the user the web-server is running as, which, in this case is root.
While you may think that the above bugs are severe, there are a number of other errors within the web interface with some being as simple as the normal authentication being commented out:
6 //include ("../lib/login_checker.php");
8 ///* login_check() return 0: no login, 1: login, admin, 2: login, normal user */
9 //if (login_check() == 0)
11 // echo json_encode($r);
12 // exit;
And others being more functionality specific, like the following example of a bug allowing a non-authenticated user the ability to upload files onto the myCloud device.
2 //if(!isset($_REQUEST['name'])) throw new Exception('Name required');
3 //if(!preg_match('/^[-a-z0-9_][-a-z0-9_.]*$/i', $_REQUEST['name'])) throw new Exception('Name error');
5 //if(!isset($_REQUEST['index'])) throw new Exception('Index required');
6 //if(!preg_match('/^[0-9]+$/', $_REQUEST['index'])) throw new Exception('Index error');
8 //if(!isset($_FILES['file'])) throw new Exception('Upload required');
9 //if($_FILES['file']['error'] != 0) throw new Exception('Upload error');
11 $path = str_replace('//','/',$_REQUEST['folder']);
12 $filename = str_replace('\\','',$_REQUEST['name']);
13 $target = $path . $filename . '-' . $_REQUEST['index'];
15 //$target = $_REQUEST['folder'] . $_REQUEST['name'] . '-' . $_REQUEST['index'];
17 move_uploaded_file($_FILES['file']['tmp_name'], $target);
20 //$handle = fopen("/tmp/debug.txt", "w+");
21 //fwrite($handle, $_FILES['file']['tmp_name']);
22 //fwrite($handle, "\n");
23 //fwrite($handle, $target);
26 // Might execute too quickly.
The above code consists of no checks for authentication and, when called will simply retrieve the uploaded file contents and use the user supplied path to determine where to place the new file.
Beyond the bugs listed in this blog post, our wiki is full of bugs we’ve found within the MyCloud web interface. Our general goal at Exploitee.rs is to get bugs fixed as quickly as possible. However, the large number of severe findings means that we may need to re-evaluate the product after the vendor has properly fixed the released vulnerabilities.
At Exploitee.rs, we normally attempt to work with vendors to ensure that vulnerabilities are properly released. However, after visiting the Pwnie Awards at the last BlackHat Vegas, we learned of the vendor’s reputation within the community. In particular, this vendor won a “Pwnie for Lamest Vendor Response” in a situation where the vendor ignored the severity of a set of bugs reported to them. Ignoring these bugs would leave the vulnerable devices online for longer periods while responsible disclosure is worked out. Instead we’re attempting to alert the community of the flaws and hoping that users remove their devices from any public facing portions of their networks, limiting access wherever possible. Through this process, we’re fully disclosing all of our research and hoping that this expedites the patches to users’ devices.
Bugs Found Statistics
1 x Login Bypass
1 x Arbitrary File Write
13 x Unauthenticated Remote Command Execution Bugs
70 x Authentication Required Command Execution Bugs*
*”Authentication Required” bugs can be reached with the login bypass bug.
Most, if not all, of the research can be applied to the entire series of Western Digital MyCloud products. This includes the following devices:
- My Cloud
- My Cloud Gen 2
- My Cloud Mirror
- My Cloud PR2100
- My Cloud PR4100
- My Cloud EX2 Ultra
- My Cloud EX2
- My Cloud EX4
- My Cloud EX2100
- My Cloud EX4100
- My Cloud DL2100
- My Cloud DL4100
For the complete listing and a small write-up on each of the bugs found during our Western Digital MyCloud research, visit the Exploitee.rs Wiki.
For updates on Western Digital’s response or alerts when new content is added to our wiki or blog follow us on twitter @Exploiteers
Posted: January 14th, 2017 | Author: zenofex | Filed under: Uncategorized | 1 Comment »
Today we’re re-visiting a device that we’ve hacked in a previous session. At DEFCON 22, we released exploits for the Samsung Smartcam network camera in our “Hack All The things” presentation. These exploits allowed for remote command execution and the ability to arbitrarily change the camera’s administrator password. After being alerted to the vulnerabilities, Samsung reacted by removing the entire locally accessible web interface and requiring users to use the Samsung SmartCloud website. This angered a number of users [Example 1, Example 2] and crippled the device from being used in any DIY monitoring solutions. So, we decided to audit the device once more to see if there is a way we can give users back access to their cameras while at the same time verifying the security of the devices new firmware.
When a user visits the updated web interface on the Samsung Smartcam, they are now greeted with a “404 – Not Found” message. The interface previously in place, which allowed for users to view and configure their camera, is now completely removed with only backend scripts left. Seemingly all vulnerabilities found by us as well as those found by others are patched. There was however one set of scripts that were not removed or modified, the php files which provide firmware update abilities for the camera through its “iWatch” webcam monitoring service were left untouched. These scripts contain a command injection bug that can be leveraged for root remote command execution to an unprivileged user.
iWatch Install.php Root Command Execution
The iWatch Install.php vulnerability can be exploited by crafting a special filename which is then stored within a tar command passed to a php system() call. Because the web-server runs as root, the filename is user supplied, and the input is used without sanitization, we are able to inject our own commands within to achieve root remote command execution. You can find the technical writeup and fix for the vulnerability as well as instructions for re-enabling the Smartcams’s web administration panel on our wiki along with a video demonstration below.
Posted: October 8th, 2015 | Author: maximus | Filed under: Routers | 4 Comments »
Today we’re releasing the method that we’ve reversed engineered on how to get root and modify the firmware on a Google OnHub. This process involves booting of the OnHub into the “Developer Mode”, loading of an image from a USB disk, and also provides the ability to modify and resign a modified image with development keys. This method was reverse engineered based on an in depth look and dump of the hardware along with a disassembly of the Android app and Google OnHub USB Recovery Chrome extension. Below we’ll talk about the process and our findings in depth.
Our initial look at the Google OnHub was the iFixIt teardown, the device contains multiple radios (including the currently unused Zigbee radio) as well as a speaker and a plethora of antennas. The pieces that caught our eye however, were the eMMC and SPI flash ICs on the board. Based on our previous experience looking at devices, we knew that with our low voltage eMMC adapters as well as a Raspberry Pi (or Bus Pirate), we had an easy and quick way to dump both flash devices. Unfortunately, at that time we did not have access to a Google OnHub, so we were stuck having to work with what we had available.
At this point our sights were aimed at the Google OnHub Android App and Recovery USB Chrome extension with the main intention being to find the firmware update URL. After a short search we found this url which contained a URL to a recovery image of the eMMC flash. This was our first real look into the firmware running on the device.
We finally acquired a Google OnHub and went right into tearing it apart. We took the device apart and then proceeded to remove and dump the SPI flash first. For this we used a Raspberry Pi along with flashrom. After dumping and a quick look, we found that the SPI flash stored the BIOS data. We proceeded to dump the eMMC, and compare to what we found within the recovery image. We determined that the images highly resembled that of the Google Chromebook, and that the OnHub was a very close match in architecture. We spent the next day going over the dumps in depth and determining our attack plan.
Our initial attack plan involved a page we found on the feasibility of hacking the Google Chromebook. This page stated that the attacks that could not be protected by the secure boot setup used by ChromeOS were those that involved physical access and re-flashing of the BIOS. So, our initial attempts were of just that, we attempted to re-flash the SPI flash but were crippled by not having a valid method of receiving debug output while booting modified images.
After subsequent attempts we re-thought our game plan and looked deeper at the hardware that was packaged within the OnHub in comparison to the Google Chromebook. This is where we found the usage of a “hidden” switch that is contained on the bottom plate of the Google OnHub but is hidden by a screw. We would soon determine that this switch enables the ability of booting into the device’s Developer Mode but requires a special key sequence first. We began to comb through more ChromiumOS docs until we found “CTRL+D”. Hitting Ctrl+D prior to pressing the Developer Mode switch, switches the device into Developer Mode. After further research into the Chromebook and examining the USB image created by the OnHub Recovery USB Image Creator Chrome Extension we crafted a USB and attempted to boot the USB device. At this point we had our first major breakthrough and had the device booting a USB image. The rest was easy and entailed exploring the device teamed with reading more ChromiumOS docs, this helped form the rest of the root process which can be found on our wiki.
TLDR, The Google OnHub is at heart a Chromebook without a screen modified as a router, and our root method is just a modified version of booting Developer Mode.
Technical details of the Google OnHub visit: Exploitee.rs Wiki – Google OnHub
Root procedure can be found at: Exploitee.rs Wiki – Rooting The Google OnHub
Posted: February 9th, 2015 | Author: hans | Filed under: Uncategorized | Comments Off on In support of the legality of rooting
As the Exploiteers, we believe in both open software and open hardware. We’ve worked tirelessly to come up with roots for all sorts of devices, and software modifications to make these rooted devices more awesome.
We are convinced that this is a good thing, and to ensure that we (and others) can continue to do awesome hacks, we are participating in the political process to ensure full control of your devices is legal in the United States.
One of the more pesky laws governing digital devices and their security is the Digital Millenium Copyright Act. It criminalizes breaking electronic locks for copyrighted works – which might include things such as the firmware update mechanism for your smart TV. The authors of the law recognized that there are reasons to circumvent digital locks that aren’t copyright infringement, and made an exemption process to formally recognize valid reasons to circumvent these locks. The exemption process happens every three years, with the US Copyright Office evaluating proposed exemptions. One of the newly proposed exemptions (by the Software Freedom Conservancy) this year is “Jailbreaking—Smart TVs”, which is a category we have a lot of experience with.
As a group of people who encounter these kind of locks every day, we submitted a comment through the comment process to advocate for formally stating that jailbreaking / rooting of smart TVs and streaming media players is legal in the US. We strongly support all of our users watching the content they want and running the apps they choose on whatever device they may own.
View the comment we submitted below, or as a PDF!
Read the rest of this entry »
Posted: December 31st, 2014 | Author: zenofex | Filed under: Uncategorized | Tags: Exploitee.rs, GTVHacker | 1 Comment »
When GTVHacker started, we were a group of researchers who met on a popular Android developer forum and simply wanted more from our newly purchased and heavily fortified Logitech Revue Google TV devices. We would have never thought that our simple goal of utilizing our hardware would turn into GTVHacker. We moved to an IRC (Internet Relay Chat) channel and began researching how our devices worked and how we could make them better. This eventually turned into an obsession until we released our first root exploit for the Revue. Flash forward 4 years to today, and the irony of the situation is that we (as a group named “GTVHacker”) have released exploits for 40+ devices, and only 1/3 of them have been for the Google TV platform. Within the same time period Google itself has ditched the Google TV name in place for “Android TV” guaranteeing an experience more in line with that of its Android mobile devices.
So we as a group have decided it’s finally time to retire the name “GTVHacker” and transition into our new form as (the) “Exploiteers”. Over the next few days we will be transitioning all of the rest of the content from the GTVHacker network on to Exploitee.rs. We will be changing site logos and themes but the archived content will stay the same. If you happen to notice something that’s not working right, feel free to contact us at [email protected] to let us know.
In the mean time, here are a few things to look forward to from the Exploitee.rs
- New exploits!
- New custom hardware!
- A new storefront to sell our custom hardware (and other future items).
TLDR, We’re now the Exploitee.rs and we’re hacking more than ever before!
Happy New Year!
Posted: June 24th, 2014 | Author: cj_000 | Filed under: Nest | 8 Comments »
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 “[email protected]” 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.)).
- Extract package.
- 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.
Download NestAttack At Download.GTVHacker.com
We’re also in the process of open sourcing our build environment at:
GTVHacker GitHub – NestDFUAttack
DEF CON 22: Again, come check out our DEF CON talk this August in Las Vegas. Hack All The Things: 20 Devices in 45 Minutes, it will be awesome and there may be a special guest!
Posted: December 28th, 2013 | Author: zenofex | Filed under: Roku, Uncategorized | 12 Comments »
Hello Universe, welcome back. It’s been a while since our last post due to a lack of new Google TV hardware and developments. When we have free time we tend to look at other interesting opportunities that come our way and recently we came into just such a situation when we found ourselves auditing multiple Roku devices.
You may not know it by looking at the device, but the Roku is considerably more secure than most entertainment devices in its genre (even our namesake). The engineers at Roku not only implemented a decently hardened grsec kernel, they did it where we hadn’t seen before, on ARM. The layers above that contain a miscellaneous assortment of secure boot and encryption methods with configurations varying between the different chipsets throughout the platform. Our package leverages one such configuration, the bcm2835 chipset, in which user accessible per box keys are used to sign the initial “stage 1” portion of the bootloader. This allows us, from the initial root bug, to modify a portion of the system boot and remove signature verification checks. Effectively breaking the “chain of trust” established and allowing us to load any compatible image desired.
Now for the details. The initial root exploit utilizes a local command execution vulnerability within the developer settings menu of the device. Specifically, the bug is within the development password field, and due to poor sanitation of input, the bug lets us run commands as root. This affects the majority of updated Roku devices and was ironically introduced as a security improvement. The downside to this bug is that it does not provide a persistent root method (or, in short, a method that continues beyond system restarts). This left us looking for a method to persist root on the device, which is when we noticed the configuration of the bcm2835 Roku devices. In this chipset, the bootloader is signed by a per box key which, in all tested bcm2835 devices, is included on the box. By having the per box key we are able to break the chain of trust and load a modified “stage 2” bootloader image. In our case we modify the stock U-Boot to include the “dev=1” kernel cmdline argument that identifies a developer device. We then take advantage of a init.d script which allows us to place files in a non-signature validated portion of the file system that is executed when the “dev=1” kernel cmdline argument is set. We use this file to place commands to mount a replacement version of “/bin/Application”, Roku’s main content shell binary, to allow us to disable automatic updates on each boot.
We’ve packaged up all of the above into a nicely commented script which can be downloaded from our download servers at:
The file above contains a script with a cpio archive that includes the following 5 files:
- bpatch – compiled for the device and used to apply binary patches to files
- mtd1-uboot.patch – a patch file for bpatch used to patch the U-Boot portion of mtd1
- nandboot.patch – a patch file for bpatch used to patch nandboot.bin (stage1 bootloader)
- roku2-nandwrite.ko – a custom kernel module used to modify kernel cmdline in memory and trick the NAND driver into allowing bootloader writes.
- Application.patch – a patch file for bpatch used to patch /bin/Application to disable updates.
The entire GTVHacker team has put a lot of work into this release and we hope the Roku community enjoys it. We invite others to continue our work and are happy to share progress made while we work to further leverage the current exploits before a patch is released. In the mean time, if you have a second generation Roku, root it. And if you don’t, buy one quick!
This bug will probably get patched soon. So in other words, exploit now or forever hold your peace.
Posted: August 3rd, 2013 | Author: zenofex | Filed under: Uncategorized | 1 Comment »
Yesterday at the DEF CON 21 security conference we released our custom recovery package and 2 individual exploits for the Google TV platform. The 2 exploits leveraged together allow users to install the first custom recovery ever created on the Google TV. The first exploit is a vulnerability which affects certain Linux configurations, in particular those that mount NTFS drives without the nodev flag. This is very similar to a vulnerability we leveraged last year for unsigned kernels on the Gen 1 Sony Google TV where as both exploit poorly mounted flash drives. The difference in this being that the NTFS bug affects every device within the platform and allows users to rewrite previously non write-able (RO) mtdblock partitions. We use this exploit to drop a SU binary on the device within the /system partition which is not mounted nosuid. Of note, another valid method we could have used would have been to modify the build.prop file. Unfortunately, even as the root user, security features within the kernel prevent this from being used to allow much for the Google TV community.We can however leverage this exploit to obtain a larger attack surface on the device.
This leads us to our next bug which only affects the boot-loader on the second generation of Google TV devices. This bug is found within the initial loading of the Google TV kernel after the device performs its RSA verification. This can best be summed up by the picture below.
Boot process for second gen Google TV devices.
As you can see by the above picture, multiple levels of AES decryption and RSA verification are performed. In a secure boot environment this setup is called a “Chain of Trust” which, in more descriptive terms, means that each segment loaded during the device’s boot is signed and verified to establish that it is provided by the manufacturer and not a third party (like GTVHacker). Our attack is actually performed directly after the last AES decrypt and verification routine, which in particular verifies the authenticity of the kernel image being loaded. The bug lies in the fact that the majority of Gen 2 devices do not perform any verification on the loaded RAMdisk address which is stored in the kernel image header. By changing the RAMdisk load address in the image to actually point to the kernel load address and by attaching an unsigned kernel image to the RAMdisk. We are able to load an unsigned kernel directly on top of the actual signed kernel after all decryption and verification routines are performed. This method works on every device in the platform except the second gen devices by Sony. The Sony devices actually do check the RAMdisk that is supplied, but fail to do so correctly. By simply attaching another kernel and RAMdisk after the signed versions, and pointing the RAMdisk load address to this new kernel and RAMdisk we are able to bypass their signature checks. By using either of these techniques on the generation 2 devices we are able to completely destroy the chain of trust the device attempts to establish during boot and we are allowed to run any code needed, which in our case is a custom recovery image that does not perform any signature validation on update images.
Today we are releasing instructions on performing both attacks as well as our slides and content for the presentation. Please note that this process does involve flashing portions of the device, and in doing so there is a risk of bricking your Google TV. We’ve attempted to make this process as fail-proof as possible in order to prevent bricked devices, however we can’t guarantee that your device won’t become a glorified paperweight. With that being said, proceed at your own caution.
We will be open sourcing our code as well as compiling more custom recovery images for Google TV devices in the coming days. Keep checking our wiki, blog and Twitter for more info. In the mean time enjoy our DEF CON 21 content that we’ve spent a portion of our free time over the last year working on, and check out the video of the demo from our presentation below.
Posted: July 28th, 2013 | Author: cj_000 | Filed under: Uncategorized | 10 Comments »
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”.
Speaking of Google TV – if you are in Vegas for DEF CON 21, check out our talk – “Google TV: Or How I Learned to Stop Worrying and Exploit Secure Boot” this Friday August 2nd at 3PM in the Penn and Teller Theater! We’ve got secure boot exploits for the Google TV (unsigned kernels and roots anyone?) and more – don’t miss it!
How does the exploit work?
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.
Downloads and instructions for exploitation can be found on our wiki at: GTVHacker Wiki: Google Chromecast
Looking for help rooting your device or just want to ask us a question? Check out our Chromecast forum
Posted: May 22nd, 2013 | Author: zenofex | Filed under: Asus, GTVHacker | Comments Off on “CubeRoot” Pulled From Google Play Store
The inevitable has happened, the GTVHacker “CubeRoot” Android application has been removed from the Google Play Store. At 11:14 AM CST, I received the following automated message from “Google Play Support”:
This honestly came as no surprise, we suspected that based on Google’s previous stance on the matter, our application would be removed from the market. However, it is interesting to be told the exact clause of the “Content Policy” that our app supposedly violated. Also, let it be noted that the GTVHacker CubeRoot application was listed on the Play Store for a total of 5 days.
As of today the Asus Cube is still vulnerable to the CubeRoot exploit. So even if you don’t plan on rooting your device with our exploit, you may want to consider using it solely for patching your device from attacks from malicious applications.
You can find a link [HERE] to download CubeRoot.apk.