00:00:00.000-->00:00:04.471 >>Kay well I wanna welcome you guys to the official LineCon after party. We are excited you 00:00:04.471-->00:00:08.642 guys are here. [cheering] We're really excited to share our research with you. My name is 00:00:08.642-->00:00:12.813 Marc Newlin, and I work as a wireless security researcher at Bastille networks. You may have 00:00:12.813-->00:00:16.717 seen some of my work last year. I did a couple projects called MouseJack and Key Sniffer which 00:00:16.717-->00:00:20.420 are vulnerabilities that I found in wireless plastic keyboards which I presented here at Def 00:00:20.420-->00:00:23.323 Con. Two other projects I have worked on that are kind of interesting are these two DARPA 00:00:23.323-->00:00:28.495 challenges. I competed in the DARPA Shredder Challenge in 2011 which was a competition to 00:00:28.495-->00:00:31.932 reassemble shredded documents. And I wrote some cool software for that and finished that 00:00:31.932-->00:00:35.736 competition in third place out of the nine thousand teams. Then I went on to do the DARPA 00:00:35.736-->00:00:39.740 Spectrum Challenge which is how I got into software defined radio and despite not going to 00:00:39.740-->00:00:44.044 college myself I managed to best some of the university teams and finished the first tournament of 00:00:44.044-->00:00:49.583 that competition in second place. >>Hey what's going on everybody? My name is 00:00:49.583-->00:00:54.354 Christopher Grayson.. Um.. My handle is lavalamp. I'm originally from Atlanta. I went 00:00:54.354-->00:00:59.126 to Georgia Tech twice. I-I've been a research scientist with DARPA working on the DARPA 00:00:59.126-->00:01:03.931 Center Program. I used to be the head of the Georgia Tech hacking club. I've also been a security 00:01:03.931-->00:01:08.969 consultant with the boutique security consultancy Bishop Fox. Uh, and most recently I'm the 00:01:08.969-->00:01:13.840 founder and principal engineer of a software security platform entitled Web Site, uh, which I 00:01:13.840-->00:01:17.177 open sourced all the software for a few days ago at Arsens so if you'd like a tax service 00:01:17.177-->00:01:23.550 enumeration you should totally check it out. >> Hey everyone, I'm Logan Lamb. I got my 00:01:23.550-->00:01:28.188 professional start at Oak Ridge National Lab where I focussed primarily on static and symbolic 00:01:28.188-->00:01:32.859 analysis and binaries. From there I went to Bastille Networks where I'm currently at 00:01:32.859-->00:01:37.731 doing wireless work with software defined radio. Some previous work ya'll may be 00:01:37.731-->00:01:42.769 familiar with, in 2014 I found some vulnerabilities affecting home security systems. And I was 00:01:42.769-->00:01:46.139 actually supposed to be up on one of these stages back then but it didn't quite work out. 00:01:46.139-->00:01:52.779 However, It did lead to a lawsuit and a sixteen million dollar settlement from ADT, so 00:01:52.779-->00:01:57.617 that's something. More recently I found some vulnerabilities affecting the, uh, elections 00:01:57.617-->00:02:02.789 system in the state of Georgia and that's culminated an ongoing lawsuit to contest the results 00:02:02.789-->00:02:08.462 of the most recent special election. >>So the scope of this talk is twenty-six 00:02:08.462-->00:02:13.133 vulnerabilities we have discovered in ISP provided wireless gateways, set top 00:02:13.133-->00:02:18.038 boxes, and voice remotes. Found vulnerabilities in hardware from Cisco, Aris, Technicolor, 00:02:18.038-->00:02:23.176 Motorola, and Xfinity. We have multiple unauthenticated remote code execution attack chains. 00:02:23.176-->00:02:26.913 And we have a variety of both network and application vulnerabilities, some wifi 00:02:26.913-->00:02:31.251 vulnerabilities, and then some ZigBee RF4CE vulnerabilities. And you might be asking 00:02:31.251-->00:02:35.822 yourself, you know, why does this matter? We see cable modem vulnerabilities and wifi 00:02:35.822-->00:02:38.392 vulnerabilities fairly frequently, but the scope of this in unlike anything that's 00:02:38.392-->00:02:42.329 been done fairly recently. We have some vulnerabilities that are specific to services 00:02:42.329-->00:02:46.466 provided by certain ISPs. We have some vulnerabilities that are specific to certain hardware 00:02:46.466-->00:02:50.137 venders. And the majority of the vulnerabilities that we've found are in the open source software 00:02:50.137-->00:02:54.608 stack called RDK which runs on many of the devices we looked at. I wanna point out that the 00:02:54.608-->00:02:58.545 attack chains affecting the comcast Xfinity devices have been remediated as of today. 00:02:58.545-->00:03:03.450 We're going to start with some background on the RDK software stack then going to get into 00:03:03.450-->00:03:07.854 some of the type of devices that run RDK. We're going to tell you about where this project started 00:03:07.854-->00:03:11.558 and where we got our humble beginnings to where we are now. Then going to get into the meat 00:03:11.558-->00:03:14.928 of the talk which is the vulnerabilities we found. I wanna point out that we found 00:03:14.928-->00:03:19.032 too many vulnerabilities to cover in depth in forty-five minutes, but we do have a 00:03:19.032-->00:03:22.636 thirty-five page wipe paper that is up on Github right now that we recommend you read if you 00:03:22.636-->00:03:26.440 want more details.. Then going to discuss the specific devices we looked at as well as the 00:03:26.440-->00:03:30.077 disclosure process in remediation actions taken by the affected vendors. And then 00:03:30.077-->00:03:34.514 hopefully we'll have a few minutes for Q and A. >>Cool so we're gonna start off with a 00:03:34.514-->00:03:38.952 little bit of a background on RDK. So, y'know we start looking at these modems and these set 00:03:38.952-->00:03:43.123 top boxes. We gain a shell. We get access to the file system. We start looking around. And we 00:03:43.123-->00:03:47.494 keep seeing references to this acronym RDK and we don't really know what it is, uh, but doing a 00:03:47.494-->00:03:51.598 little bit more digging it's, uh, the Reference Development Kit and basically what this is 00:03:51.598-->00:03:56.069 is an open source software stack, uh, that is designed to be placed on consumer premise 00:03:56.069-->00:04:00.073 equipment, uh, that deals with media so we're talking about cable modems, we're talking 00:04:00.073-->00:04:05.045 about set top boxes, we're talking ab-erm we're talking about basically anything that 00:04:05.045-->00:04:10.817 goes in a home that has to do with media, uh and so we see this and we're like, oh, cool we 00:04:10.817-->00:04:14.287 really like open source software. It's pretty cool that open source software is being 00:04:14.287-->00:04:19.059 deployed on these devices, uh, that's fantastic. And, uh, so the-the RDK, uh, code base 00:04:19.059-->00:04:24.431 actually was founded in 2012. And then we do a little bit more digging. And so this really like 00:04:24.431-->00:04:29.302 open source question mark software. Uh, so before we realized that it was open 00:04:29.302-->00:04:33.440 source, uh, we thought that we stumbled upon-upon like a treasure trove of data that we 00:04:33.440-->00:04:37.544 weren't supposed to be able to have access to, uh, because we found all of the code. So, like 00:04:37.544-->00:04:39.679 we're talking about the different web applications. We're talking about the 00:04:39.679-->00:04:43.150 operating system, the various, like, games that-that uh reside on these devices. Uh,but then 00:04:43.150-->00:04:47.454 we're like, oh it's actually open source. Okay, well this isn't such a great find anyways. 00:04:47.454-->00:04:53.193 Uhm, so you can right now go to code.RDKcentral.com and pull down all of this software, uh, 00:04:53.193-->00:04:57.030 if you wanna take a look. And so we're really, y'know, feeling pretty jazzed about this, like 00:04:57.030-->00:05:00.267 this is pretty cool that all this open source software is being deployed and then we do a 00:05:00.267-->00:05:05.438 "who is" lookup on RDKcentral.com and that's when the eyebrows started, uh, being 00:05:05.438-->00:05:11.545 raised. Like if you can see what's over here on the screen, uh, the technical name for the, 00:05:11.545-->00:05:16.550 uh, "who is" record for RDKcentral.com is Comcast Domains. So, this is where 00:05:18.819-->00:05:23.790 things start getting a little bit hairier because, uh, you can go to this website, you can pull 00:05:23.790-->00:05:29.829 down these repos, uh, and you can do get log and grab for the word vulnerability and, uh, you 00:05:29.829-->00:05:35.335 will get pages and pages of vulns that have been patched in this software. And that's not 00:05:35.335-->00:05:41.074 necessarily a bad thing, y'know, we definitely want these vulns to be patched and we definitely 00:05:41.074-->00:05:44.244 want the software that we used to use to be secure, but where this gets a little bit kind of 00:05:44.244-->00:05:50.450 weird is these patches are not really being pushed to consumers in any rapid, kind of, process. 00:05:50.450-->00:05:55.555 So, we're looking at six to twelve to eighteen months before these patches that are in these 00:05:55.555-->00:06:00.493 publicly available repositories are actually pushed to consumer premise equipment. Uh, so what 00:06:00.493-->00:06:03.730 sort of vulnerabilities are we talking about? Well, it really runs the gamut. We're talking 00:06:03.730-->00:06:07.867 about remote code execution, cross site scripting, cross site request forgery, memory 00:06:07.867-->00:06:12.172 corruption. You name it they got it. And if you go to these repositories and look for these 00:06:12.172-->00:06:17.344 changes, like, these are, these are vulnerabilities that are present in these code bases. And 00:06:17.344-->00:06:22.549 so the thing that, uh, really kind of made our eyebrows raised the most was that as far as we 00:06:22.549-->00:06:27.587 could tell, uh, y'know. These are known vulnerabilities. They're being patched. Uh, none 00:06:27.587-->00:06:32.726 of the customers that these effect are being informed. And there are no CBEs being filed 00:06:32.726-->00:06:37.731 for either. >>Alright ya'll so I'm gonna give a quick overview of the devices that run RDK. 00:06:41.034-->00:06:46.072 Give you some reasons ISPs choose RDK and point out some salient tidbits that will be 00:06:46.072-->00:06:51.711 relevant later in the talk. So there are two major categories of devices that run RDK. The 00:06:51.711-->00:06:58.518 first is set top boxes which run RDK video. The second are gateways which run RDK 00:06:58.518-->00:07:04.624 broadband. Uh, a gateway in the most literal sense is a combination modem and wifi 00:07:04.624-->00:07:09.629 access point. So, why do [inaudible off mic aside] why do ISPs choose RDK? Well they 00:07:17.037-->00:07:22.142 choose RDK because it gets them about ninety percent of the way to a completed software stack. 00:07:22.142-->00:07:27.213 And it comes out of the box with fantastic remote management for when you need to manage tens of 00:07:27.213-->00:07:33.720 millions of devices. It has excellent diagnostics, very verbose logging. I hear they 00:07:33.720-->00:07:39.626 have a security subsystem. We haven't actually seen that yet, but I hear it's a thing. And 00:07:39.626-->00:07:46.533 they have a media framework which runs on RDK video. And it's pretty neat. Uh, in the 00:07:46.533-->00:07:51.204 media framework you have closed-captioning, video on demand, pay per view, i-it 00:07:51.204-->00:07:55.542 handles the transponding of audio and video to your television and it does DRM. Uh, 00:07:55.542-->00:08:00.480 all out of the box. Okay, so RDK video. This device that you're looking at right now. It's a 00:08:03.550-->00:08:10.190 Motorola XG1 set top box. This is the same one that we shelled working on it in Atlanta. Uh, we 00:08:10.190-->00:08:15.528 haven't actually taken one of these apart yet. This is a picture from the FCC 00:08:15.528-->00:08:20.767 documentation, uh, we didn't need to take it apart. Uhm, once you get a shell on one of these 00:08:20.767-->00:08:25.138 devices, uh, it really just looks like any other embedded linux device. It's really 00:08:25.138-->00:08:29.876 architecturally not that interesting. I-It's just remained a lot of RDK based 00:08:29.876-->00:08:34.881 software. Uh, there should be a lot of future work here. There's all sorts of IO and we have TR 00:08:38.418-->00:08:44.657 zero six nine and mocha over coax. You guys should look at that. Uh, things to remember for 00:08:44.657-->00:08:51.398 later. The way these devices work. Everything you see and hear on your television is 00:08:51.398-->00:08:56.870 actually being rendered inside of a webkit based browser engine. Meaning everything is 00:08:56.870-->00:09:01.808 happening inside of a browser on your set top box and that's pretty cool, right? It makes 00:09:01.808-->00:09:05.245 development a lot easier. What could possibly go wrong? >>What-what could possibly go 00:09:05.245-->00:09:10.116 wrong. [laughter] >>And, uh, y-you can plug in a keyboard and a mouse and interact with your 00:09:10.116-->00:09:15.121 set top box and that's cool. And at least it's [inaudible] a later on. Alright, so now we 00:09:17.390-->00:09:24.364 come to gateways. RDK broadband. Uh, in the most literal sense it's a combination modem and 00:09:24.364-->00:09:30.870 router in one enclosure, mkay? Uh, in RDK-B Parlance we have a network processor and 00:09:30.870-->00:09:35.875 application processor. So, we've cracked apart at least half a dozen makes and models of these 00:09:38.311-->00:09:44.784 devices. And they all are nearly exactly the same both, uh, internally and externally. You 00:09:44.784-->00:09:51.057 have two distinct systems on a single board. Running two different operating systems, 00:09:51.057-->00:09:56.129 mkay. Uh, they normally run embedded Linux, but every once in awhile we'll see one running 00:09:56.129-->00:10:01.668 ECos which is a real time operating system on the network processor. Uh, and these two 00:10:01.668-->00:10:06.673 devices communicate over a switch in ways that are defined by RDK broadband. Uh, things to 00:10:09.142-->00:10:13.980 remember for later in the talk. Just because you pop one of these devices doesn't 00:10:13.980-->00:10:19.819 necessarily mean you fully own the entire box. [crying] [laughter] >>I don't know about 00:10:19.819-->00:10:26.392 that. >>Well, we'll find out right? >>We'll see.8 And, um, Puma is intel's take on RDK 00:10:26.392-->00:10:31.397 broadband hardware architecture. And for Intel Puma, the network processor is an ARM core and the 00:10:34.701-->00:10:39.405 application processor is an AP core. >> So after I finished research on the Mousejack and 00:10:39.405-->00:10:43.142 Key Sniffer projects, I knew I wanted to do more vulnerability research, but I didn't have a 00:10:43.142-->00:10:47.147 good concept of what devices would be fun to look at. At this point I was still kind of 00:10:47.147-->00:10:51.251 naively assuming that these mature devices from big industry players were going to be well 00:10:51.251-->00:10:55.054 locked down and free of vulnerabilities. And we'll see this is not the case but this 00:10:55.054-->00:10:59.492 was my assumption at the time. So last year I made my way to Hack-in-the-Box in Amsterdam and 00:10:59.492-->00:11:03.663 I saw a talk by Peter Giesler and Peter had demonstrated that he could reverse engineer the 00:11:03.663-->00:11:08.134 algorithm they used to generate the default SS ID and passphrase on the wireless gateway provided 00:11:08.134-->00:11:12.138 by his ISP. And this was kind of a lightbulb moment when I realized that people were still 00:11:12.138-->00:11:16.142 finding interesting wireless vulnerabilities in this ISP provided equipment. So I decided 00:11:16.142-->00:11:19.579 I would go home and do the same with my ISP gear at home. And unfortunately I had a pretty 00:11:19.579-->00:11:23.616 busy year last year so it wasn't until December when I had time to look at this. And so I 00:11:23.616-->00:11:27.153 started to look at this project and about a week later I was dropping my keys off at Chris's 00:11:27.153-->00:11:30.456 house because he was kind enough to watch my cats when my fiance and I were up in Seattle for 00:11:30.456-->00:11:35.195 Christmas. And it turned out that Chris was a prior customer of the same ISP. I also looked 00:11:35.195-->00:11:38.231 at his wireless gateway once upon a time and we both had an interest in this type of 00:11:38.231-->00:11:42.602 research. So we decided to team up and see what we could find. And the nice thing about Chris 00:11:42.602-->00:11:46.973 is that he has a background in pentesting so he know about things like application security 00:11:46.973-->00:11:50.910 and network security and so that first night he taught me what netcat was. He taught me how to 00:11:50.910-->00:11:56.015 use ed map and we were able to leverage a previously disclosed vulnerability in the wireless 00:11:56.015-->00:12:00.086 gateway I used to pull off the file system. We also were able to start digging into the RDK 00:12:00.086-->00:12:04.090 repositories and just get a general idea of how these devices operated. And pretty 00:12:04.090-->00:12:07.727 soon we had some novel vulnerabilities and soon after that we had some novel wireless 00:12:07.727-->00:12:11.164 vulnerabilities. And at this point we brought the project to my employer Bastille which is a 00:12:11.164-->00:12:14.867 wireless security company and we disclosed everything through my work. After some more 00:12:14.867-->00:12:18.204 vulnerabilities and some more work on this Chris and I had an impasse where we needed some 00:12:18.204-->00:12:21.541 hardware expertise. So we brought Logan into the fold to leverage his hardware and 00:12:21.541-->00:12:25.278 embedded expertise. And then we were able, between the three of us, to find all kinds of 00:12:25.278-->00:12:28.448 vulnerabilities in these wireless gateways and then leverage what we learned from 00:12:28.448-->00:12:32.685 these wireless gateways to start getting root shells in set top boxes. And because we were 00:12:32.685-->00:12:35.588 finding these vulnerabilities over the course of several months, we disclosed the 00:12:35.588-->00:12:39.926 vulnerabilities to the affected vendors in four groups. So now let's get into the really fun 00:12:39.926-->00:12:44.063 part of the talk which is these vulnerabilities. [chuckling] And that's my cat Tim by the way. 00:12:44.063-->00:12:49.469 So, I y'know, because my initial interest in this was sparked by Peter Giesler's talk, I was 00:12:49.469-->00:12:54.607 hoping to figure out the default wifi SS ID and passphrase regenerated by my wireless 00:12:54.607-->00:12:58.544 gateway and I never figured that out but my motivation was to really look at the different 00:12:58.544-->00:13:03.049 wireless things running on this box. And one of the first things Chris and I discovered is that 00:13:03.049-->00:13:06.552 there are multiple plain text configuration files which contain all kinds of hard coded 00:13:06.552-->00:13:11.658 credentials and dynamic credentials including all of the wifi configurations for the 00:13:11.658-->00:13:16.562 devices. And I saw what appeared to be a hidden wifi network that I was not previously aware of on 00:13:16.562-->00:13:22.035 my device. And it had an SS ID of XHS hyphen and then eight hex characters representing the 00:13:22.035-->00:13:27.407 lower four bytes of the CM Mac on my wireless gateway. And the CM Mac is not normally known and 00:13:27.407-->00:13:32.245 is a unique identifier for the device used for provisioning and other things. And the passphrase 00:13:32.245-->00:13:36.849 for this hidden wifi network was sixteen hex characters and this just felt like it was gonna be 00:13:36.849-->00:13:41.154 generated dynamically. So I started groping around for words like calculate and generate in 00:13:41.154-->00:13:47.260 XHS and key and DSK. And pretty soon I found this method called calculate DSK key in a shared 00:13:47.260-->00:13:52.131 library. >> What could that function possibly do? >>Exactly! >>Yeah. >>So this shared library 00:13:52.131-->00:13:56.769 turns out has extremely verbose debug output via print depth statements so I was able to run 00:13:56.769-->00:14:01.007 just strings on this shared library and trace the full of execution through this method. 00:14:01.007-->00:14:06.012 And it appeared that it was consuming the Mac address and spitting out a wifi passphrase. 00:14:06.012-->00:14:10.283 So, I fumbled around and got together a cross compilation tool chain and I compiled a 00:14:10.283-->00:14:14.620 binary which linked against a shared library, put it on the gateway, and ran it and it 00:14:14.620-->00:14:19.726 actually consumed the CM Mac and produced a passphrase for this hidden wifi network. And so, 00:14:19.726-->00:14:25.164 what is this wifi network used for? There's a hidden home security wifi network on these 00:14:25.164-->00:14:29.068 devices. So if you have this home security service provided by these ISPs you can get a 00:14:29.068-->00:14:32.171 wireless touch screen control panel which connects to the internet through your wireless 00:14:32.171-->00:14:35.007 gateway. And the way it connects to the wireless gateway is through this hidden home 00:14:35.007-->00:14:40.046 security wifi network. The thing is that I did not have this home security service so this network 00:14:40.046-->00:14:44.817 was enabled even though I did not have this service. So now we have a hidden wifi network on my 00:14:44.817-->00:14:49.856 wireless gateway. We know that if we-if we we can this CM Mac we can generate the credentials 00:14:49.856-->00:14:53.760 for this wifi network. And once we're on this network we found multiple network surfaces which 00:14:53.760-->00:14:57.430 we could exploit for root command execution. So now the question is how do we get the CM 00:14:57.430-->00:15:01.534 Mac to generate the credentials for this hidden wifi network? So it turns out that a lot of these 00:15:01.534-->00:15:05.972 devices have a public wifi hotspot and in this case Xfinity wifi and if you're a customer of 00:15:05.972-->00:15:10.343 this ISP you can connect with this wifi network on any one of these devices and access the 00:15:10.343-->00:15:13.613 internet. It's a pretty cool service. But it turns out that when you connect to this wifi 00:15:13.613-->00:15:19.152 network you get a DHCP lease and the DHCP app actually contains the CM Mac. So you connect to 00:15:19.152-->00:15:24.390 this public wifi hotspot in the DHCP app, you get the CM Mac and then generate the credentials to 00:15:24.390-->00:15:30.696 the hidden wifi network, connect to that and get root on the box. [laughter] >>Good good. >>And so 00:15:30.696-->00:15:36.435 it turns out there's also a IPP six multicast packet that's broadcast unencrypted every four 00:15:36.435-->00:15:40.807 seconds from these devices. And this packet, I'm not quite sure why this is transmitted, but it 00:15:40.807-->00:15:46.279 contains the Mac address of another network interface on the device. This is the L2SD0.500 00:15:46.279-->00:15:50.149 network interface. The Mac address of this network interface has a deterministic 00:15:50.149-->00:15:55.454 offset from the CM Mac. So you can listen to the wifi channel that the device is using for 00:15:55.454-->00:15:59.425 four seconds, retrieve this packet, convert that Mac address into the CM Mac, generate the 00:15:59.425-->00:16:05.464 credentials, and root the box. Then a lot of these devices also have VOIP service. The VOIP 00:16:05.464-->00:16:10.236 interface has a public IPv4 address. That public IPv4 address is a fully qualified 00:16:10.236-->00:16:14.473 domain name which contains the Mac address of the network interface used for this VOIP 00:16:14.473-->00:16:20.513 connection. Also in this FQDN is a reaching code and you can determina-determin-uh-determinis 00:16:20.513-->00:16:24.617 tically translate this Mac address into the CM Mac. So this means that you can get your 00:16:24.617-->00:16:29.655 reverse DMS database, pull down the list of all the possible VOIP Mac addresses in your 00:16:29.655-->00:16:34.627 region, turn those into CM Macs. The full list of all the hidden SS IDs and passphrases in your 00:16:34.627-->00:16:40.833 region. And as I was thinking about these, uh, Mac addresses and IP addresses, I noticed that 00:16:40.833-->00:16:45.838 the IPv6 address of the WAN zero interface devices was generated from the CM Mac. And the WAN 00:16:48.441-->00:16:52.478 zero interface, in this case, is facing the Comcast infrastructure. And so if you 00:16:52.478-->00:16:56.315 know anything about IPv6 it's a sixty-four bit address, which is a pretty large search base but 00:16:56.315-->00:17:00.486 if you generate it from a known thirty-two bit address it's much easier to find. So we were 00:17:00.486-->00:17:04.824 trying to figure out, y'know, why might they be generating IPv6 addresses from the CM Macs. 00:17:04.824-->00:17:09.161 And so turns out that on these devices you have the Web UI that you get from the LAN but if you 00:17:09.161-->00:17:15.301 hid the device from this ISP facing IPv6 address you can also log in to the Web UI with hard 00:17:15.301-->00:17:20.573 coded or daily generated credentials or login by SSH. And we weren't sure how exactly we 00:17:20.573-->00:17:25.678 could access this because we are, as a customer, not on the ISP network. So it turns out 00:17:25.678-->00:17:29.382 there's this service called Xfinity send to TV and this is pretty cool. So you can go to 00:17:29.382-->00:17:34.820 Xfinity dot com slash send to TV. You put a URL, you hit go, login with your ISP credentials 00:17:34.820-->00:17:39.458 and then on your TV by your set top box you can view this website. So we thought, what 00:17:39.458-->00:17:44.263 happens if we put in the IPv6 address of a wireless gateway. Well, [laughter] it turns out 00:17:44.263-->00:17:49.001 that it will actually load up the Web UI and you look like you're actually coming from the 00:17:49.001-->00:17:53.272 ISP infrastructure and then you can log into this with either hard coded credentials or daily 00:17:53.272-->00:17:57.310 generated credentials. So these daily generated credentials are called a password of the day. 00:17:57.310-->00:18:00.947 This is used by many ISPs we've only looked at the Comcast variant. In this case it was 00:18:00.947-->00:18:05.618 actually a binary which resides on the wireless gateway which generates this by a cronjaw that 00:18:05.618-->00:18:09.822 actually fires at 12:05am. So we thought what if we just fire this ourselves and spook the 00:18:09.822-->00:18:16.329 date? So we can actually generate all the future passwords of the day for these 00:18:16.329-->00:18:21.867 devices. [clapping] [inaudible in background] >>Alright so, uh, we're gonna do, we're gonna show 00:18:21.867-->00:18:26.872 you a quick video of what that actually looks like. Uhh, and so what you're gonna see in this 00:18:29.375-->00:18:35.281 video is using this send to tv service you're gonna see that we're gaining access to another 00:18:35.281-->00:18:39.251 modem, um, via that process. And then at the end of the video you'll see what happened once 00:18:39.251-->00:18:43.589 the actual path was applied and see that instead of actually gaining access to that modem it 00:18:43.589-->00:18:48.594 just hangs. >>It's a really great service >>So now we're putting in the IPv6 address of 00:18:53.799-->00:18:57.036 the wireless gateway from a different customer account than the set top box we're using. 00:19:10.816-->00:19:17.823 >>So this is on TV. We're watching some NASA stuff >>As you do. >>And all of a sudden we 00:19:17.823-->00:19:22.828 have this access. >>And this is hard coded credentials to log into another customer's wireless 00:19:25.464-->00:19:30.469 gateway's Web UI [clapping] >>And here's the video of it not working. >>And so now that it's 00:19:34.173-->00:19:39.178 been patched this is no longer possible. >>Yeah. >>And so I've been spending a lot of time 00:19:42.381-->00:19:46.685 thinking about the wireless devices and wireless networks on these wireless gateways. And so 00:19:46.685-->00:19:50.122 I decided to take a look at these public wifi hotspots. And the way this works if you're a 00:19:50.122-->00:19:54.593 customer you can connect to any one of these wifi hotspots. You sign in with your ISP username 00:19:54.593-->00:19:57.596 and password. And then you get to access the internet which is pretty great because then you 00:19:57.596-->00:20:02.601 have some tens of millions of free wifi hotspots around the country. The next time you sign 00:20:02.601-->00:20:06.072 in or connect to one of these you do not have to provide your credentials. And what's 00:20:06.072-->00:20:10.309 happening is that your device has remembered based on the Mac address of your wifi network 00:20:10.309-->00:20:15.081 interface. So, an attacker can simply observe all of the authenticated and connected 00:20:15.081-->00:20:20.019 devices on these public wifi hotspots. The attacker could then spoof the Mac address of a 00:20:20.019-->00:20:24.623 co- actual connected customer, use that Mac address to connect to a different wifi hotspot and 00:20:24.623-->00:20:28.327 get the internet access for free. Now what's interesting is that free internet's great, but 00:20:28.327-->00:20:32.231 any malicious activity performed by the attacker is then attributed to the customer 00:20:32.231-->00:20:37.236 they're spoofing. >>Awesome. So, uh, we've talked a lot about how you actually gain access to 00:20:40.106-->00:20:44.143 these devices, but what do you do once you're on these networks. Uh so, I'm gonna talk 00:20:44.143-->00:20:48.147 about three things that you can do. There's plenty more. We highly recommend that you look 00:20:48.147-->00:20:52.852 at our white paper. And the first thing that I'm gonna talk about is fast CGI. And so fast 00:20:52.852-->00:20:58.824 CGI is successor to CGI which is the Common Gateway Interface protocol and what, uh, CGI is is 00:20:58.824-->00:21:04.363 basically a way for a web server to be able to invoke processes dynamically so, uh, y'know back 00:21:04.363-->00:21:08.801 in the day we were only serving up static content from web servers and this is what enabled 00:21:08.801-->00:21:13.372 web servers to, uh, y'know invoke a PHP interpreter, invoke, y'know what have you 00:21:13.372-->00:21:18.177 based on a web request so it's kind of the birth of the dynamic web. Um, so CGI was the initial 00:21:18.177-->00:21:23.449 protocol. FastCGI, uh, was a, y'know, improvement upon it. It had a bunch of obvious, uh, 00:21:23.449-->00:21:27.586 speed up games, uh, and one of the other things that, uh, [chuckle] it-it implemented as 00:21:27.586-->00:21:32.858 well was not only could you now listen on unix domain sockets but you could also listen on TCP 00:21:32.858-->00:21:38.898 sockets. What could possibly go wrong? Uh, so uh the interesting thing about this is there's 00:21:38.898-->00:21:43.836 actually no RFC. For fast CGI. And its relied upon by a bunch of web servers you've probably 00:21:43.836-->00:21:48.841 never heard of like Apache and Engine-x and like Sun Web Server and like, really everything uses 00:21:48.841-->00:21:55.114 fastCGI. Uh, but there's still no RFC. Uh, if anybody can find an RFC please let us know. Uh, 00:21:55.114-->00:21:59.385 the only documentation that we could find was actually the white paper, uh, from the MIT 00:21:59.385-->00:22:03.122 student that drafted this protocol back in 1996. So something that's basically 00:22:03.122-->00:22:07.293 relied upon. Like, most recent documentation we have is twenty-one years old. Uh, 00:22:07.293-->00:22:11.997 there's three modes of operation that the fastCGI servers can operate in. Uh, one of which is 00:22:11.997-->00:22:17.102 responder. And so responder is I'm gonna talk to you via this fastCGI protocol. I'm gonna give 00:22:17.102-->00:22:21.140 you a bunch of information about an http request. And then I'm gonna specify a file path on a 00:22:21.140-->00:22:24.877 local disk. And that's the file that I want you to pass through the interpreter. Uh, the 00:22:24.877-->00:22:29.982 authorizer mode of operation is, uh, I'm gonna give you all the information about the http 00:22:29.982-->00:22:34.253 request via the fastCGI protocol. Uh, and then instead of giving me back any content 00:22:34.253-->00:22:37.656 you're just gonna tell me "yes this request is authorized" or "no this request is not 00:22:37.656-->00:22:42.328 authorized." The third mode of operation which I have yet to find implemented which is very 00:22:42.328-->00:22:47.066 disappointing, uh, is called filter. And filter is the exact same as responder, where you're 00:22:47.066-->00:22:50.269 gonna give it a bunch of information about an http request. But instead of 00:22:50.269-->00:22:55.474 specifying a local file path, you just give it the file to run. So, you can see why I would 00:22:55.474-->00:23:01.180 be disappointed that I haven't found that yet. So, uh, let's talk about the PHP fastCGI 00:23:01.180-->00:23:06.452 process manager. PHPFPM. Uh, this is a way to get PHP deployed on embedded devices 00:23:06.452-->00:23:09.888 very easily. Y'know, you can y'know it's not just embedded devices. Its any device but it's 00:23:09.888-->00:23:15.527 very heavily relied upon by embedded devices. Uh, and its fastCGI coupled with PHP. Um, 00:23:15.527-->00:23:21.767 and it gives you some really cool additional functionality on top of fastCGI. Uh, like you 00:23:21.767-->00:23:26.772 have the ability to reconfigure the PHP environment on every request. Huh. If anybody's used 00:23:28.974-->00:23:34.146 PHP before you might be like "oh that's bad." Uh so and also, by the way, if you're ever doing 00:23:34.146-->00:23:38.917 research and you Google a technology and the first result comes up with a big red box that 00:23:38.917-->00:23:42.254 says "hey by the way there's some security precautions you probably want to consider," 00:23:42.254-->00:23:45.858 you're going the right direction. I promise. Uh, [laughter] so basically you talk 00:23:45.858-->00:23:50.829 fastCGI. You use the binary fastCGI protocol. You talk to it. Uh, you're able to 00:23:50.829-->00:23:55.467 reconfigure the PHP. Uh, y'know, environment on every single request. You supply http post 00:23:55.467-->00:23:59.972 data via standard in, um and so if only there was a way you could use this to be a code 00:23:59.972-->00:24:04.977 execution. Uh, so turns out there is. Basically, uh, there's a PHP configuration value that 00:24:07.579-->00:24:13.852 is, uh, given a file path and that file path points to a file that is going to be run before 00:24:13.852-->00:24:17.956 the actual file you're requesting. So, y'know, maybe the idea behind this is you've 00:24:17.956-->00:24:21.060 got a big PHP application but you have a script that bootstraps your entire 00:24:21.060-->00:24:24.897 environment ahead of time so instead of actually including it or requiring it, you just 00:24:24.897-->00:24:30.135 reconfigure PHP to say "just run that file before anything else." So PHP also has some really 00:24:30.135-->00:24:36.975 interesting file scheme handlers. Um, one of which is PHP colon slash slash STDIN. And 00:24:36.975-->00:24:41.981 this is just a reference to standard in. We supply http post data via standard into the PHP 00:24:44.750-->00:24:49.988 interpreter. So how do we put this all together? Well in the fastCGI request we basically say 00:24:49.988-->00:24:54.360 "Hey. Uh, before you run anything else. Run that file first." And the file description 00:24:54.360-->00:24:59.298 we give it is point to standard in. And then all the http post data that we've supplied is then 00:24:59.298-->00:25:05.270 used as code. Its past the PHP interpreter. >>So some of you might be saying that this is old 00:25:05.270-->00:25:10.576 news. And, uh, to a-to an extent you're right. Uh, CBE 2012 eighteen twenty-three described 00:25:10.576-->00:25:15.981 precisely this attack chain. Uh, where you're abusing the PHP configuration, uh, to gain code 00:25:15.981-->00:25:19.885 execution. Uh, that is not this though. The difference between the two is that was actually 00:25:19.885-->00:25:23.989 piggy backing on top of an http request. So there's a way that you can abuse the query string 00:25:23.989-->00:25:28.827 to supply this data, gain code execution, but it was again based on top of an http request. 00:25:28.827-->00:25:33.332 This, we're just talking straight to the damon. So the damon is bound on TCP where its 00:25:33.332-->00:25:37.803 ten twenty-six through ten twenty-nine on all interfaces on these RDK devices. Uh, so if you 00:25:37.803-->00:25:42.808 see it there you can probably talk to it. Uh, and, basically, uh, this - one of the reasons 00:25:45.744-->00:25:49.415 that this wasn't, well we'd assume, one of the reasons that this hasn't been found before is 00:25:49.415-->00:25:55.554 when you end map. End map does not recognize fastCGI. It just sees it as TCP wrap. Uh, so, we 00:25:55.554-->00:25:59.658 uh also recommend the Github repository that we've supplied alongside our talk. Because 00:25:59.658-->00:26:03.729 we've written and end map NFC script which will actually identify fastCGI, uh and you can 00:26:03.729-->00:26:08.734 do all sorts of fun things with that. So, one last note before I go onto the next one. Uh, in 00:26:11.069-->00:26:17.476 PHPFPM as compiled on RDK. This functionality has been compiled out. You can't actually 00:26:17.476-->00:26:22.214 reconfigure PHP with every request. And we could not find any documentation for how you 00:26:22.214-->00:26:25.684 would do this. If this is something that's seen as, like oh yeah this is a security flaw, 00:26:25.684-->00:26:29.154 this is something that we'd expect. You'd also anticipate that there's documentation for 00:26:29.154-->00:26:33.559 "hey, here's how you compile this out." But as far as we could find, that did not exist. 00:26:33.559-->00:26:37.930 So for some reason this has been compiled out. We don't know why. Uh, but it was probably 00:26:37.930-->00:26:42.267 intentional because this was default functionality. But, lo and behold, we didn't actually 00:26:42.267-->00:26:45.504 need it to gain code execution because you can actually just request files on disks. You can 00:26:45.504-->00:26:49.508 bypass the control flow, uh, that you would expect to see in the actual web app. And you can 00:26:49.508-->00:26:54.513 do some crazy stuff like that. So let's keep it going. Uh, I'm gonna talk about SYSEVENTD right 00:26:54.513-->00:27:00.352 now. You may have heard of SYSEVENTD before. This is, uh, This is what we were, this is 00:27:00.352-->00:27:04.356 us. Actually doing this research. Uh, so you may have heard of SYSEVENTD before. Uh 00:27:04.356-->00:27:09.328 it's on PCP for 52367. The SYSEVENTD you may have heard of is not this. There's oracle 00:27:09.328-->00:27:13.999 SYSEVENTD this is completely separate. This is a proprietary, uh, proprietary service built 00:27:13.999-->00:27:18.003 just for RDK. Uh, and the reason that it exists is that you can basically say that when this 00:27:18.003-->00:27:23.842 event happens on an operating system, do XYZ. Uh, so y'know it's the event based programming 00:27:23.842-->00:27:28.213 within an operating system for embedded devices. Uh, there's no authentication, no authorization 00:27:28.213-->00:27:31.550 if you know how to talk the protocol. Fantastic. You can do whatever you want with it. So, 00:27:31.550-->00:27:36.321 in order to abuse SYSEVENTD the first thing that you do. And also, by the way they really 00:27:36.321-->00:27:41.093 hand you with a binary that really knows how to speak this protocol in RDK, uh, so you 00:27:41.093-->00:27:45.697 don't have to write any of your own stuff but the first step is you set up an event and the 00:27:45.697-->00:27:50.135 event you have two arguments to. You basically say here's here's the binary. I want there to to 00:27:50.135-->00:27:54.439 be fired. And here's the name of the event. And that registers the event in the system and then 00:27:54.439-->00:27:58.644 the next thing you do to trigger the event. You, uh, you basically trigger the event name 00:27:58.644-->00:28:03.282 which is what you see up here in step two. And you pass it in argument. And when you do that 00:28:03.282-->00:28:08.453 what happens is the binary that you, uh, configured the event with in step one is called and 00:28:08.453-->00:28:13.659 the first argument to the binary is the name of the event and the second argument to the binary is 00:28:13.659-->00:28:19.298 the value that you triggered the event with. Oh, what do you do with this? Well typically this 00:28:19.298-->00:28:22.568 is what we would we would assume this is being used for. Like oh let's say there's like a log 00:28:22.568-->00:28:26.471 file that's like placed on disk and as soon as that log file is placed on disk it's like oh we 00:28:26.471-->00:28:29.508 don't want to copy that to a separate directory, uh, so that's what you see up here. 00:28:29.508-->00:28:33.445 Like maybe when this XNL file hits the disk it's actually going to be copied into another 00:28:33.445-->00:28:37.916 location and be exfiltrated somewhere else. But what we want it to do is gain, y'know, 00:28:37.916-->00:28:43.422 arbitrary code execution. So if you create an event with a binary of Vin-bash and an event 00:28:43.422-->00:28:49.094 named dash c then whatever you supplied to the event is just passed as um as arguments to 00:28:49.094-->00:28:55.300 been dash. Code execution has root. Fantastic. So where's this app? Uh, it's bound to all 00:28:55.300-->00:29:00.739 interfaces across the entire IPv4 address space. We found 149 thousand instances of it. Uh, we 00:29:00.739-->00:29:04.042 don't really know why these weren't firewalled at all. But the majority of them were. Uh, 00:29:04.042-->00:29:09.815 but basically if you gain access to any of these LANs you'll probably see other SYSEVENTD or 00:29:09.815-->00:29:14.620 fastCGI. And the last thing that I'm gonna talk about is A Tale of Two Operating Systems. So, as 00:29:14.620-->00:29:18.523 Logan was talking about before these devices actually have two separate operating systems on 00:29:18.523-->00:29:22.728 them. Uh, one of them, uh, is what you would expect to see when you open up your browser. 00:29:22.728-->00:29:27.099 You go to configure your modem. That's a ten dot dot dot dot one. That's on arm side. Uh, and 00:29:27.099-->00:29:33.505 then there's a system on a chip that kind of handles all of the networking stuff, uh, that is an 00:29:33.505-->00:29:38.377 adam, uh, adam instance. And this is usually at the top of the DCP range that you're 00:29:38.377-->00:29:42.280 getting leases into right underneath the broadcast address. So the Adam instances, 00:29:42.280-->00:29:47.619 uh, are gonna be at ten dot dot dot dot dot two five four in most cases. And this, to this 00:29:47.619-->00:29:52.057 day, I don't know why this works. Uh, so so you know, we have a lot of really 00:29:52.057-->00:29:56.395 complementary skillsets up here and uh so I come over to Marc's place one day and he shows me, 00:29:56.395-->00:30:00.132 you know, he's teaching himself how to do this networking stuff. He's like "hey I did this" and I 00:30:00.132-->00:30:04.302 said "that's not supposed to work." Like that's not a thing. That's not supposed to happen. 00:30:04.302-->00:30:09.741 So, uh, the adam side has an interface that has an IP address in the one six nine two five 00:30:09.741-->00:30:13.712 four range which is not generally supposed supposed to be used it's not supposed to be 00:30:13.712-->00:30:18.784 routable. Uh, so it turns out that you can add a routing rule to your device that says hey 00:30:18.784-->00:30:22.587 when i'm trying to talk to one six nine two five four oh one, ten dot dot dot dot dot two five 00:30:22.587-->00:30:27.292 four is my gateway. And then you can talk to the private interface on the outside. And 00:30:27.292-->00:30:32.197 just forge traffic. I don't know if that's supposed to happen. I really think it's not. Uh, but 00:30:32.197-->00:30:36.535 this is pretty fantastic. I was like "Marc, what the h**l, what, oh my God." Uh and so once you 00:30:36.535-->00:30:40.472 actually have access to this you see the results of the endmap output out here, you see ports 00:30:40.472-->00:30:43.775 twn twenty-six through ten twenty-nine open. Those are the fastCGI servers that we were 00:30:43.775-->00:30:50.615 talking about before. Again you have code execution. Fantastic. >>Alright ya'll so I'm gonna 00:30:50.615-->00:30:55.420 walk you through our suite of vulnerabilities affecting set top boxes and voice remotes. So 00:30:55.420-->00:30:59.858 the first three affect set top boxes. Then I'm gonna have a hard transition to some wireless 00:30:59.858-->00:31:05.931 work. Then I'm gonna bring the rooted set top box back into the mix. Alright, so, for those of 00:31:05.931-->00:31:11.903 you who don't know, Marc Newlin is really good at slapping keys. Okay [laughter] He's really good 00:31:11.903-->00:31:18.110 at it. Especially so in context of set top boxes. He plugged a keyboard into a set top box. 00:31:18.110-->00:31:22.614 Proceeded to touch every key that he could. Hit every key combination that he could think 00:31:22.614-->00:31:27.619 of. And then we, this popped up on the television. A remote web inspector enabled. >>That's- 00:31:30.856-->00:31:35.160 that was surprising. Also, he was bashing a bunch of stuff and like the screen split in two and 00:31:35.160-->00:31:41.099 it-it-it was pretty, uh, >>It was pretty whack. But his is in fact real life. So, uh, remote 00:31:41.099-->00:31:47.639 web inspector. It's basically, like, firebug for firefox or dev tools for chrome where web 00:31:47.639-->00:31:54.246 developers can debug their web pages and that's really great when you're trying to find, 00:31:54.246-->00:31:59.818 y'know vulnerabilities in something that's running this. And uh you can actually hit this 00:31:59.818-->00:32:05.524 from over the internet. So thats pretty cool, right. So, uh, there's another key combination 00:32:05.524-->00:32:10.929 that you could hit and it would pull up a hidden diagnostic [inaudible] I'm totally that 00:32:10.929-->00:32:14.866 guy. >>Somebody's dying I'm sure >>I'm totally that guy. [laughter] >>Alright, so, uh, we 00:32:14.866-->00:32:19.871 could hit a key combination and pull up a hidden diagnostics menu. We, uh, just perused this 00:32:22.007-->00:32:28.713 diagnostics menu, looked at the traffic between the set top box and whatever services it was 00:32:28.713-->00:32:34.119 hitting. Uh, lo and behold there was a route, just by the name of the route made us think we could 00:32:34.119-->00:32:39.124 get arbitrary file reads on the set top box. If you were to post a legitimate file route, file 00:32:41.159-->00:32:45.831 path to a file on the file system you could just get the contents of that file and it 00:32:45.831-->00:32:50.836 worked. Yeah, so that's kind of neat, kind. Uh, and so since this is RDK and it's so 00:32:53.338-->00:32:57.709 standardized we already a good idea of all of the interesting things we wanted to look at. 00:33:01.213-->00:33:06.918 [clanging] Woo! [chuckle] Alright. So, uh the-uh for those of you who don't know. Uh, I've 00:33:06.918-->00:33:13.024 got a pro tent. It's generally best not to get random input from the internet and then 00:33:13.024-->00:33:18.029 execute it locally. >>It's rude >>I think you're not supposed to do that. >>Naw I don't think so. 00:33:20.198-->00:33:25.403 >>Protent. Yeah so sanitize your inputs guys. I think it's not the nineties anymore. Uh, we 00:33:25.403-->00:33:30.408 found a route and we could just, uh, essentially post to this route, uh a parameter that was 00:33:33.411-->00:33:38.416 shell command and we could just shell the box. GG easy mode. Alright, hard transition. Now 00:33:40.752-->00:33:46.892 we're getting to some wireless work. Uh, what you see up on the screen is an XR11 voice remote. 00:33:46.892-->00:33:52.364 And these are actually pretty cool. So, uh, the way they work. Once you pair it with your set 00:33:52.364-->00:33:57.702 top box they communicate over ROF instead of IR and so you can be super lazy and just point it 00:33:57.702-->00:34:04.242 anywhere you want. Uh, also they have a built in microphone and a button. And you press the button 00:34:04.242-->00:34:09.481 and you talk to the mic and you're like "hey um do something" or you can query it 00:34:09.481-->00:34:15.453 like you're talking to Siri or Lexa like "disable my home security system. Yeah, this is a 00:34:15.453-->00:34:21.660 thing. Whichever. So, uh, the the query goes up to your ISPs cloud and then it comes back 00:34:21.660-->00:34:27.098 down or it just executes locally. Yeah its pretty slick. Um, these things have a CC 00:34:27.098-->00:34:33.204 twenty-five thirty chip in them and I suspect they're running remote T I which is the 00:34:33.204-->00:34:38.877 reference design. You guys should look into it. Alright, so getting into the ROF. The 00:34:38.877-->00:34:43.882 protocol they use to communicate over ROF is called ROF 4CE. Radio For Consumer Electronics. 00:34:46.284-->00:34:50.689 It's a Zigbee standard based on eight oh two fifty dot four and it defines the way paired 00:34:50.689-->00:34:55.994 devices communicate with one another. Uh, one of the devices takes on the role of controller 00:34:55.994-->00:35:01.600 which is the, uh remote. Uh, the other takes on the role of target. In our case its set top 00:35:01.600-->00:35:08.206 box. And it finds how, uh, commands get sent from one device to another. So, the vast 00:35:08.206-->00:35:13.979 majority of ROF 4CE device is forced encryption out of the box. It-as it should. But, if 00:35:13.979-->00:35:20.819 you're a bad guy you can listen to the key exchange which is done in the clear or just forge 00:35:20.819-->00:35:27.325 a re-keying and then you can decrypt all of the traffic which is, I hear that's no bueno. Uh, 00:35:27.325-->00:35:34.032 this code is gonna be online in a day or a week or whenever it is allowed to be online. So, 00:35:34.032-->00:35:38.603 built on top of ROF 4CEs is another standard called open cable. And this, uh defines 00:35:38.603-->00:35:43.608 exactly how the remote sends key presses to the set top box. It also defines the way that you, 00:35:45.643-->00:35:52.283 uh conduct the binding process. So as an end user you press setup, mash the Xfinity button a 00:35:52.283-->00:35:57.922 couple and then a pin appears on your television. You enter it on your remote and then you're 00:35:57.922-->00:36:02.861 dandy and you're paired and that's great. And generally you have, uh, five to ten tries, uh 00:36:05.663-->00:36:11.002 before you have to actually reinitiate the binding process and we discovered that this 00:36:11.002-->00:36:16.841 binding process wasn't rate limited. Mkay. So if you had really really fast hands or a 00:36:16.841-->00:36:21.846 way of instrumenting this whole thing, yeah, uh that-that'd be great. So that's what we did. 00:36:24.816-->00:36:30.588 Uh, what you see- the chip you see on the right is teensy arduino hooked up over spy to 00:36:30.588-->00:36:35.593 the ADF7242P mod. I love this chip. Out of- out of the box it supports bluetooth, BLE, uh, 00:36:39.130-->00:36:43.868 eight oh two fifteen dot four, uh unmanaged and managed and arbitrary GFSK. If that's 00:36:43.868-->00:36:49.040 something that you all get excited about, please read the white paper it's pretty cool. So 00:36:49.040-->00:36:54.245 we implemented enough of the RF4CE stack and the open cable stack to go through this binding 00:36:54.245-->00:36:59.250 process and in practice it takes less than a second to do it. And we can force pair our device to 00:37:01.519-->00:37:07.559 a set top box in under two hours. And after you force pair a device you can pull up, uh, 00:37:07.559-->00:37:12.564 the diagnostics menu and enable remote web inspector and shell the set top box. Okay. So 00:37:14.933-->00:37:20.505 bringing the shelled set top box back into the mix. Uh, as I said, RDK has fantastic logging. 00:37:20.505-->00:37:25.510 So we were just prepping- >>So verbose >>Its sooo verbose >>So we were prepping around the logs 00:37:28.079-->00:37:34.252 for anything having to do with ROF4CE, right? And it turns out we were very easily able to 00:37:34.252-->00:37:40.291 discover the update daemon for the ROF4CE remote. We thought it would be really cool if we could 00:37:40.291-->00:37:45.196 potion over the air update to this remote and make a remote listening device. I mean, that 00:37:45.196-->00:37:49.701 would be pretty cool right. Totally didn't do that. Yeah, we haven't gone that far yet. You 00:37:49.701-->00:37:56.007 guys should do it. But we did prove that um you can push an OTA to the remote and the reason 00:37:56.007-->00:38:01.246 you can do this is because there's no crypto involved meaning the firmware payload 00:38:01.246-->00:38:08.019 isn't signed. It's just protected by CRC. So, all we had to do is make a few minor 00:38:08.019-->00:38:13.358 modifications to the update binary. The configuration it read and then we made 00:38:13.358-->00:38:17.996 modifications to the firmware payload so we could verify that the over the air update was in 00:38:17.996-->00:38:23.001 fact good. Then we change the CRC of the firmware package and push the OTA. And if you look up 00:38:25.570-->00:38:30.909 on the screen the reported firmware version is generally one zero one zero I think and we 00:38:30.909-->00:38:37.015 are the only ones with a remote with firmware version one three three seven. >>So now we'll take 00:38:37.015-->00:38:42.353 a look at the, uh, specific devices we looked at as well as the disclosure process and 00:38:42.353-->00:38:46.257 remediation actions taken by the affected vendors. So here we have the list of devices we 00:38:46.257-->00:38:51.129 found vulnerabilities in, uh, I wanna highlight the Technicolor Time Warner device there. Uh, we 00:38:51.129-->00:38:55.667 have no code execution on this device. This was a vulnerability where we had, y'know, we guessed 00:38:55.667-->00:39:01.105 both default wifi credentials. We have two Cisco modems with code execution. A Technicolor 00:39:01.105-->00:39:05.777 and Arris modem with code execution. This Motorola set top box with code execution and then 00:39:05.777-->00:39:10.114 the voice remote with the over the air firmware update that we can push. And in an effort to be 00:39:10.114-->00:39:14.052 diligent we've looked at a lot of devices from various ISPs to see if we can reproduce these 00:39:14.052-->00:39:18.656 vulnerabilities. So we look at devices from Spectrum, Mediacom, Time Warner, Virgin Media, 00:39:18.656-->00:39:24.262 Unitymedia, Cox, and one Xfinity device which did not run RDK. uh, this is not to say that 00:39:24.262-->00:39:27.632 these devices have no vulnerabilities. In fact, we do have other vulnerabilities in 00:39:27.632-->00:39:31.669 disclosure that we can't speak about yet. But, uh, y'know, we found a lot of devices that run 00:39:31.669-->00:39:36.541 RDK. But a lot of devices that do not run RDK. We found these vulnerabilities over the course 00:39:36.541-->00:39:40.011 of multiple months and so we disclose them to the affected vendors in four groups. We had 00:39:40.011-->00:39:44.349 the first two groups in March. The second two groups in April. The first public knowledge of 00:39:44.349-->00:39:48.052 this project was on July 11th and there was a really unfortunate mishap with the 00:39:48.052-->00:39:51.689 hosting provider that Defcon used for the Defcon website which was preventing customers 00:39:51.689-->00:39:55.560 from Comcast and some other ISPs from accessing the website. When our app jack was released this 00:39:55.560-->00:40:00.632 unfortunate mishap and then we publically disclosed these vulnerabilities today. I wanna 00:40:00.632-->00:40:04.269 point out that all of the unauthenticated RCE attack chains affecting the Comcast 00:40:04.269-->00:40:08.940 devices have been remediated. Customers of other ISPs are invited to contact their ISP to 00:40:08.940-->00:40:13.578 find out if their devices run RDK, if they're vulnerable and if they've been patched. And as 00:40:13.578-->00:40:18.483 I've said before we haven't had enough time to go in detail on all the vulnerabilities because 00:40:18.483-->00:40:23.655 we've found too many CBEs which is, uh, a good problem to have. So we invite you to go to our 00:40:23.655-->00:40:28.159 link to the white paper as you see there. To, uh, you up on Github >>That's not the link by 00:40:28.159-->00:40:33.598 the way. >> [laughter] So we have a pretty verbose technical detail on the white paper. And 00:40:33.598-->00:40:39.103 we found a lot of, y'know, very critical vulnerabilities but all of the worst attack chains have 00:40:39.103-->00:40:42.440 been patched. I wanna thank you guys for watching our talk. I want to thank Bastille for 00:40:42.440-->00:40:47.946 supporting our research. I wanna thank Comcast for remediating these attack chains. [applause] 00:40:47.946-->00:40:52.951 >>You know what. I'm gonna say this real quick. Uh the first time I heard about Defcon was 00:40:57.088-->00:41:02.026 when I was thirteen years old and I always wanted to be a part of this, uh, and I've been 00:41:10.168-->00:41:16.507 submitting for four years and I finally got in. It means the world for you guys to be here. 00:41:16.507-->00:41:17.275 [applause] [cheering]