>>Kay well I wanna welcome you guys to the official LineCon after party. We are excited you guys are here. [cheering] We’re really excited to share our research with you. My name is Marc Newlin, and I work as a wireless security researcher at Bastille networks. You may have seen some of my work last year. I did a couple projects called MouseJack and Key Sniffer which are vulnerabilities that I found in wireless plastic keyboards which I presented here at Def Con. Two other projects I have 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 shredded documents. And I wrote some cool software for that and finished that competition in third place out of the nine thousand 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 of the university teams and finished the first tournament of that competition in second place.
>>Hey what’s going on everybody? My name is Christopher Grayson.. Um.. My handle is lavalamp. I’m originally from Atlanta. I went to Georgia Tech twice. I-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. Uh, and most recently I’m the founder and principal engineer of a software security platform entitled Web Site, uh, which I open sourced all the software for a few days ago at Arsens so if you’d like a tax service enumeration you should totally check it out. 
>> Hey everyone, I’m Logan Lamb. I got my professional start at Oak Ridge National Lab where I focussed primarily on static and symbolic analysis and binaries. From there I went to Bastille Networks where I’m currently at doing wireless work with software defined radio. Some previous work ya’ll 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 sixteen million dollar settlement from ADT, so that’s something. More recently I found some vulnerabilities affecting the, uh, elections system in the state of Georgia and that’s culminated an ongoing lawsuit to contest the results of the most recent special election. 
>>So the scope of this talk is twenty-six vulnerabilities we have discovered in ISP provided wireless gateways, set top boxes, and voice remotes. Found vulnerabilities in hardware from Cisco, Aris, 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 wifi 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 wifi vulnerabilities fairly frequently, but the scope of this in unlike anything that’s been done fairly recently. We have some vulnerabilities that are specific to services provided by certain ISPs. We have some vulnerabilities that are specific to certain hardware venders. And the majority of the vulnerabilities that we’ve found are in the open source software stack called RDK which runs on many of the devices we looked at. I wanna 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 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 where we got our humble beginnings to where we are now. Then going to get into the meat of the talk which is the vulnerabilities we found. I wanna point out that we found too many vulnerabilities to cover in depth in forty-five minutes, but we do have a thirty-five page wipe paper that is up on Github right now that we recommend you read if you want more details.. Then going to discuss the specific devices we looked at as well as the disclosure process in remediation actions taken by the affected vendors. And then hopefully we’ll have a few minutes for Q and A.
>>Cool so we’re gonna start off with a little bit of a background on RDK. So, y’know we start looking at these modems and these set top boxes. We gain a shell. We get access to the file system. We start looking around. And we keep seeing references to this acronym RDK and we don’t really know what it is, uh, but doing a little bit more digging it’s, uh, the Reference Development Kit and basically what this is is an open source software stack, uh, that is designed to be placed on consumer premise equipment, uh, that deals with media so we’re talking about cable modems, we’re talking about set top boxes, we’re talking ab-erm we’re talking about basically anything that goes in a home that has to do with media, uh and so we see this and we’re like, oh, cool we really like open source software. It’s pretty cool that open source software is being deployed on these devices, uh, that’s fantastic. And, uh, so the-the RDK, uh, code base actually was founded in 2012. And then we do a little bit more digging. And so this really like open source question mark software. Uh, so before we realized that it was open source, uh, we thought that we stumbled upon-upon like a treasure trove of data that we weren’t supposed to be able to have access to, uh, 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, games that-that uh reside on these devices. Uh,but then we’re like, oh it’s actually open source. Okay, well this isn’t such a great find anyways. Uhm, so you can right now go to code.RDKcentral.com and pull down all of this software, uh, if you wanna take a look. And so we’re really, y’know, feeling pretty jazzed about this, like this is 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, uh, being raised. Like if you can see what’s over here on the screen, uh, the technical name for the, uh, “who is” record for RDKcentral.com is Comcast Domains. So, this is where things start getting a little bit hairier because, uh, you can go to this website, you can pull down these repos, uh, and you can do get log and grab for the word vulnerability and, uh, you will get pages and pages of vulns that have been patched in this software. And that’s not necessarily a bad thing, y’know, we definitely want these vulns to be patched and we definitely want the software that we used to 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 six to twelve to eighteen months before these patches that are in these publicly available repositories are actually pushed to consumer premise equipment. Uh, 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, these are vulnerabilities that are present in these code bases. And so the thing that, uh, really kind of made our eyebrows raised the most was that as far as we could tell, uh, y’know. These are known vulnerabilities. They’re being patched. Uh, none of the customers that these effect are being informed. And there are no CBEs being filed for either. 
>>Alright ya’ll so I’m gonna 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. Uh, a gateway in the most literal sense is a combination modem and wifi access point. So, why do [inaudible off mic aside] why do ISPs choose RDK? Well they choose RDK because it gets them about ninety percent of the way to a completed software stack. And 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. Uh, in the media framework you have closed-captioning, video on demand, pay per view, i-it handles the transponding of audio and video to your television and it does DRM. Uh, 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. Uh, we haven’t actually taken one of these apart yet. This is a picture from the FCC documentation, uh, we didn’t need to take it apart. Uhm, once you get a shell on one of these devices, uh, it really just looks like any other embedded linux device. It’s really architecturally not that interesting. I-It’s just remained a lot of RDK based software. Uh, there should be a lot of future work here. There’s all sorts of IO and we have TR zero six nine and mocha over coax. You guys should look at that. Uh, 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 and that’s pretty cool, right? It makes development a lot easier. What could possibly go wrong? 
>>What-what could possibly go wrong. [laughter] 
>>And, uh, y-you can plug in a keyboard and a mouse and interact with your set top box and that’s cool. And at least it's [inaudible] a later on.
Alright, so now we come to gateways. RDK broadband. Uh, in the most literal sense it’s a combination modem and router in one enclosure, mkay? Uh, in RDK-B Parlance we have a network processor and application processor. So, we’ve cracked apart at least half a dozen makes and models of these devices. And they all are nearly exactly the same both, uh, internally and externally. You have two distinct systems on a single board. Running two different operating systems, mkay. Uh, they normally run embedded Linux, but every once in awhile we’ll see one running ECos which is a real time operating system on the network processor. Uh, and these two devices communicate over a switch in ways that are defined by RDK broadband. Uh, 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. [crying] [laughter]
>>I don’t know about that.
>>Well, we’ll find out right?
>>We’ll see.8
And, um, 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 AP core.
>> So after I finished research on the Mousejack and Key Sniffer 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. At this point I was still kind of naively assuming that these mature devices from big industry players were going to be well locked down and free of vulnerabilities. And we’ll see this is not the case but this was my assumption at the time. So last year I made my way to Hack-in-the-Box in Amsterdam and I saw a talk by Peter Giesler and Peter had demonstrated that he could reverse engineer the algorithm they used to generate the default SS ID and passphrase on the wireless gateway provided by his ISP. And this was kind of a lightbulb 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 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 of the same ISP. I 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 pentesting so he know about things like application security and network security and so that first night he taught me what netcat was. He taught me how to use ed map and we were able to leverage a previously disclosed vulnerability in the wireless gateway I used to pull off the file system. We also were able to start digging into the RDK repositories and 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 Bastille 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 learned from these wireless gateways to start getting root shells in set top boxes. And because we were finding these vulnerabilities over the course of several months, we disclosed the vulnerabilities to the affected vendors in four groups. So now let’s get into the really fun part of the talk which is these vulnerabilities. 
[chuckling] And that’s my cat Tim by the way. 
So, I y’know, because my initial interest in this was sparked by Peter Giesler’s talk, I was hoping to figure out the default wifi SS ID and passphrase regenerated by my wireless gateway and I never figured 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 configurations 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 SS ID of XHS hyphen and then eight hex characters representing the lower four bytes of the CM Mac on my wireless gateway. And the CM Mac is not normally known and is a unique identifier for the device used for provisioning and other things. And the passphrase for this hidden wifi network was sixteen hex characters and this just felt like it was gonna be generated dynamically. So I started groping around for words like calculate and generate in XHS and key and DSK. And pretty soon I found this method called calculate DSK key in a shared library.
>> What could that function possibly do?
>>Exactly!
>>Yeah.
>>So this shared library turns out has extremely verbose debug output via print depth statements so I was able to run just strings on this shared library and trace the full of execution through this method. And it appeared that it was consuming the Mac address and spitting out a wifi passphrase. So, I fumbled 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 CM Mac and produced a passphrase for this hidden wifi network. And so, what is this wifi network used for? There’s 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 this home security service so this network was enabled even though I did not have this service. So now we have a hidden wifi network on my wireless gateway. We know that if we-if we we can this CM Mac we can  generate the credentials for this wifi network. And once we’re on this network we found multiple network surfaces which we could exploit for root command execution. So now the question is how do we get the CM Mac to generate the credentials for this hidden wifi network? So it turns out that a lot of these devices have a public wifi hotspot and in this case Xfinity wifi and if you’re a customer of this ISP you can connect with 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 app actually contains the CM Mac. So you connect to this public wifi hotspot in the DHCP app, you get the CM Mac and then generate the credentials to the hidden wifi network, connect to that and get root on the box. 
[laughter]
>>Good good.
>>And so it turns out there’s also a IPP six 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 L2SD0.500 network interface. The Mac address of this network interface has a deterministic offset from the CM Mac. 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 CM Mac, 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 is 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 reaching code and you can determina-determin-uh-deterministically translate this Mac address into the CM Mac. So this means that you can get your reverse DMS database, pull down the list of all the possible VOIP Mac addresses in your region, turn those into CM Macs. The full list of all the hidden SS IDs and passphrases in your region. And as I was thinking about these, uh, Mac addresses and IP addresses, I noticed that the IPv6 address of the WAN zero interface devices was generated from the CM Mac. And the WAN zero interface, in this case, is facing the Comcast infrastructure. And so if you know anything about IPv6 it's a sixty-four bit address, which is a pretty large search base but if you generate it from a known thirty-two bit address it's much easier to find. So we were trying to figure out, y’know, why might they be generating IPv6 addresses from the CM Macs. And so turns out that on these devices you have the Web UI that you get from the LAN but if you hid 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 login by 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 this service called Xfinity send to TV and this is pretty cool. So you can go to Xfinity dot com slash send to TV. You put a URL, you hit go, login with your ISP credentials and then on your TV by your set top box you can view this website. So we thought, what happens if we put in the IPv6 address of a wireless gateway. Well, [laughter] it turns out that it will actually load up the Web UI and you look like you’re actually coming from the ISP infrastructure and then you can log into 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 it was actually a binary which resides on the wireless gateway which generates this by a cronjaw that actually fires at 12:05am. So we thought what if we just fire this ourselves and spook the date? So we can actually generate all the future passwords of the day for these devices. [clapping] [inaudible in background]
>>Alright so, uh, we’re gonna do, we’re gonna show you a quick video of what that actually looks like. Uhh, and so what you’re gonna see in this video is using this send to tv service you’re gonna see that we’re gaining access to another modem, um, via that process. And then at the end of the video you’ll see what happened once the actual path was applied and see that instead of actually gaining access to that modem it just hangs. 
>>It's a really great service
>>So now we’re putting in the IPv6 address of the wireless gateway from a different customer account than the set top box we’re using.
>>So this is on 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 gateway’s Web UI 
[clapping]
>>And here’s the video of it not working.
>>And so now that it’s been patched this is no longer possible.
>>Yeah.
>>And so I’ve been spending a lot of time thinking about the wireless devices and wireless networks on these wireless gateways. And so I decided to take a look at these public wifi hotspots. And the way this works if you’re a customer you can connect to any one of these wifi 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 wifi hotspots around the country. The next time you sign in or connect to one of these you do not have to provide your credentials. And what’s happening is that your device has remembered based on the Mac address of your wifi network interface. So, an attacker can simply observe all of the authenticated and connected devices on these public wifi hotspots. The attacker could then spoof the Mac address of a co- actual connected customer, use that Mac address to connect to a different wifi hotspot and get the internet access for free. Now what’s interesting is that free internet’s great, but any malicious activity performed by the attacker is then attributed to the customer they’re spoofing. 
>>Awesome. So, uh, 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. Uh so, I’m gonna talk about three 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 gonna talk about is fast CGI. And so fast CGI is successor to CGI which is the Common Gateway Interface protocol and what, uh, CGI is is basically a way for a web server to be able to invoke processes dynamically so, uh, y’know back in the day we were only serving up static content from web servers and this is what enabled web servers to, uh, y’know invoke a PHP interpreter, invoke, y’know what have you based on a web request so it’s kind of the birth of the dynamic web. Um, so CGI was the initial protocol. FastCGI, uh, was a, y’know, improvement upon it. It had a bunch of obvious, uh, speed up games, uh, and one of the other things that, uh, [chuckle] it-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? Uh, so uh the interesting thing about this is there’s actually no RFC. For fast CGI. And its relied upon by a bunch of web servers you’ve probably never heard of like Apache and Engine-x and like Sun Web Server and like, really everything uses fastCGI. Uh, but there’s still no RFC. Uh, if anybody can find an RFC please let us know. Uh, the only documentation that we could find was actually the white paper, uh, from the MIT student that drafted this protocol back in 1996. So something that’s basically relied upon. Like, most recent documentation we have is twenty-one years old. Uh, there’s three modes of operation that the fastCGI servers can operate in. Uh, one of which is responder. And so responder is I’m gonna talk to you via this fastCGI protocol. I’m gonna give you a bunch of information about an http request. And then I’m gonna specify a file path on a local disk. And that’s the file that I want you to pass through the interpreter. Uh, the authorizer mode of operation is, uh, I’m gonna give you all the information about the http request via the fastCGI protocol. Uh, and then instead of giving me back any content you’re just gonna tell me “yes this request is authorized” or “no this request is not authorized.” The third mode of operation which I have yet to find implemented which is very disappointing, uh, is called filter. And filter is the exact same as responder, where you’re gonna 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, uh, let’s talk about the PHP fastCGI process manager. PHPFPM. Uh, this is a way to get PHP deployed on embedded devices very easily. Y’know, you can y’know it’s not just embedded devices. Its any device but it's very heavily relied upon by embedded devices. Uh, and its fastCGI coupled with PHP. Um, and it gives you some really cool additional functionality on top of fastCGI. Uh, 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.” Uh so and also, 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 the right direction. I promise. Uh, [laughter] so basically you talk fastCGI. You use the binary fastCGI protocol. You talk to it. Uh, you’re able to reconfigure the PHP. Uh, y’know, environment on every single request. You supply http post data via standard in, um and so if only there was a way you could use this to be a code execution. Uh, so turns out there is. Basically, uh, there’s a PHP configuration value that is, uh, 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, y’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. Um, 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 into the PHP interpreter. So how do we put this all together? Well in the fastCGI request we basically say “Hey. Uh, before you run anything else. Run that file first.” And the file description we give it is point to standard in. And then all the http post data that we’ve supplied is then used as code. Its past the PHP interpreter.
>>So some of you might be saying that this is old news. And, uh, to a-to an extent you’re right. Uh, CBE 2012 eighteen twenty-three described precisely this attack chain. Uh, where you’re abusing the PHP configuration, uh, to gain code execution. Uh, that is not this though. The difference between the two is that was actually piggy backing on top of an http request. So there's a way that you can abuse the query string to supply this data, gain code execution, but it was again based on top of an http request. This, we’re just talking straight to the damon. So the damon is bound on TCP where its ten twenty-six through ten twenty-nine on all interfaces on these RDK devices. Uh, so if you see it there you can probably talk to it. Uh, and, basically, uh, this - one of the reasons that this wasn’t, well we’d assume, one of the reasons that this hasn’t been found before is when you end map. End map does not recognize fastCGI. It just sees it as TCP wrap. Uh, so, we uh also recommend the Github repository that we’ve supplied alongside our talk. Because we’ve written and end map NFC script which will actually identify fastCGI, uh and you can do all sorts of fun things with that.  
So, one last note before I go onto the next one. Uh, in PHPFPM 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’d expect. You’d 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. Uh, but it was probably intentional because this was default functionality. But, lo and behold, we didn’t actually need it to gain code execution because you can actually just request files on disks. You can bypass the control flow, uh, that you would expect to see in the actual web app. And you can do some crazy stuff like that.
So let’s keep it going. Uh, I’m gonna talk about SYSEVENTD right now. You may have heard of SYSEVENTD before. This is, uh, This is what we were, this is us. Actually doing this research. Uh, so you may have heard of SYSEVENTD before. Uh it’s on PCP for 52367. The SYSEVENTD you may have heard of is not this. There’s oracle SYSEVENTD this is completely separate. This is a proprietary, uh, proprietary service built just for RDK. Uh, and the reason that it exists is that you can basically say that when this event happens on an operating system, do XYZ. Uh, so y’know it's the event based programming within an operating system for embedded devices. Uh, there’s no authentication, no authorization if you know how to talk the protocol. Fantastic. You can do whatever you want with it.
So, in order to abuse SYSEVENTD the first thing that you do. And also, by the way they really hand you with a binary that really knows how to speak this protocol in RDK, uh, so you don’t have to write any of your own stuff but the first step is you set up an event and the event you have two arguments to. You basically say here’s here’s the binary. I want there to 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, uh, you basically trigger the event name which is what you see up here in step two. And you pass it in argument. And when you do that what happens is the binary that you, uh, configured the event with in step one 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. Oh, what do you do with this? Well typically this is what we would we would assume this is being used for. Like oh let's say there's like a log file that’s like placed on disk and as soon as that log file is placed on disk it's like oh we don't want to copy that to a separate directory, uh, so that’s what you see up here. Like maybe when this XNL file hits the disk it's actually going to be copied into another location and be exfiltrated somewhere else. But what we want it to do is gain, y’know, arbitrary code execution. So if you create an event with a binary of Vin-bash and an event named dash c then whatever you supplied to the event is just passed as um as arguments to been dash. Code execution has root. Fantastic. 
So where’s this app? Uh, it's bound to all interfaces across the entire IPv4 address space. We found 149 thousand instances of it. Uh, we don’t really know why these weren’t firewalled at all. But the majority of them were. Uh, but basically if you gain access to any of these LANs you’ll probably see other SYSEVENTD or fastCGI. 
And the last thing that I’m gonna 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. Uh, one of them, uh, is what you would expect to see when you open up your browser. You go to configure your modem. That’s a ten dot dot dot dot one. That’s on arm side. Uh, and then there’s a system on a chip that kind of handles all of the networking stuff, uh, that is an adam, uh, adam instance. And this is usually at the top of the DCP range that you’re getting leases into right underneath the broadcast address. So the Adam instances, uh, are gonna be at ten dot dot dot dot dot two five four in most cases. And this, to this day, I don't know why this works. Uh, so so you know, we have a lot of really complementary skillsets up here and uh so I come over to Marc’s place one day and he shows me, you know, he’s teaching himself how to do this networking stuff. He’s like “hey I did this” and I said “that's not supposed to work.” Like that’s not a thing. That’s not supposed to happen. So, uh, the adam side has an interface that has an IP address in the one six nine two five four range which is not generally supposed supposed to be used it's not supposed to be routable. Uh, so it turns out that you can add a routing rule to your device that says hey when i'm trying to talk to one six nine two five four oh one, ten dot dot dot dot dot two five four is my gateway. And then you can talk to the private interface on the outside. And just forge traffic. I don’t know if that’s supposed to happen. I really think it's not. Uh, but this is pretty fantastic. I was like “Marc, what the h**l, what, oh my God.” Uh and so once you actually have access to this you see the results of the endmap output out here, you see ports twn twenty-six through ten twenty-nine open. Those are the fastCGI servers that we were talking about before. Again you have code execution. Fantastic.
>>Alright ya’ll so I’m gonna walk you through our suite of vulnerabilities affecting set top boxes and voice remotes. So the first three affect set top boxes. Then I’m gonna have a hard transition to some wireless work. Then I’m gonna bring the rooted set top box back into the mix. 
Alright, so, for those of you who don’t know, Marc Newlin is really good at slapping keys. Okay [laughter] He’s really good at it. Especially so in context of set top boxes. He plugged a keyboard into a 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. A remote web inspector enabled. 
>>That’s- that was surprising. Also, he was bashing a bunch of stuff and like the screen split in two and it-it-it was pretty, uh,
>>It was pretty whack. But his is in fact real life. So, uh, remote web inspector. It's basically, like, firebug 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, y’know vulnerabilities in something that’s running this. And uh you can actually hit this from over the internet. So thats pretty cool, right. So, uh, there’s another key combination that you could hit and it would pull up a hidden diagnostic [inaudible] I’m totally that guy.
>>Somebody’s dying I’m sure
>>I’m totally that guy. [laughter]
>>Alright, so, uh, we could hit a key combination and pull up a hidden diagnostics menu. We, uh, just perused this diagnostics menu, looked at the traffic between the set top box and whatever services it was hitting. Uh, lo 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, kind. Uh, and so since this is RDK and it's so standardized we already a good idea of all of the interesting things we wanted to look at. [clanging] Woo! [chuckle]
Alright. So, uh the-uh for those of you who don't know. Uh, I’ve got a pro tent. It's generally best not to get random input from the internet and then execute it locally. 
>>It’s rude
>>I think you’re not supposed to do that. 
>>Naw I don’t think so.
>>Protent. Yeah so sanitize your inputs guys. I think it's not the nineties anymore. Uh, we found a route and we could just, uh, essentially post to this route, uh a parameter that was shell command and we could just shell the box. GG easy mode. 
Alright, hard transition. Now we’re getting to some wireless work. Uh, what you see up on the screen is an XR11 voice remote. And these are actually pretty cool. So, uh, the way they work. Once you pair it with your set top box they communicate over ROF instead of IR and so you can be super lazy and just point it anywhere you want. Uh, 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 um do something” or you can query it like you're talking to Siri or Lexa like “disable my home security system. Yeah, this is a thing. Whichever. So, uh, the the query goes up to your ISPs cloud and then it comes back down or it just executes locally.
Yeah its pretty slick. 
Um, these things have a CC twenty-five thirty chip in them and I suspect they’re running remote T I which is the reference design. You guys should look into it. Alright, so getting into the ROF. The protocol they use to communicate over ROF is called ROF 4CE. Radio For Consumer Electronics. It's a Zigbee standard based on eight oh two fifty dot four and it defines the way paired devices communicate with one another. Uh, one of the devices takes on the role of controller which is the, uh remote. Uh, the other takes on the role of target. In our case its set top box. And it finds how, uh, commands get sent from one device to another. So, the vast majority of ROF 4CE device is forced encryption out of the box. It-as it should. But, if you’re a bad guy you can listen to the key exchange which is done in the clear or just forge a re-keying and then you can decrypt all of the traffic which is, I hear that’s no bueno. Uh, this code is gonna be online in a day or a week or whenever it is allowed to be online.
So, built on top of ROF 4CEs is another standard called open cable. And this, uh defines exactly how the remote sends key presses to the set top box. It also defines the way that you, uh conduct the binding process. So as an end user you press setup, mash the Xfinity button a couple and then a pin appears on your television. You enter it on your remote and then you’re dandy and you’re paired and that’s great. And generally you have, uh, five to ten tries, 


