 want to welcome you guys to the official LionCon after party. We are excited you guys are here. We're really excited to share our research with you. My name is Mark Newlin and I work as a wireless security researcher at Bestial Networks. You may have seen some of my work last year. I did a couple of projects called Mousetrap and Key Sniffer, a bunch of vulnerabilities that I found in wireless mice and keyboards, which I presented here at Defcon. Two other projects I've worked on that are kind of interesting are these two DARPA challenges. I competed in the DARPA Shredder Challenge in 2011, which was a competition to reassemble Shredder documents. And I wrote some cool software for that and finished that competition in third place out of the 9,000 teams. Then I went on to do the DARPA Spectrum Challenge, which is how I got into software-defined radio. And despite not going to college myself, I managed to best some other university teams and finish the first tournament of that competition in second place. Hey, what's going on everybody? My name is Christopher Grayson. My handle is lava lamp. I'm originally from Atlanta. I went to Georgia Tech twice. I've been a research scientist with DARPA working on the DARPA Center program. I used to be the head of the Georgia Tech Hacking Club. I've also been a security consultant with the Boutique Security Consultancy Bishop Fox. And most recently, I am the founder and principal engineer of a software security platform entitled Website, which I open sourced all the software for a few days ago at Arsenal. So if you like attack surface enumeration, you should totally check it out. Hey everyone, I'm Logan Lamb. I professional start at Oak Ridge National Lab, where I focus primarily on static and symbolic analysis of binaries. From there, I went to Bastille Networks, where I'm currently at, doing wireless work with software-defined radio. Some previous work you all may be familiar with. In 2014, I found some vulnerabilities affecting home security systems. And I was actually supposed to be up on one of these stages back then, but it didn't quite work out. However, it did lead to a lawsuit and a $16 million settlement from ADT. So that's something. More recently, I found some vulnerabilities affecting the election systems in the state of Georgia. And that's culminated in an ongoing lawsuit to contest the results of the most recent special election. So the scope of this talk is 26 vulnerabilities we have discovered in ISP provided wireless gateways, set-top boxes, and voice emotes. We found vulnerabilities in hardware from Cisco, RS, Technicolor, Motorola, and Xfinity. We have multiple unauthenticated remote code execution attack chains. And we have a variety of both network and application vulnerabilities, some Wi-Fi vulnerabilities, and then some ZigBee RF4CE vulnerabilities. And you might be asking yourself, you know, why does this matter? We see cable modem vulnerabilities and Wi-Fi vulnerabilities fairly frequently, but the scope of this is unlike anything that's been done fairly recently. We have some vulnerabilities that are specific to certain hardware vendors. And the majority of the vulnerabilities we found are in the open-source software stack called RDK, which runs on many of the devices we looked at. And I want to point out that the attack chains affecting the Comcast Xfinity devices have been remediated as of today. We're going to start with some background on the RDK software stack. Then we're going to get into some of the type of devices that run RDK. We're going to tell you about where this project started and how we got these things to where we are now. We're then going to get into the meat of the talk, which is the vulnerabilities we found. Now I want to point out that we found too many vulnerabilities to cover in depth in 45 minutes. But we do have a 35-page white paper that is up on GitHub right now that we recommend you read if you want more details. We're then going to discuss the specific devices we looked at, as well as a disclosure process and remediation actions taken by the affected vendors. And then hopefully we'll have a few minutes for Q&A. Cool. So we're going to start off with a little bit of a background on RDK. So, you know, we start looking at these modems in these set-top boxes. We gain a shell. We get access to the file system. Start looking around. And we keep seeing references to this acronym RDK. And we don't really know what it is. But doing a little bit more digging, it's the reference development kit. And basically what this is, is an open-source software stack that is designed to be placed on consumer premise equipment that deals with media. So we're talking about cable mode. We're talking about set-top boxes. We're talking about basically anything that goes in a home that has to deal with media. And so, you know, we see this as like, oh, cool. We really like open-source software. It's pretty cool that open-source software is being deployed on these devices. That's fantastic. And so the RDK codebase actually was founded in 2012. And then we do a little bit more digging. And so this is really like open-source question mark software. So before we realized that it was open-source, we thought that we stumbled upon like, you know, a treasure trove of data that we weren't supposed to be able to have access to because we found all of the code. So like we're talking about the different web applications. We're talking about the operating system, the various like daemons that reside on these devices. But then we're like, oh, it's actually open-source. Okay, well, this isn't such a great find anyways. So you can right now go to code.rdkcentral.com and pull down all of this software if you want to take a look. And so we're really feeling pretty jazzed about this. It's pretty cool that all this open-source software is being deployed. And then we do a who is lookup on rdkcentral.com. And that's when the eyebrows started being raised. If you can see what's over here on the screen, the technical name for the who is record for rdkcentral.com is Comcast Domains. So this is where things start getting a little bit harrier because you can go to this website, you can pull down these repos. And you can do get log and grep for the word vulnerability. And you'll get pages and pages of volums that have been patched in this software. And that's not necessarily a bad thing. You know, we definitely want these volums to be patched. We want the software that we use to be secure. But where this gets a little bit kind of weird is these patches are not really being pushed to consumers in any rapid kind of process. So we're looking at 6 to 12 to 18 months before these patches that are in these publicly available repositories are actually pushed to consumer premise equipment. So what sort of vulnerabilities are we talking about? Well, it really runs the gamut. We're talking about remote code execution, cross-site scripting, cross-site request forgery, memory corruption. You name it, they got it. And if you go to these repositories and look for these changes, like these are vulnerabilities that are present in these code bases. And so the thing that really kind of made our eyes, brows, raises the most was that as far as we could tell, you know, these are non-vulnerabilities. They're being patched. None of the customers that these affect are being informed. And there are no CVEs being filed for either. All right, y'all. So I'm going to give a quick overview of the devices that run RDK, give you some reasons ISPs choose RDK and point out some salient tidbits that will be relevant later in the talk. So there are two major categories of devices that run RDK. The first is set top boxes, which run RDK video. The second are gateways, which run RDK broadband. A gateway in most literal sense is a combination modem and Wi-Fi access point. So why do ISPs choose RDK? Well, they choose RDK because it gets them about 90% of the way to a completed software stack. It comes out of the box with fantastic remote management for when you need to manage tens of millions of devices. It has excellent diagnostics, very verbose logging. I hear they have a security subsystem. We haven't actually seen that yet, but I hear it's a thing. And they have a media framework, which runs on RDK video. And it's pretty neat. In the media framework, you have closed captioning video on demand, pay per view. It handles the transport of audio and video to your television, and it does DRM, all out of the box. Okay, so RDK video. This device that you're looking at right now, it's a Motorola XG1 set top box. This is the same one that we shelled working on it in Atlanta. We haven't actually taken one of these apart yet. This is a picture from the FCC documentation. We didn't need to take apart. Once you get a shell on one of these devices, it really just looks like any other embedded Linux device. It's really architecturally not that interesting. It's just running a lot of RDK based software. There should be a lot of future work here. There's all sorts of IO and we have TR069 and Mocha over Coax. You guys should look at that. Things to remember for later. The way these devices work, everything you see and hear on your television is actually being rendered inside of a WebKit based browser engine. Meaning everything is happening inside of a browser on your set top box. That's pretty cool, right? It makes development a lot easier. What could possibly go wrong? What could possibly go wrong? You can plug in a keyboard and mouse and interact with your set top box. That's cool. At least it's important later on. Alright, so now we come to gateways. RDK broadband. In the most literal sense, it's a combination modem and router in one enclosure. In RDKB parlance, we have a network processor and an application processor. We've cracked apart at least half a dozen makes and models of these devices. And they all are nearly exactly the same, both internally and externally. You have two distinct systems on a single board running two different operating systems. They normally run embedded Linux, but every once in a while we'll see one running ECOS, which is a real time operating system on the network processor. And these two devices communicate over a switch in ways that are defined by RDK broadband. Things to remember for later in the talk. Just because you pop one of these devices doesn't necessarily mean you fully own the entire box, right? I don't know about that. Oh, we'll find out. I'll see. And Puma is Intel's take on RDK broadband hardware architecture. And for Intel Puma, the network processor is an ARM core and the application processor is an ARM core. So after I finished research on the Mousetrack and Gistifer projects, I knew I wanted to do more vulnerability research, but I didn't have a good concept of what devices would be fun to look at. And at this point I was still kind of naively assuming that these mature devices from big industry players are going to be well locked down and free of vulnerabilities. And as we'll see, this is not the case, but this is my assumption at the time. So last year I made my way to hack in the box in Amsterdam. I saw a talk by Peter Geisler. And Peter had demonstrated that he could reverse engineer the algorithm that used to generate the default SSID and pass phrase on the wireless gateway provided by his ISP. And this was kind of a light bulb moment when I realized that people were still finding interesting wireless vulnerabilities in this ISP provided equipment. So I decided I would go home and do the same with my ISP gear at home. And unfortunately I had a pretty busy year last year. And so it wasn't until December when I had time to look at this. And so I started to look at this project. And about a week later I was dropping my keys off at Chris's house because he was kind enough to watch my cats when my fiance and I were up in Seattle for Christmas. And it turned out that Chris was a prior customer at the same ISP and it also looked at his wireless gateway once upon a time. And we both had an interest in this type of research. So we decided to team up and see what we could find. And the nice thing about Chris is that he has a background in pen testing. So he knew about things like application security and network security. And so at first night he taught me what Netcat was. He taught me how to use Nmap. And we were able to leverage a previously disclosed vulnerability in the wireless gateway I used to pull off the file system. We're also able to start digging into the art of care to just get a general idea of how these devices operated. And pretty soon we had some novel vulnerabilities. And soon after that we had some novel wireless vulnerabilities. And at this point we brought the project to my employer bestial which is a wireless security company and we disclosed everything through my work. After some more vulnerabilities and some more work on this Chris and I had an impasse where we needed some hardware expertise. So we brought Logan into the fold to leverage his hardware and embedded expertise. And then we were able between the three of us to find all kinds of vulnerabilities in these wireless gateways and then leverage what we were able to do with the wireless gateways to start getting root shells on the set up boxes. And because we were finding these vulnerabilities over the course of several months we disclosed the vulnerabilities to be affected vendors in four groups. So now let's get into the really fun part of the talk which is these vulnerabilities. And that's my cat Tim by the way. So you know because my initial interest in this was sparked by Peter Geiser's talk I was hoping to figure out how the default wifi SSID and passphrase were generated on my wireless gateway. And I never forget that out but my motivation was to really look at the different wireless things running on this box. And one of the first things Chris and I discovered is that there are multiple plain text configuration files which contain all kinds of hard coded credentials and dynamic credentials including all of the wifi configuration for the devices. And I saw what appeared to be a hidden wifi network that I was not previously aware of on my device. And it had an SSID of XHS hyphen and then 8 hex characters representing the lower four bytes of the CMAC on my wireless gateway. And the CMAC is not normally known and it's a unique identifier for the device used for provisioning and other things. And the passphrase for this hidden wifi network was 16 hex characters and this just felt like it was going to be generated dynamically. So I started rocking around for words like calculate and generate and XHS and key and PSK. And pretty soon I found this method called calculate PSK key in a shared library. What could that function possibly do? So the shared library it turns out has extremely verbose debug output by printf statements. So I was able to run just strings on the shared library and trace the flow of execution through this method. And it appeared that it was consuming a MAC address and spitting out a wifi passphrase. So I bubbled around and got together a cross compilation tool chain and I compiled a binary which linked against a shared library, put it on the gateway and ran it and it actually consumed the CMAC and produced a passphrase for this hidden wifi network. And so there is a hidden home security wifi network on these devices. So if you have this home security service provided by these ISPs you can get a wireless touch screen control panel which connects to the internet through your wireless gateway and the way it connects to the wireless gateway is through this hidden home security wifi network. The thing is that I did not have the home security service so this network was enabled even though I did not have the service. So now we have a hidden wifi network on my wireless gateway. We know that if we were on this network we found multiple network services which we can exploit for root command execution. So now the question is how do we get the CMAC to generate the credentials for this hidden wifi network. So it turns out that a lot of these devices have a public wifi hotspot in this case Xfinity wifi and if you're a customer of this ISP you can connect to this wifi network on any one of these devices and access the internet. It's a pretty cool service. But it turns out that when you connect to this wifi network you get a DHCP lease and the DHCP act you connect to this public wifi hotspot in the DHCP act you get the CMAC and then generate the credentials for the hidden wifi network, connect to that and get root on the box. Good good. And so it turns out there's also a IPv6 multicast packet that's broadcast unencrypted every four seconds from these devices. And this packet I'm not quite sure why this is transmitted but it contains the MAC address of another network interface on the device. This is the L2SD 0.500 network interface. The MAC address of this network interface has a deterministic offset from the CMAC so you can listen to the wifi channel that the device is using for four seconds retrieve this packet, convert that MAC address into the CMAC, generate the credentials and root the box. Then a lot of these devices also have VOIP service. The VOIP interface has a public IPv4 address. That public IPv4 address has a fully qualified domain name which contains the MAC address of the network interface used for this VOIP connection. Also in this FQDN is a region code and you can deterministically translate this MAC address into the CMAC. So this means that you can get a reverse DNS database pull down the list of all of the possible VOIP MAC addresses in your region turn those into CMACs and the full list of all the hidden SSIDs and passwords in your region. And as I was thinking about these MAC addresses and IP addresses I noticed that the IPv6 address of the WAN0 interface on these devices was generated from the CMAC. And the WAN0 interface in this case is facing the Comcast infrastructure. And so if you know anything about IPv6 it's a 64 bit address which is a pretty large search space but if you generate it from a known 32 bit address it's much easier to find. So we're trying to figure out why might they be generating these IPv6 addresses from the CMACs. And so it turns out that on these devices you have a web UI that can hit from the LAN but if you hit the device from this ISP facing IPv6 address you can also log in to the web UI with hard coded or daily generated credentials or log in via SSH. And we weren't sure how exactly we could access this because we are as a customer not on the ISP network. So it turns out there's a service called Xfinity Send to TV. This is pretty cool so you can go to xfinity.com slash send to TV you put in a URL, you hit go, log in with your ISP credentials and then on your TV via your set top box you can view this wireless gateway. Well, it turns out they can actually load up the web UI and you look like you're coming from the ISP infrastructure and then you can log in to this with either hard coded credentials or daily generated credentials. So these daily generated credentials are called a password of the day. This is used by many ISPs, we've only looked at the Comcast variant. In this case there's actually a binary which resides on the wireless gateway which generates this by a cron job that can actually generate all the future passwords of the day for these devices. We're going to do, we're going to show you a quick video of what that actually looks like. And so what you're going to see in this video is using the Send to TV service you're going to see that we are gaining access to another modem via that process and at the end of the video you'll see what happened once the actual path was applied and see that instead of gaining access to that we're putting in the IPv6 address of a wireless gateway from a different customer account than the Set.box we're using. So this is on the TV we're watching some NASA stuff as you do and all of a sudden we have this access. And this is hard coded credentials to log into another customer's wireless gateways web UI. And here's the video of it not working. Now that it's been patched this is no longer possible. And so I've been spending a lot of time thinking about the wireless devices in different ways and so I decided to take a look at these public Wi-Fi hotspots and the way this works if you're a customer you can connect to any one of these Wi-Fi hotspots you sign in with your ISP username and password and then you get to access the internet which is pretty great because then you have some tens of millions of free Wi-Fi hotspots around the country. The next time you sign in or connect to one of these you do not have to provide your credentials what's happening is that your device is remembered based on the MAC address of the authenticated and connected devices on these public Wi-Fi hotspots the attacker could then spoof the MAC address of an actual connected customer use that MAC address connect to a different Wi-Fi hotspot and gain the internet access for free. Now what's interesting is that free internet is great but any malicious activity performed by the attacker is an attributed to the customer they're spoofing. Awesome. So we've talked a lot about how you actually gain access to these devices but what do you do once you're on these networks? So I'm going to start with things that you can do there's plenty more we highly recommend that you look at our white paper and the first thing that I'm going to talk about is FastCGI and so FastCGI is a successor to CGI which is a common gateway interface protocol and what CGI is is basically a way for a web server to be able to invoke processes dynamically. So you know back in the day we were only serving up static content from web servers and this is what enabled web servers to invoke a PHP interpreter invoke what have you based on a web request so it's kind of the birth of the dynamic web. So CGI was the initial protocol FastCGI was a improvement upon it it had a bunch of obvious speed up gains and one of the other things it implemented as well was not only could you now listen on Unix domain sockets but you could also listen on TCP sockets what could possibly go wrong. So the interesting thing about this is there's actually no RFC for FastCGI and it's relied upon by a bunch of web servers you've probably never heard of like Apache and Nginx and like Sunwebserver and like really everything uses FastCGI but there's still no RFC. If anybody can find an RFC please let us know the only documentation that we could find is actually the white paper from the MIT student that drafted this protocol back in 1996. So something that's ubiquitously relied upon but the most recent documentation we have is 21 years old. This is an operation that the FastCGI service can operate in one of which is Responder and so Responder is I'm going to talk to you via this FastCGI protocol I'm going to give you a bunch of information about an HTTP request and I'm going to specify a file path on the local disk and that's the file that I want you to pass to the interpreter. The authorizer mode of operation is I'm going to give you all the information about the HTTP request via the FastCGI protocol and then instead of giving me back any content or know this request is not authorized the third mode of operation which I have yet to find implemented which is very disappointing is called filter and filter is the exact same as Responder where you're going to give it a bunch of information about an HTTP request but instead of specifying a local file path you just give it the file to run. So you can see why I would be disappointed that I haven't found that yet. So let's talk about the PHP FastCGI process manager PHP FPM this is a way PHP deployed on embedded devices very easily I mean you can it's not just embedded devices it's any device but it's very heavily relied upon by embedded devices and it's FastCGI coupled with PHP and it gives you some really cool additional functionality on top of FastCGI like you have the ability to reconfigure the PHP environment on every request. Huh. If anybody's used PHP before you might be like oh that's bad by the way if you're ever doing research and you Google a technology and the first result comes up with a big red box that says hey by the way there's some security precautions you probably want to consider you're going in the right direction I promise. So basically you talk FastCGI you use the binary FastCGI protocol you talk to it you're able to reconfigure the PHP environment on every single request you supply HTTP post data via standard in and so if only there was a way that you could abuse this it turns out there is and basically there is a PHP configuration value that is given a file path and that file path points to a file that is going to be run before the actual file you're requesting so you know maybe the idea behind this is you've got a big PHP application but you have a script that bootstraps your entire environment ahead of time so instead of actually including it or requiring it you just reconfigure PHP to say just run that file before anything else. So PHP also has some really interesting file scheme handlers one of which is PHP colon slash slash STDIN and this is just a reference to standard in. We supply HTTP post data via standard in to the PHP interpreter so how do we put this all together well in the FastCGI request we basically say hey before you run anything else run that file first and the file the script we give it is pointing to standard in to the HTTP post data that we supply is then used as code it's passed to the PHP interpreter. So some of you might be saying that this is old news and to an extent you're right CVE 2012 1823 described precisely this attack chain where you're abusing the PHP configuration to gain code execution that is not this though the difference between the two is that was actually piggybacking on top of an HTTP request so there's a way that you could abuse a query to gain code execution but it was again based on top of an HTTP request this we're just talking straight to the daemon so the daemon is bound on TCP where it's 1026 through 1029 on all interfaces on these RDK devices so if you see it there you can probably talk to it and basically this one of the reasons that this wasn't well we assume one of the reasons that this hasn't been found before is when you end map the API it just sees it as TCP wrap so we also recommend that you check out the Github repository that we supplied alongside our talk because we've written an end map NSD script which will actually identify that CGI and you can do all sorts of fun things with that so one last note before I go on to the next one in PHP FPM as compiled on RDK this functionality has been compiled out you can't actually reconfigure PHP with every request and we could not find any documentation for how you would do this if this is something that's seen as like oh yeah this is a security flaw this is something that we expect you would also anticipate that there's documentation for hey here's how you compile this out but as far as we could find that did not exist so for some reason this has been compiled out we don't know why but it was probably intentional because this is default functionality but lo and behold we didn't actually need it to gain code execution because you can just request files on disk you can bypass the control flow that you would expect to see in the actual web app and create the stuff like that so let's keep it going I'm going to talk about sys-eventd right now you may have heard of sys-eventd before this is what we were this is us actually doing this research so you may have heard of sys-eventd before it's on tcp452.367 the sys-eventd you may have heard of is not this there's oracle sys-eventd this is completely separate this is a proprietary proprietary service built just for RDK and the reason that it exists is you can basically say this event happens on an operating system do xyz so basically event based programming within an operating system for embedded devices there's no authentication no authorization if you know how to talk to protocol fantastic you can do whatever you want with it so in order to abuse this eventd the first thing that you do and also by the way they really handily just provide you with a binary that knows how to speak this protocol in RDK so you don't have to write any of your own stuff but the first step is you set up an event you have two arguments to you basically say here's the binary I want there to be fired and here's the name of the event and that registers the event in the system and then the next thing you do to trigger the event you basically trigger the event name which is what you see up here in step 2 and you pass it an argument and when you do that what happens is the binary that you configured the event with in step 1 is called and the first argument to the binary is the name of the event and the second argument to the binary is the value that you triggered the event with what can you do with this well typically this is what we would assume this is being used for let's say there's a log file that's placed on disk and as soon as that log file is placed on disk it's like oh we want to copy that to a separate directory so that's what you see up here that maybe when this XML file hits the disk it's actually going to be copied into another location to be exfiltrated somewhere else but what we wanted to do was gain arbitrary code execution so if you create an event of bin bash and an event name of dash C then whatever you supply to the event is just passed as arguments to bin bash code execution as root fantastic so where is this at it's bound to all the interfaces across the entire IPv4 address space we found 149,000 instances of it we don't really know why these weren't firewalled off but the majority of them were but basically if you gain access to any of these lands you'll probably see other sys event D or fast CGI and the last thing that I'm going to talk about is a tale of two operating systems so as Logan was talking about before these devices actually have two separate operating systems on them one of them is what you would expect to see when you open up your browser you got to configure your modem that's a 10.0.0.1 that's an arm side and then there's a system on a chip that kind of handles all of the networking stuff that is an atom an atom instance and this is usually at the top of the DHCP range that you're getting leases into right underneath the broadcast address so the atom instance is going to be at 10.0.0.254 in most cases and to this day I don't know why this works so we have a lot of really complimentary skill sets up here so I come over to Mark's place one day and he's teaching himself how to do this networking stuff he's like hey I did this and I was like that's not supposed to work that's not a thing that's not supposed to happen and he said has an interface that has an IP address in the 169.254 range which is not generally supposed to be used it's not supposed to be routable so it turns out that you can add a routing rule to your device that says hey when I'm trying to talk to 169.254.01 10.0.0.254 is my gateway and then you can talk to the private interface on the atom side and it just forage traffic I don't know if that's supposed to happen I really think it's not oh my god and so once you actually have access to this you see the results of the end map output out here you see ports 1026 through 1029 open those are the fast CGI services that we were talking about before again you have code execution fantastic alright y'all so I'm going to walk you through our suite of vulnerabilities affecting set top boxes and voice remotes so the first three effects set top boxes then I'm going to have a hard transition to some wireless work alright so for those of you who don't know Mark Newell is really good at slapping keys okay he's really good at it especially so in the context of set top boxes he plugged a keyboard into his set top box proceeded to touch every key that he could hit every key combination that he could think of and then we this popped up on the television remote web inspector enabled that was surprising also he was fashion a bunch of stuff and like the screen split in two it was pretty wacky but this is in fact real life so remote web inspector it's basically fire bug for firefox or dev tools for chrome where web developers can debug their web pages and that's really great when you're trying to find vulnerabilities in something that's running this and you can actually hit this from over the internet so that's pretty cool right so there was another key combination that you could hit and it would pull up a hidden diagnostic menu I'm totally that guy somebody's dying I'm pretty sure I'm totally that guy alright so we could hit a key combination and pull up a hidden diagnostics menu we just perused this diagnostics menu and looked at the network traffic between the set top box and the services it was hitting low and behold there was a route just by the name of the route made us think we could get arbitrary file reads on the set top box if you were to post a legitimate file route file path to a file on the file system you could just get the contents of that file and it worked yeah so that's kind of neat right and since this is rdk and it's so standardized we already had a good idea of all of the interesting things we wanted to look at so for those of you who don't know I've got a pro tip it's generally best not to get random input from the internet and then execute it locally especially as route you're not supposed to do that no I don't think so so sanitize your inputs guys I think it's not the 90s anymore we found a route essentially post to this route a parameter that was a shell command and we could just shell the box gg easy mode hard transition now we're getting to some wireless work what you see up on the screen is an xr11 voice remote and these are actually pretty cool so the way they work once you pair it with your set top box they communicate over rf instead of ir so you can be super lazy and just point it anywhere you want also they have a built-in microphone and a button and you press the button and you talk to the mic and you're like hey do something or you can query it like you're talking to siri or alexa or disable my home security system this is a thing, whichever so the query goes up to your isps cloud and then it comes back down yeah it's pretty slick these things have a cc2530 chip in them and I suspect they're running remote ti which is the reference design, you guys should look into it alright so getting into the rf the protocol they use to communicate over rf is called rf4ce radio for consumer electronics it's a zigby standard based on 802.15.4 and it defines the way pairs of devices communicate with one another one of the devices takes on the role of controller which is the remote the other takes on the role of target in our case the set top box and it defines how commands get sent from one device to another so the vast majority of rf4ce devices support encryption out of the box as you should but if you're a bad guy you can listen to the key exchange or just force a rekeem and then you can decrypt all of the traffic which is I hear that's no bueno this code is going to be online in a day or a week or whenever it is allowed to be online so built on top of rf4ce is another standard called open cable and this defines exactly how the remote sends key presses to the set top box it also defines the way that you conduct the binding process so as an end user you press set up mash the xfinity button a couple times and then a pin appears on your television you enter it on your remote and then your dandy and your paired and that's great and generally you have five to ten tries before you have to actually re-initiate the binding process and we discovered that this binding process wasn't rate limited ok so if you had really really fast hands or a way of instrumenting this whole thing yeah that'd be great so that's what we did the chip you see on the right is a teensy arduino hooked up over spy to an adf7242p mod I love this chip out of the box it supports bluetooth BLE 802 15.4 unmanaged and managed in arbitrary gfsk if that's something that you all get excited about please read the white paper it's pretty cool so we implemented enough of the rf4ce stack and the open cable stack to go through this binding process and in practice it takes less than a second to do it and we can force pair our device to a set top box in under two hours and after you force pair a device you can pull up the diagnostics menu and enable remote web inspector and enable the set top box okay so bringing the shelled set top box back into the mix as I said rdk has fantastic logging so we were just gripping around the logs for anything having to do with rf4ce right and it turns out we were very easily able to discover the update daemon for the rf4ce remote it would be really cool if we could push an over the air update to this remote and make a remote listening device that'd be pretty cool right totally didn't do that yeah we haven't gone that far yet you guys should do it but we did prove that you could push an OTA to the remote and the reason you can do this is because there's no crypto involved meaning the firmware payload isn't signed it's just protected by CRC modifications to the update binary the configuration it read and then we made modifications to the firmware payload so we could verify that the over the air update was in fact good then we changed the CRC of the firmware package and pushed the OTA and if you look up on the screen the reported firmware version is generally 1010 I think and we are the only ones with remote with firmware version 1337 so now we'll take a look at the specific devices that we've looked at as well as the disclosure process and the remediation action is taken by the effective vendors so here we have a list of devices we found vulnerabilities in I want to highlight the Technicolor Time Warner device there we have no code execution on this device this was a vulnerability where we had we guessable default Wi-Fi credentials we have two Cisco modems with code execution a Technicolor and Eris modem with code execution and then the voice remote with the over the air firmware update that we can push and in an effort to be diligent we've looked at a lot of devices from various ISPs to see if we can reproduce these vulnerabilities so we looked at devices from Spectrum, MediaCom, Time Warner, Virgin Media, Unity Media, Cox and one Xunity device which had not run RDK this is not to say that these devices have no vulnerabilities in fact we do have other vulnerabilities in disclosure that we can't speak about yet but we found a lot of devices that run RDK we found these vulnerabilities over the course of multiple months and so we disclosed them to the affected vendors in four groups we had the first two groups in March, the second two groups in April the first public knowledge of this project was on July 11th and there was a really unfortunate mishap with the hosting provider that Defcon used for the Defcon website which was preventing customers from Comcast and some other ISPs from hitting the website when our abstract was released just in unfortunate mishap and then we publicly disclosed these vulnerabilities today but that all of the unauthenticated RCE attack trains affecting the Comcast devices have been remediated customers of other ISPs are invited to contact their ISP to find out if their devices run RDK if they're vulnerable and if they've been patched and as I said before we haven't had enough time to go in detail on all the vulnerabilities because we found too many CVEs which is a good problem to have so we invite you to go to our link to the white paper as you see there to be up on GitHub so we have pretty proposed technical detail on the white paper and we found a lot of very critical vulnerabilities but all of the worst attack trains have been patched I want to thank you guys for watching our talk I want to thank Bastille for supporting our research I want to thank Comcast for remediating the first time I heard about Defcon was when I was 13 years old and I always wanted to be a part of this and I've been spending for four years we finally got in, it means the world for you guys to be here yeah