Posted: April 3rd, 2021 | Author:zenofex | Filed under:Uncategorized | Tags:ORP | Comments Off on ORP – The Open Research Project
We created the Exploitee.rs (formerly GTVHacker) over 10 years ago as a research group with the sole purpose of unlocking embedded devices for the public good. At that time, we were targeting GoogleTV devices but after the death of the platform, we migrated our research into general embedded devices. While each target provided a unique attack surface, we’ve historically relied on custom built tools that we’ve created to assist us in our research. These tools included items such as disassembler plugins which provided insight into interesting places within binaries to analyze or fuzzing harnesses which allowed for continuous background testing while performing our own manual analysis. While these tools have allowed us to focus our time on other areas, as each of us have evolved as researchers, we’ve embraced automation and added more to our internal tooling. This methodology has unfortunately provided more data output than we’ve been able to analyze and in some cases, we believe it has prevented vulnerabilities from being disclosed as quickly as could have been possible otherwise. While we’ve also looked at open sourcing our tooling, we prefer to keep the code private as we consider it valuable to our own future research.
Therefore, today we would like to introduce you to what we’ve been internally calling The Exploiteer’s Open Research Project (ORP). ORP will consist of a number of chat bots conducting automated research on different items including fuzzing open source projects, auditing APKs, and performing IOT firmware analysis. These bots would then output all results to our Discord chat server for analysis by the Exploitee.rs security community within designated channels. The project will start with the addition of our APK scanning bot which enumerates a list of top APKs within the Google Play store, then proceeds to search the APK and associated libraries for leaked credentials, databases, and private keys. After each round of APK downloading and analysis, the bot will restart allowing for constant testing of the newest top android mobile apps. We plan to evolve this bot to perform a deeper analysis of the APKs at a later point but will use the bots current output as a proof of concept for the general idea of crowdsourcing security analysis.
Example finding from ORP APK bot
We encourage researchers to comb through the results of the data and privately disclose the findings to the APK creators and while we appreciate credit, the goal of the project is to provide a safer environment for users by providing a form of independent checking of the mobile application ecosystem. We’re also hoping to improve the ORP projects output by collaborating with other researchers, so if you have an idea for an improvement or suggestion, please don’t hesitate to let us know.
If you’re interested in ORP, learning from other researchers, or Exploitee.rs in general, come chat with us on our Discord chat server. We have a great community, we’re friendly and most of us don’t bite.
Today, we’re going to talk about how the patch that was supplied for the vulnerability was inadequate in blocking exploitation, show how to bypass the resulting fix, and releasing a bash one-liner resulting in remote code execution in the latest vBulletin software.
CVE-2019-16759
The vulnerability mentioned above was later formally labeled “CVE-2019-16759” and a patch was issued on September 25, 2019. Although the patch was provided in just under 3 days, the patch seemed, at the time, to fix the proof of concept exploit provided by the un-named finder.
The patch(s) consisted of three main changes provided in 2 sets of patches, the first being shown below.
/**
* Remove any problematic values from the template
* variable arrays before rendering
*///for now don't pass the values through. These arrays are potentially large//and we don't want to make unnecesary copies. The alternative is to pass by//reference which causes it's own headaches. It's an internal function and the//relevant arrays are all class variables.privatefunction cleanRegistered(){$disallowedNames=array('widgetConfig');foreach($disallowedNamesAS$name){unset($this->registered[$name]);unset(self::$globalRegistered[$name]);}}
/**
* Remove any problematic values from the template
* variable arrays before rendering
*/
//for now don't pass the values through. These arrays are potentially large
//and we don't want to make unnecesary copies. The alternative is to pass by
//reference which causes it's own headaches. It's an internal function and the
//relevant arrays are all class variables.
private function cleanRegistered()
{
$disallowedNames = array('widgetConfig');
foreach($disallowedNames AS $name)
{
unset($this->registered[$name]);
unset(self::$globalRegistered[$name]);
}
}
The above function was added but unfortunately had to be obtained from the code as opposed to directly from a diff between the two coded bases. This is because vBulletin doesn’t provide the older insecure versions of their software after a patch is released. Therefore, the above code was pulled directly from 5.5.4 Patch Level 2.
The above “cleanRegistered” function was added as the first fix to the vulnerability and simply iterates through a list of non-allowed “registered variables”, deleting their contents when found. This list when added only contained the name of the single variable which contained the php code to execute in the released exploit.
In the next version of the software (vBulletin 5.5.5), the following pieces were added to further prevent future problems with the widget_rendering template code.
diff -ur vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/frontend/applicationlight.php vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/frontend/applicationlight.php
--- vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/frontend/applicationlight.php 2020-08-0806:40:31.356918994-0500+++ vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/frontend/applicationlight.php 2020-08-0806:40:40.577517014-0500@@-286,20+286,32@@thrownew vB5_Exception_Api('ajax','render',array(),'invalid_request');}-$this->router=new vB5_Frontend_Routing();-$this->router->setRouteInfo(array(-'action'=>'actionRender',-'arguments'=>$serverData,-'template'=>$routeInfo[2],-// this use of $_GET appears to be fine,-// since it's setting the route query params-// not sending the data to the template-// render-'queryParameters'=>$_GET,-));- Api_InterfaceAbstract::setLight();+$templateName=$routeInfo[2];+if($templateName=='widget_php')+{+$result=array(+'template'=>'',+'css_links'=>array(),+);+}+else+{+$this->router=new vB5_Frontend_Routing();+$this->router->setRouteInfo(array(+'action'=>'actionRender',+'arguments'=>$serverData,+'template'=>$templateName,+// this use of $_GET appears to be fine,+// since it's setting the route query params+// not sending the data to the template+// render+'queryParameters'=>$_GET,+));+ Api_InterfaceAbstract::setLight();+$result= vB5_Template::staticRenderAjax($templateName,$serverData);+}-$this->sendAsJson(vB5_Template::staticRenderAjax($routeInfo[2],$serverData));+$this->sendAsJson($result);}/**
diff -ur vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/frontend/applicationlight.php vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/frontend/applicationlight.php
--- vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/frontend/applicationlight.php 2020-08-08 06:40:31.356918994 -0500
+++ vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/frontend/applicationlight.php 2020-08-08 06:40:40.577517014 -0500
@@ -286,20 +286,32 @@
throw new vB5_Exception_Api('ajax', 'render', array(), 'invalid_request');
}
- $this->router = new vB5_Frontend_Routing();
- $this->router->setRouteInfo(array(
- 'action' => 'actionRender',
- 'arguments' => $serverData,
- 'template' => $routeInfo[2],
- // this use of $_GET appears to be fine,
- // since it's setting the route query params
- // not sending the data to the template
- // render
- 'queryParameters' => $_GET,
- ));
- Api_InterfaceAbstract::setLight();
+ $templateName = $routeInfo[2];
+ if ($templateName == 'widget_php')
+ {
+ $result = array(
+ 'template' => '',
+ 'css_links' => array(),
+ );
+ }
+ else
+ {
+ $this->router = new vB5_Frontend_Routing();
+ $this->router->setRouteInfo(array(
+ 'action' => 'actionRender',
+ 'arguments' => $serverData,
+ 'template' => $templateName,
+ // this use of $_GET appears to be fine,
+ // since it's setting the route query params
+ // not sending the data to the template
+ // render
+ 'queryParameters' => $_GET,
+ ));
+ Api_InterfaceAbstract::setLight();
+ $result = vB5_Template::staticRenderAjax($templateName, $serverData);
+ }
- $this->sendAsJson(vB5_Template::staticRenderAjax($routeInfo[2], $serverData));
+ $this->sendAsJson($result);
}
/**
This portion of the patch created an if statement that would return empty template or css data if the ‘widget_php’ template was listed as the last portion of the route. These two changes prevented the PoC from functioning in its released state.
The third change can be found in the second part of the vBulletin 5.5.5 update diff.
diff -ur vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/template/runtime.php vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/template/runtime.php
--- vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/template/runtime.php 2020-08-08 06:40:31.276913797 -0500+++ vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/template/runtime.php 2020-08-08 06:40:40.493511575 -0500@@ -12,6 +12,26 @@
class vB5_Template_Runtime
{+ //This is intended to allow the runtime to know that template it is rendering.+ //It's ugly and shouldn't be used lightly, but making some features widely+ //available to all templates is uglier.+ private static $templates = array();++ public static function startTemplate($template)+ {+ array_push(self::$templates, $template);+ }++ public static function endTemplate()+ {+ array_pop(self::$templates);+ }++ private static function currentTemplate()+ {+ return end(self::$templates);+ }+
public static $units = array(
'%',
'px',
@@ -1944,6 +1964,21 @@
return '<div style="border:1px solid red;padding:10px;margin:10px;">' . htmlspecialchars($timerName) . ': ' . $elapsed . '</div>';
}}++ public static function evalPhp($code)+ {+ //only allow the PHP widget template to do this. This prevents a malicious user+ //from hacking something into a different template.+ if (self::currentTemplate() != 'widget_php')+ {+ return '';+ }+ ob_start();+ eval($code);+ $output = ob_get_contents();+ ob_end_clean();+ return $output;+ }}
diff -ur vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/template/runtime.php vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/template/runtime.php
--- vBulletin/vBulletin/vb5_connect/vBulletin-5.5.4_Patch_Level_2/upload/includes/vb5/template/runtime.php 2020-08-08 06:40:31.276913797 -0500
+++ vBulletin/vBulletin/vb5_connect/vBulletin-5.5.5/upload/includes/vb5/template/runtime.php 2020-08-08 06:40:40.493511575 -0500
@@ -12,6 +12,26 @@
class vB5_Template_Runtime
{
+ //This is intended to allow the runtime to know that template it is rendering.
+ //It's ugly and shouldn't be used lightly, but making some features widely
+ //available to all templates is uglier.
+ private static $templates = array();
+
+ public static function startTemplate($template)
+ {
+ array_push(self::$templates, $template);
+ }
+
+ public static function endTemplate()
+ {
+ array_pop(self::$templates);
+ }
+
+ private static function currentTemplate()
+ {
+ return end(self::$templates);
+ }
+
public static $units = array(
'%',
'px',
@@ -1944,6 +1964,21 @@
return '<div style="border:1px solid red;padding:10px;margin:10px;">' . htmlspecialchars($timerName) . ': ' . $elapsed . '</div>';
}
}
+
+ public static function evalPhp($code)
+ {
+ //only allow the PHP widget template to do this. This prevents a malicious user
+ //from hacking something into a different template.
+ if (self::currentTemplate() != 'widget_php')
+ {
+ return '';
+ }
+ ob_start();
+ eval($code);
+ $output = ob_get_contents();
+ ob_end_clean();
+ return $output;
+ }
}
This portion was added as a layer of redundancy to attempt to prevent any non ‘widget_php’ template from loading the eval code. Based on the comment in the code, this is an attempt to prevent a user from modifying a template to incorrectly call the ‘evalPhp’ without doing so from an embedded php widget.
Problems Ahead
The problem with the above arises because of how the vBulletin template system is structured. Specifically, templates aren’t actually written in PHP but instead are written in a language that is first processed by the template engine and then is output as a string of PHP code that is later ran through an eval() during the “rendering” process. Templates are also not a standalone item but can be nested within other templates, in that one template can have a number of child templates embedded within. For example, take the following template.
Then after being rendered, when the code is later pushed through the eval process, the other portion of its child templates are loaded and also ran through eval.
This type of system may seem innocuous to the untrained eye but the approach opens up a number of issues beyond just the insecure uses of an eval calls.
Regardless, here are a few ways this can fail.
Any non-filtered modifications to the output variable will open up the code for another code execution.
Constant filtering required of all template code for situations which can create non-escaped PHP.
XSS filtering nightmares
Included child code will have access to parent declared variables.
I cannot think of many situations where this would be the optimal approach. However, to keep this analysis to the point, I’ll focus on the issues leading to a bypass.
Bypassing CVE-2019-16759
The patch code mentioned in one of the previous sections above may seem thorough, but the approach is actually somewhat short sighted. Specifically, the patch faces issues when encountering a user controlled child template in that a parent template will be checked to verify that the routestring does not end with a widget_php route. However we are still prevented from providing a payload within the widgetConfig value because of code within the rendering process, which cleans the widgetConfig value prior to the templates execution. This problem is remedied for us because of a lucky solution manifesting in the following template.
The template “widget_tabbedcontainer_tab_panel”, which is displayed above is a perfect assistant in bypassing the previous CVE-2019-16759 patch because of two key features.
The templates ability to load a user controlled child template.
The template loads the child template by taking a value from a separately named value and placing it into a variable named “widgetConfig”.
These two characteristics of the “widget_tabbedcontainer_tab_panel” template allow us to effectively bypass all filtering previously done to prevent CVE-2019-16759 from being exploited.
PoC
Because of the vulnerabilities simplicity, creating a one line command line exploit is as simple as the following.
This fix will disable PHP widgets within your forums and may break some functionality but will keep you safe from attacks until a patch is released by vBulletin.
Go to the vBulletin administrator control panel.
Click “Settings” in the menu on the left, then “Options” in the dropdown.
Choose “General Settings” and then click “Edit Settings”
Look for “Disable PHP, Static HTML, and Ad Module rendering”, Set to “Yes”
Hello and happy Halloween fellow Exploitee.rs. Today we’re excited to be bringing you something we’ve been working on for the last few months. Today, we’re introducing you to FireFU. FireFU is an exploit chain we’ve created to allow users to unlock (and root) their FireTV Cube and FireTV Pendant.
WARNING
Exploitee.rs would like to remind users that any flashing of unofficial firmware or usage of provided tools is done at your own risk and will likely void your device’s warranty.
DFU Mode
This exploit chain relies on two primitives, the first being a read/write primitive leveraged from the DFU mode accessible from the Amlogic S905Z SoC. DFU mode can be accessed on these devices by utilizing HDMI’s I2C bus and sending a specific string (“boot@USB”) to the device during boot. An adapter can be made which enters DFU by cutting open a HDMI cable or simply purchasing an HDMI header, then connecting to the appropriate I2C pins from the HDMI to the I2C pins on an Arduino or compatible board. We have provided an arduino “sketch” that can be compiled and loaded onto an arduino then used to perform the software side of entering DFU.
Upon accessing DFU mode, we are given access to read and write portions of the FireTV’s memory. Through this we target the hardware registers for the eMMC controller giving us the new primitive of being able to read and write to the device’s eMMC flash. However, due to both devices having secure boot enabled, we are unable to directly leverage the primitives we currently have to run unsigned code. We however did discover another vulnerability that we can use.
U-Boot Heap Overflow
In a secure boot environment, each portion of the boot process checks and sets up the following. From the SoC ROM all the way to the kernel and some cases even the kernel modules. In order to run unsigned code, a weakness needs to be found in some portion of the secure boots “chain of trust”. After a bit of research, we stumbled onto the perfect vulnerability we could leverage to break the chain. This vulnerability consisted of a heap overflow within U-Boot triggered when reading the RSV info within the devices partition table. This overflow can be seen in the code below.
436/* get ptbl from rsv area from emmc */437staticint get_ptbl_rsv(struct mmc *mmc, struct _iptbl *rsv)438{439struct ptbl_rsv * ptbl_rsv =NULL;440 uchar * buffer =NULL;441 ulong size, offset;442int checksum, version, ret =0;443struct virtual_partition *vpart = aml_get_virtual_partition_by_name(MMC_TABLE_NAME);444445 size =(sizeof(struct ptbl_rsv)+511)/512*512;446if(vpart->size < size){447 apt_err("too much partitons\n");448 ret =-1;449goto _out;450}451 buffer =malloc(size);452if(NULL== buffer){453 apt_err("no enough memory for ptbl rsv\n");454 ret =-2;455goto _out;456}457/* read it from emmc. */458 offset = _get_inherent_offset(MMC_RESERVED_NAME)+ vpart->offset;459if(size != _mmc_rsv_read(mmc, offset, size, buffer)){460 apt_err("read ptbl from rsv failed\n");461 ret =-3;462goto _out;463}464465 ptbl_rsv =(struct ptbl_rsv *) buffer;466 apt_info("magic %s, version %s, checksum %x\n", ptbl_rsv->magic,
467 ptbl_rsv->version, ptbl_rsv->checksum);468/* fixme, check magic ?*/469if(strcmp(ptbl_rsv->magic, MMC_PARTITIONS_MAGIC)){470 apt_err("magic faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);471 ret =-4;472goto _out;473}474/* check version*/475 version = _get_version(ptbl_rsv->version);476if(version <0){477 apt_err("version faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);478 ret =-5;479goto _out;480}481/* check sum */482 checksum = _calc_iptbl_check(ptbl_rsv->partitions, ptbl_rsv->count, version);483if(checksum != ptbl_rsv->checksum){484 apt_err("checksum faild 0x%x, 0x%x\n", ptbl_rsv->checksum, checksum);485 ret =-6;486goto _out;487}488489 rsv->count = ptbl_rsv->count;490memcpy(rsv->partitions, ptbl_rsv->partitions, rsv->count *sizeof(struct partitions));491492 _out:493if(buffer)494free(buffer);495return ret;496}
436 /* get ptbl from rsv area from emmc */
437 static int get_ptbl_rsv(struct mmc *mmc, struct _iptbl *rsv)
438 {
439 struct ptbl_rsv * ptbl_rsv = NULL;
440 uchar * buffer = NULL;
441 ulong size, offset;
442 int checksum, version, ret = 0;
443 struct virtual_partition *vpart = aml_get_virtual_partition_by_name(MMC_TABLE_NAME);
444
445 size = (sizeof(struct ptbl_rsv) + 511) / 512 * 512;
446 if (vpart->size < size) { 447 apt_err("too much partitons\n"); 448 ret = -1; 449 goto _out; 450 } 451 buffer = malloc(size); 452 if (NULL == buffer) { 453 apt_err("no enough memory for ptbl rsv\n"); 454 ret = -2; 455 goto _out; 456 } 457 /* read it from emmc. */ 458 offset = _get_inherent_offset(MMC_RESERVED_NAME) + vpart->offset;
459 if (size != _mmc_rsv_read(mmc, offset, size, buffer)) {
460 apt_err("read ptbl from rsv failed\n");
461 ret = -3;
462 goto _out;
463 }
464
465 ptbl_rsv = (struct ptbl_rsv *) buffer;
466 apt_info("magic %s, version %s, checksum %x\n", ptbl_rsv->magic,
467 ptbl_rsv->version, ptbl_rsv->checksum);
468 /* fixme, check magic ?*/
469 if (strcmp(ptbl_rsv->magic, MMC_PARTITIONS_MAGIC)) {
470 apt_err("magic faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);
471 ret = -4;
472 goto _out;
473 }
474 /* check version*/
475 version = _get_version(ptbl_rsv->version);
476 if (version < 0) { 477 apt_err("version faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);
478 ret = -5;
479 goto _out;
480 }
481 /* check sum */
482 checksum = _calc_iptbl_check(ptbl_rsv->partitions, ptbl_rsv->count, version);
483 if (checksum != ptbl_rsv->checksum) {
484 apt_err("checksum faild 0x%x, 0x%x\n", ptbl_rsv->checksum, checksum);
485 ret = -6;
486 goto _out;
487 }
488
489 rsv->count = ptbl_rsv->count;
490 memcpy(rsv->partitions, ptbl_rsv->partitions, rsv->count * sizeof(struct partitions));
491
492 _out:
493 if (buffer)
494 free (buffer);
495 return ret;
496 }
Specifically, by providing a high enough value to the number of entries in the RSV table (rsv->count on line 490), we are able to overflow the heap allocation and obtain a new write primitive. Through this primitive (and all within the exploit’s payload) we modify values in memory for U-Boot tricking the device into believing it is unlocked and disabling all signature verification. Due to the exploit being ran during each boot, the U-Boot code needs to only be patched in memory. However, because the exploit is now being stored in the original RSV location in flash, we must move the old RSV values to a new area and fixup any addresses pointing to the previous location. After a reboot and successful exploitation, the Fire TV device will be able to run unsigned code.
Fastboot
To simplify flashing of new images, we’ve chosen to use flashboot to flash a new recovery and boot.img to the device, this new recovery only provides the fixups needed to point to the new RSV location. The boot.img however includes “magisk”, a popular android root application, to facilitate providing the user root access to the device.
Technical Details & Instructions
Technical details for the exploit chain is available on our wiki as well as usage instructions, source code, and information on needed hardware/tools.
Posted: August 18th, 2017 | Author:zenofex | Filed under:Uncategorized | Comments Off on All Your Things Are Belong To Us
We’re back from Vegas and it’s time to reflect. This year in Las Vegas, we were given the opportunity to present our research at both BlackHat USA 2017 and DEFCON 25. At BlackHat, we presented on reverse engineering embedded devices with eMMC flash in our talk, “Hacking Hardware With A $10 SDCard Reader.” At DEFCON, we came back and did a remake of one of our most popular presentations (“Hack All The Things“) with, “All Your Things Are Belong To Us.” The experience was amazing and we’re grateful to both conferences for letting us come out and present to you all. This blog post will be a summary of everything we revealed from both conferences and will hopefully guide visitors around all of the new stuff we’ve posted.
At BlackHat, our presentation was geared toward giving attendees a strategy for attacking devices with eMMC flash storage. In this presentation we showed attendees how to identify eMMC pinouts as well as tips on how to connect to an eMMC flash with a standard SD card reader and as few as 4 wires. If you’re interested in checking out the research, you can find the slides on our wiki along with our white-paper on the subject.
At DEFCON, our “All Your Things Are Belong To Us” presentation showcased exploits for a variety of new embedded devices. Below is a list with the corresponding new wiki pages for the new material we’ve added.
We dropped a lot of vulnerabilities on the audience at DEFCON, but a few of the highlights include bugs such as the remote root vulnerability we found within the QNAP NAS devices. This vulnerability affects a network transcoding service and allows for command injection as the root user. Then, there are the two vulnerabilities we found within the Western Digital MyCloud series of devices, a series of devices we’ve released multiple bugs for in the past; these pre-auth bugs both allow for remote code execution. The first one has the primitive of being able to write a file anywhere on disk, allowing us to write a PHP shell to the device for remote code execution as root. The other vulnerability is an authentication bypass which can be paired with any of our previously released (and unfixed) post authentication bugs for remote code execution as root. Beyond just the 3 NAS bugs, we’ve documented multiple hardware (UART/eMMC) roots, USB roots, and even a pre-auth root vulnerability affecting an SDK used in dozens of products.
You can find the slides for “All Your Things Are Belong To Us” and all of our previous presentations on the front page of our wiki (or HERE)
Finally, at DEFCON and BlackHat, attendees of our presentations received some new hardware we recently created. Particularly, they received our new SD & Micro SD Breakout boards which can be used with SD card readers to read 3.3v logic eMMC flash storage devices. These new boards will be available for sale in our online store soon and will be given away with orders from our online store (1 with every order).
If you attended either of our presentations, we’d like to say thank you for coming out and we hope you enjoyed getting to hear our latest round of research. If you didn’t, we hope you’ll check out our videos or slides. We love getting to spend time with the community and we hope we inspire you to “Hack Everything.”
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.
Login Bypass
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.
/lib/login_checker.php
function login_check()
{
$ret = 0;
if (isset($_SESSION['username']))
{
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
}
return $ret;
}
The above code contains a function called “login_check”, this function is used by all of the backend PHP scripts and is used to verify pre-authenticated users. The above code has two paths, one which involves checking the session values for “username” and “isAdmin” and another (if the prior fails) attempts to complete the same process but with cookies. Because cookies are supplied by the user, the requirements that the scripts are looking for can be met by the attacker. The above process for sessions and cookies is summed up as follows.
“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.
/var/www/web/lib/login_checker.php
20 function login_check()
21 {
22 $ret = 0;
23
24 if (isset($_SESSION['username']))
25 {
26 if (isset($_SESSION['username']) && $_SESSION['username'] != "")
27 $ret = 2; //login, normal user
28
29 if ($_SESSION['isAdmin'] == 1)
30 $ret = 1; //login, admin
31 }
32 else if (isset($_COOKIE['username']))
33 {
34 if (isset($_COOKIE['username']) && $_COOKIE['username'] != "")
35 $ret = 2; //login, normal user
36
37 if ($_COOKIE['isAdmin'] == 1)
38 $ret = 1; //login, admin
39
40 if (wto_check($_COOKIE['username']) === 0) //wto check fail
41 $ret = 0;
42 }
43
44 return $ret;
45 }
46 ?>
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.
/var/www/web/lib/login_checker.php
3 /*
4 return value: 1: Login, 0: No login
5 */
6 function wto_check($username)
7 {
8 if (empty($username))
9 return 0;
10
11 exec(sprintf("wto -n \"%s\" -i '%s' -c", escapeshellcmd($username), $_SERVER["REMOTE_ADDR"]), $login_status);
12 if ($login_status[0] === "WTO CHECK OK")
13 return 1;
14 else
15 return 0;
16 }
17
18 /* ret: 0: no login, 1: login, admin, 2: login, normal user */
19
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.
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
username=$(touch /tmp/1)
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.
Other Errata
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:
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.
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.
Responsible Disclosure
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.
Scope
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
More Info
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
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.
Web Interface
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.
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!
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.
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: 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.
ometimes 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.