uh before you have to actually reinitiate the binding process and we discovered that this binding process wasn’t rate limited. Mkay. So if you had really really fast hands or a way of instrumenting this whole thing, yeah, uh that-that’d be great. So that’s what we did. Uh, what you see- the chip you see on the right is teensy arduino hooked up over spy to the ADF7242P mod. I love this chip. Out of- out of the box it supports bluetooth, BLE, uh, eight oh two fifteen dot four, uh unmanaged and managed and 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, uh, the diagnostics menu and enable remote web inspector and shell the set top box. Okay. So bringing the shelled set top box back into the mix. Uh, as I said, RDK has fantastic logging. So we were just prepping-
>>So verbose
>>Its sooo verbose
>>So we were prepping around the logs for anything having to do with ROF4CE, right? And it turns out we were very easily able to discover the update daemon for the ROF4CE remote. We thought it would be really cool if we could potion over the air update to this remote and make a remote listening device. I mean, that would 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 um you can 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. So, all we had to do is make a few minor 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 change the CRC of the firmware package and push the OTA. And if you look up on the screen the reported firmware version is generally one zero one zero I think and we are the only ones with a remote with firmware version one three three seven. 
>>So now we’ll take a look at the, uh, specific devices we looked at as well as the disclosure process and remediation actions taken by the affected vendors. So here we have the list of devices we found vulnerabilities in, uh, I wanna highlight the Technicolor Time Warner device there. Uh, we have no code execution on this device. This was a vulnerability where we had, y’know, we guessed both default wifi credentials. We have two Cisco modems with code execution. A Technicolor and Arris modem with code execution. This Motorola set top box 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 look at devices from Spectrum, Mediacom, Time Warner, Virgin Media, Unitymedia, Cox, and one Xfinity device which did not run RDK. uh, 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, uh, y’know, we found a lot of devices that run RDK. But a lot of devices that do not run RDK. We found these vulnerabilities over the course of multiple months and so we disclose 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 accessing the website. When our app jack was released this unfortunate mishap and then we publically disclosed these vulnerabilities today. I wanna point out that all of the unauthenticated RCE attack chains 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’ve said before we haven’t had enough time to go in detail on all the vulnerabilities because we’ve found too many CBEs which is, uh, a good problem to have. So we invite you to go to our link to the white paper as you see there. To, uh, you up on Github
>>That’s not the link by the way. 
>> [laughter] So we have a pretty verbose technical detail on the white paper. And we found a lot of, y’know, very critical vulnerabilities but all of the worst attack chains have been patched. I wanna thank you guys for watching our talk. I want to thank Bastille for supporting our research. I wanna thank Comcast for remediating these attack chains. [applause]
>>You know what. I’m gonna say this real quick. Uh the first time I heard about Defcon was when I was thirteen years old and I always wanted to be a part of this, uh, and I’ve been submitting for four years and I finally got in. It means the world for you guys to be here. [applause] [cheering]