WEBVTT 00:00.000 --> 00:08.400 Welcome to Kicking Devices and Taking CBEs, The Zoomer's Guide to Hacking Shit, presented by yours truly, a fellow Zoomer. 00:08.580 --> 00:24.500 In this talk, I'm going to first introduce you to the life of a Zoomer, what happened before 2020, things I found instead of lost stocks, the methodology I used to find things instead of lost stocks, the actual hacking shit, which is why you guys are here. 00:24.500 --> 00:32.480 Hopefully, we'll get through a live-ish demo, and then I'm going to take you through a responsible disclosure and a call to action. 00:32.600 --> 00:35.340 So, the life of a Zoomer, aka me. 00:35.340 --> 00:47.900 I'm a junior security analyst at ISC, a rising electrical engineering senior at UCLA, and I'm primarily focused on cryptography, IoT and hardware security, and hiding from my dog. 00:47.900 --> 00:58.120 I enjoy researching IoT devices and collecting CBEs, and my research has been covered by publications such as Motherboard, Daily Swig, and ISMG. 00:58.760 --> 01:07.800 So, before 2020, aka before shit hit the fan, unlike Sam, I'm not a polite hacker, but it's okay. 01:07.840 --> 01:19.060 So, last year, in September, two weeks before I had to go back to school, my manager had like a mini dead week, so my manager grabbed her out of nowhere, and he's like, okay, do you want to poke around and find some derivatives? 01:19.060 --> 01:20.020 And I was like, sure. 01:20.140 --> 01:29.920 So, this presentation is the story of how I found five CBEs in about three days, and if a Zoomer can do it, pretty much anyone can. 01:30.560 --> 01:32.700 So, what do Zoomers want? 01:32.700 --> 01:43.900 There are two things we want, more than anything else in the world, the first being persistent remote shell, and the second being CBEs, because as you guys know, Zoomers love fame and fortune. 01:44.600 --> 01:47.280 So, what is a persistent remote shell? 01:47.280 --> 01:59.360 A persistent remote shell permanently allows an attacker to execute shell commands on another computer, in this case, the Tenda device, across the network, even if the device is reset or reboot. 01:59.360 --> 02:07.300 And obviously, you guys know why this is so important, because effectively, once we have persistent remote shell access, we have complete control over the device. 02:08.380 --> 02:10.000 What are CBEs? 02:10.000 --> 02:19.520 So, according to MITRE, CBEs are common vulnerability and exposure entries, and these are unique, common identifiers for publicly known information security vulnerabilities. 02:19.840 --> 02:31.960 So, of course we want them because, you know, if we get our name out in the security field, but also they're just a good way to keep track of the research that's going on in the field, and, you know, you might find it might be a stepping stone for further research. 02:33.720 --> 02:45.840 So, in this talk, we're going to be using the Tenda AC-15, AC-1900, smart dual-band gigabit Wi-Fi router, a really long name, as our scapegoat. 02:45.840 --> 02:58.060 And this device was running the 2019 firmware, which is the latest at the time when I began researching the 15.03.05.19 firmware version. 02:58.660 --> 03:13.640 So, the reason why we start, like, you should start your IT-embedded device research journey with routers is because, like, not only are they super easy to find, and, you know, they're pretty much everywhere, and they're also, like, the main pivot point for most smart, 03:13.640 --> 03:21.400 you know, homes and IoT networks, but they're also generally pretty cheap, and you can generally find them everywhere. 03:21.720 --> 03:26.280 Also, when you, you know, find something in a router, it's more fun to talk about. 03:26.780 --> 03:29.220 So, things I found instead of lost socks. 03:29.220 --> 03:31.140 So, I keep losing my socks. 03:31.140 --> 03:32.520 I'm really good at it. 03:32.520 --> 03:36.820 And, obviously, when I try to find them in my router, I'm not going to get anywhere. 03:36.880 --> 03:40.200 Instead, I found five CVEs. 03:40.320 --> 03:46.700 So, the first CVE, the first two instances were RCE, or remote code execution. 03:46.840 --> 03:53.440 So, this allows attackers to execute code or commands on a target device remotely over a network . 03:53.780 --> 04:03.300 And the reason why we want this is because it allows us to read, write, and delete content , gain persistent access, which is something similars want, and build botnets. 04:03.300 --> 04:11.060 I think there was a talk yesterday about how teams have too much time on their hands and enjoy building botnets, and I agree with this. 04:12.080 --> 04:17.140 The second attack we found was XSS, cross-site scripting. 04:17.140 --> 04:26.500 This allows attackers to inject malicious client-side scripts in web applications that will typically affect several users when executed by the browser. 04:26.500 --> 04:34.860 The reason why we want this is because it allows us to capture sensitive information, perform phishing attacks, and perform unauthorized actions. 04:34.980 --> 04:40.760 The third attack we found was CSRF, or cross-site request forgery. 04:40.760 --> 04:47.880 This forces end-users to execute unwanted state-changing actions on web applications in which they're currently authenticated. 04:47.880 --> 04:58.220 And the reason why we want this is because it allows us to indirectly perform unintended actions, exploit vulnerabilities that require authentication. 04:58.420 --> 05:05.140 Something to note here is that the user has to be authenticated for this attack to work. 05:05.500 --> 05:20.820 However, if you can chain this with other attacks, then, like I mentioned before, you can exploit vulnerabilities that require authentication and thereby increase the severity of those vulnerabilities, something that we will talk about a little more later on in this talk. 05:21.400 --> 05:26.980 So the last vulnerability I found was the hard-coded Telnet password in the source code. 05:26.980 --> 05:30.860 And this allows attackers to log in to the unencrypted Telnet daemon. 05:30.860 --> 05:35.680 And as you can see, this allows attackers to bring hell on earth. 05:35.680 --> 05:46.520 Okay, maybe not exactly hell on earth, but it definitely allows us to gain direct root shell access and basically persistent, which is something we want, and to build botnets. 05:47.140 --> 05:55.860 So generally, routers aren't supposed to allow Telnet, and usually it's not an option that's always on. 05:55.920 --> 06:03.980 And even if they do, usually the IoT devices will have the option for users to toggle this on or off. 06:03.980 --> 06:12.800 Unfortunately, or well, fortunately for us, the Tenda router does not do this, and the Telnet daemon remains on perpetually forever. 06:13.260 --> 06:16.200 Okay, so the methodology. 06:16.200 --> 06:24.900 So in this section, we're going to talk about the recon and areas of interest that you guys should look at and pay attention to when you're beginning your IoT research. 06:26.340 --> 06:34.020 So recon, again, is the most important part when you're formulating a task against any hardware or software. 06:34.260 --> 06:37.780 So the main things I looked at was four things. 06:37.780 --> 06:56.800 First, we because this is a good place to, you know, figure out what vulnerabilities exist in the device to start with, and also just because generally vulnerabilities will, you know, show up in the different endpoint or instance of the same device, or like a different device produced by the same manufacturer. 06:57.320 --> 07:04.300 The other things we looked at are, I looked at our network ports, the web interface, and again, because this is an embedded device, the firmware. 07:07.080 --> 07:10.960 So for the network ports, so I used Nmap. 07:10.960 --> 07:21.320 Again, something I should mention before going in further into this is that all of the methodology that we're going to talk about basically focuses on the vulnerabilities I've found. 07:21.320 --> 07:28.480 So we're going to be focusing on the Telnet and the hard-coded Telnet password, RCE, and then XSS and CSRF. 07:28.660 --> 07:38.240 So because you're looking for Telnet, you should check out and try to see if you can find port 23, 2323, or check if 9527 is open. 07:38.240 --> 07:46.040 It's also really cool to check for other open ports and check for unencrypted and unauthenticated communications. 07:46.120 --> 07:54.240 I think I found a really weird port called CSRListener or ERCListener, something I didn't really have time to check out. 07:54.260 --> 07:56.620 So I only had three days to work on this. 07:56.620 --> 08:03.840 But if you guys ever do feel like playing around with the Tender router, that's something I encourage you to check out and play with. 08:05.300 --> 08:07.800 Okay, so the web interface. 08:07.800 --> 08:12.720 So this router actually came with a web interface, not all embedded devices do. 08:12.860 --> 08:22.240 A good place to start, you know, your analysis is just manual testing and then later on use Verbsuite to try and help yourself out. 08:22.240 --> 08:34.260 So we began this process by mapping out the application, you know, going through the web interface, looking for injection points through user supply data, and then going through the request and looking for user control data. 08:34.260 --> 08:44.360 Something I want to mention here is that if you can see in this picture, many people overlook user control data, such as the headers here or the cookie. 08:44.360 --> 08:48.840 And because you have access to this data, you have the power to change it. 08:48.840 --> 08:53.880 It's something to keep in mind when you're beginning your research careers. 08:55.040 --> 08:57.440 The next thing we're going to look at is firmware. 08:57.440 --> 09:02.360 And as I mentioned before, we're focusing on hard-coded passwords and RCE. 09:02.440 --> 09:10.460 So I use Binlog to extract the files from the firmware, and then IDA Pro to, you know, disassemble the code and parse it. 09:10.460 --> 09:17.460 So because we're looking for hard-coded passwords, the best thing to do is to parse this assembled code and run strings. 09:17.820 --> 09:23.960 In this case, as you can see, we found this hard-coded password, but sometimes you might not always find hard-coded passwords. 09:24.040 --> 09:35.180 Generally, although if you do run strings and you do look for other cool, you know, strings in your firmware, you might find other interesting behavior, which is cool to look out for. 09:36.320 --> 09:39.820 The next thing we're going to be looking out for is RCE. 09:39.820 --> 09:45.860 So it's good to pay attention and search for system.cmd, popen, and exec. 09:45.860 --> 09:53.720 As you can see here, I found two instances of do system.cmd in the firmware, and we will talk about that a little later. 09:56.170 --> 10:02.230 So now it's time to actually hack shit, which is why you guys are here. 10:02.550 --> 10:05.410 So we're going to start with ccert. 10:06.130 --> 10:11.830 So I found the first instance of ccert that I found was on the sys.tool.reboot.get endpoint. 10:11.830 --> 10:20.870 Something to mention here is that, you know, state changing GET requests, as I mentioned previously, are inherently susceptible to ccert. 10:21.170 --> 10:27.290 This, again, works because of the lack of anti-ccert tokens and other anti-ccert protections. 10:27.330 --> 10:38.810 But, for example, if an attacker used this payload, image source payload, and successfully socially engineered the end user to run this, then the router would reboot. 10:38.810 --> 10:50.670 And if the attacker found a way to persistently send this to the router and persistently get that to the end user and persistently get the end user to submit this request, you would have persistent denial of service. 10:51.950 --> 10:57.770 The second vulnerability attack that we're going to talk about is XSS or cross-site scripting. 10:57.770 --> 11:06.450 So I was really prepared to go all out and, you know, use body tags and image tags and, you know, figure out a complicated payload to get this to work. 11:06.450 --> 11:08.690 I was very determined to get XSS working. 11:08.930 --> 11:15.070 I ended up just using a really basic script tag and that too on the Wi-Fi name, so I was kind of disappointed. 11:15.390 --> 11:16.510 But it's okay. 11:16.530 --> 11:18.530 I mean, efficiency is good. 11:18.770 --> 11:26.610 So here, I'm just using this to output and display the document cookie, which you can kind of see here. 11:26.910 --> 11:36.750 The document cookie, this is something I kind of want to mention for later, is that this is the password and this is the MD5 hash for mouse. 11:36.750 --> 11:44.450 So, first of all, it's good to pay attention that, you know, the router is using MD5 hashes, which is also really easy to, you know, crack. 11:44.450 --> 11:48.430 And there's tons of software out there such as, you know, Hashcat and John the Ripper. 11:48.690 --> 11:57.050 So, first of all, that was the biggest problem, but also this is something to look out for in the later parts of this talk. 11:57.950 --> 12:10.510 So, something I want to mention here is that, as you can see, for XSS to work, the attacker has to be authenticated, which makes this, you know, attack have really low severity. 12:10.610 --> 12:18.030 However, because we found Csurf, we can change this and, you know, increase the severity by training XSS with Csurf. 12:19.130 --> 12:21.430 And you can use a payload like this. 12:21.610 --> 12:30.290 So, what this does, it's kind of hard to see here, but all this does is it sends the document cookie, which, as you know, is the password to the attacker. 12:30.370 --> 12:38.490 Okay, so the next thing to look at, since we've gone through the web interface, is to start parsing the firmware. 12:38.570 --> 12:44.530 So, as you remember from the recon section, this is the first instance of the do system cmd command. 12:44.550 --> 12:55.390 So, we found this in the form set USB on load function and the httpd binary file on variable v2, which was device name. 12:55.390 --> 13:05.650 So, our next logical conclusion would be to look for this endpoint in the web interface, since we have access to the web interface, which is what we do. 13:05.650 --> 13:09.670 And we come across this endpoint and, as you can see, there's the device name. 13:09.750 --> 13:14.110 So, here we're just going to do a simple reboot command and the device reboots. 13:14.110 --> 13:15.410 Nothing much to see here. 13:15.410 --> 13:25.010 But, as you can tell, this is an authenticated request, which means that for this RCE to work, the attacker needs to be authenticated. 13:25.010 --> 13:30.650 So, we're going to increase the severity here by chaining this with CSRF again. 13:30.650 --> 13:38.570 So, if the attacker is able to successfully social engineer the end user, we can get this to reboot. 13:38.570 --> 13:45.510 And we basically... or, well, reboot is a very simple thing, but we could... we basically have RCE here, unauthenticated. 13:46.350 --> 13:56.590 So, as I kept parsing the firmware and playing around, poking around, I came across this string in the tendo login binary file. 13:56.990 --> 14:03.270 So, because it was, you know, the tendo login binary file, I figured I have to use it to log into something. 14:03.390 --> 14:09.130 So, and since I knew that Telnet was running on the device, I tried, you know, running this on the device. 14:09.130 --> 14:13.550 Okay, by the way, this is the md5 hash for fired up. 14:13.550 --> 14:15.490 Like, legit, just fired up. 14:15.490 --> 14:29.290 So, here I just Telnet it into the device and use fired up and I have persistent shell access to the device, which is one of the things Zoomers want and my goal has been achieved. 14:29.610 --> 14:35.210 Again, as... so, as I mentioned, we found another instance of do system cmd. 14:35.530 --> 14:40.970 So, this one was in the tendo Telnet function in the httpd binary file. 14:41.050 --> 14:46.370 And as you can see here, this was on variable v3, which was land.it. 14:46.510 --> 14:55.830 So, we're going to try something a little different here instead of going through the web interface and instead go through Telnet, since we have, you know, root shell access. 14:56.010 --> 15:09.550 So, what we're going to do is we're going to figure out how to set the value of land.it to, you know, to something that will get us a remote code execution. 15:09.970 --> 15:18.770 So, you go a little below this, you know, function, there's a command called cfm, which you can see here. 15:18.970 --> 15:29.990 So, what I'm going to do is I will set the value of land.ip using cfm, and I'm just going to set it to, like, the simple land.ip address and then, you know, touch a trash file. 15:30.950 --> 15:39.130 Something to note here is the reason why we're putting this in the temp folder is because that was one of the few read-write folders on the device. 15:39.130 --> 15:52.630 Something to keep a lookout for is when you're trying to, you know, change the state of an embedded device, you want to find a read-write folder so that you can actually do stuff with it, because most folders will be read-only. 15:53.110 --> 15:55.850 So, as you can see here, the trash file doesn't exist. 15:55.850 --> 16:06.790 And one thing to note here is that for this to work, you want the router to reboot first, because, like, it'll get executed once you actually turn that into the device. 16:07.270 --> 16:14.210 So, until you turn that into the device, this command won't work, so that's why the trash file doesn't already exist. 16:14.430 --> 16:26.950 So, what we're going to do is I've rebooted the device, and then we turn that back in, and once we see the end of temp, you can see that the trash file has been created, thus giving us, you know, an RCP. 16:28.370 --> 16:32.670 Okay, so now it's time for the live-ish demo. 16:36.060 --> 16:48.100 So, for the first demo, I hope to show you guys a small glimpse in the kind of damage you can do with root shell access, and we will be demonstrating this through TomNet. 16:48.220 --> 16:53.660 So, since the router is an embedded device, we want to see where stuff is stored. 16:53.660 --> 16:58.840 In this case, basically, the non-volatile memory, which is the flash memory. 16:58.880 --> 17:12.680 So, in general, in embedded systems, you can usually find MTVs, which are memory technology devices, and these are device files created in Linux to interact with flash memory. 17:12.700 --> 17:20.720 So, a good way to see this is to figure out first how they are being partitioned in actual device memory. 17:20.720 --> 17:28.660 So, we will be doing this by cd'ing into the proc folder and outputting the contents of the MTD file. 17:28.660 --> 17:42.100 What's interesting to note here is the MTD6 block partition and the MTD7 block partition, where the 6th is cfm-backup and the 7th is cfm. 17:42.100 --> 17:59.520 The cfm function is something that we discovered while we were playing around with the RCE on the lan.ip parameter, and hopefully we will find similar parameters such as the lan.ip in one of these block partitions. 17:59.880 --> 18:03.060 So, now we will go into the dev folder. 18:03.240 --> 18:10.780 So, we will first display the contents of the MTD6 block partition, which is the cfm-backup partition. 18:10.780 --> 18:22.920 The first param that pops out is the 2G wifi password, and as we keep scrolling up, we can see a lot of other interesting parameters that we could potentially, you know, play around with or observe. 18:23.020 --> 18:36.100 But if we keep scrolling up, we find the sys.userpass parameter, which as we know from previous results, consists of the md5 hash of mouse. 18:36.240 --> 18:41.520 And now we are going to output the contents of the MTD7 block. 18:41.600 --> 18:45.820 So, as we can see, the wifi password is obviously still the same. 18:45.820 --> 18:48.320 Also, by the way, this is the cfm partition. 18:48.420 --> 18:54.260 But now when we go to the sys.userpass parameter, the value is slightly different. 18:54.260 --> 18:58.120 And this is the md5 hash of mouse2. 18:58.120 --> 19:00.700 So, a little bit of backstory here. 19:00.700 --> 19:07.940 I originally set the password of the admin console to be mouse2, and then later on I changed it to mouse. 19:07.940 --> 19:17.140 So, what's interesting is that the cfm-backup partition stores the actual password that's being used on the admin console, aka mouse. 19:17.140 --> 19:24.740 And the cfm partition stores the most recent, previously used password. 19:24.840 --> 19:32.240 So, now we basically have access to the router's wifi passwords, both 2G and 5G. 19:32.240 --> 19:39.380 And we also have access to the user's admin console password, among other interesting information. 19:39.380 --> 19:46.720 Now, although this information is certainly fun, it would be definitely way cooler if we could change this. 19:46.760 --> 20:05.960 So, now our next goal is to figure out how to change, say, either the wifi password or the admin console password so that we're the only people who have access to it, and the OG user isn't able to access either their admin console or, you know, the router's wifi. 20:06.280 --> 20:13.720 What we're going to do is we're going to use a similar method to how we change the value for the lan.ip parameter, where we use cfm-set. 20:13.740 --> 20:22.540 So, here we're going to use cfm-set sys.userpass, and we will be changing it to the mouse is alive. 20:22.660 --> 20:28.760 So, a quick note here, while analyzing hardware or software, it's important to understand how the system is doing things. 20:28.780 --> 20:39.860 So, in this case, when you enter a password to log in on the admin console, it gets md5-hashed, and this hash is compared to the actual value stored in flash memory. 20:40.140 --> 20:49.000 So, here it's important that when you're actually setting the user pass, you're setting it to the md5-hash and not the actual plain text password that you want. 20:49.360 --> 20:58.120 So, now we will set this, and again, important to note that you have to reboot for this to actually, you know, take into effect. 20:58.220 --> 21:05.280 Once the router reboots, we will try logging in onto the admin console with our new password. 21:05.280 --> 21:14.080 Okay, so now that the router has rebooted, we will log in with the mouse is alive, and boom, we're in. 21:17.410 --> 21:24.690 So, for the second demo in this talk, we are going to find another way to gain persistent access to the device. 21:24.690 --> 21:27.630 Of course, we can always tell that into the router. 21:27.770 --> 21:33.710 I think also this is a good place to mention that Tenda has not released any updated firmware. 21:33.710 --> 21:50.250 So, as long as the AC1900 routers are using the 2019 firmware, even potentially older firmware versions might have the hard-coded telnet password, then you should be able to use FireItUp to gain access to the router. 21:50.530 --> 21:53.150 But, come on, that's so basic. 21:53.490 --> 22:06.170 So, instead, we're going to try to see if we can chain one of our previously found RCEs with the telnet to find another way of getting persistent access to the device. 22:06.450 --> 22:13.210 So, when we start, the first thing to do is to check if you can download files onto the router. 22:13.210 --> 22:20.030 The best way to do that is to check if Wget is available on the embedded system that the device is using. 22:20.030 --> 22:33.590 So, when we type Wget here, we can see that the device is running a BusyBox version 1.19.2, which is a commonly found Linux system that's used a lot in embedded devices. 22:33.670 --> 22:39.750 And we can obviously see that Wget also exists, so this makes our life so much easier. 22:39.750 --> 22:45.430 I've already set up a reverse shell that connects to port 8123. 22:45.430 --> 22:47.270 So, here I'm going to serve it. 22:47.270 --> 22:53.570 I will be using Netcat to listen on port 8123 for incoming connections. 22:53.850 --> 23:04.110 So, my first step is I'm going to download the shell because we're hosting it, change the permission so that we can actually run it, and then run the shell. 23:13.680 --> 23:19.680 Okay, as we can see, the connection has been received and we have access to the device. 23:19.680 --> 23:23.360 But the first question to ask is, is this persistent? 23:23.360 --> 23:29.280 And we kind of know that it isn't, but a good way to check is by rebooting the router. 23:29.280 --> 23:31.340 What happens when the router reboots? 23:31.340 --> 23:40.480 But obviously, what we're expecting is that we won't find the shell in the comp folder because it's not persistent. 23:40.520 --> 23:43.120 And obviously, this is what happens. 23:43.240 --> 23:50.600 So, now what we're going to do is we're going to see if we can use the RCE to change this. 23:50.600 --> 24:00.740 So, we're going to first go ahead and connect cat to 8123 and start listening for incoming connections so that we don't accidentally run our script and forget to connect cat. 24:00.740 --> 24:10.520 I'm going to make a new fast script here called sizzle where we're going to use the RCE in land.ip. 24:10.740 --> 24:16.980 So, basically, we're going to do a cfm set land.ip and then run the same commands that we ran initially. 24:16.980 --> 24:23.000 So, we're going to cd attempt, download the shell, change the permissions, and run the shell. 24:23.000 --> 24:33.780 Something really important to note here is that you want to make sure you actually include the actual land.ip address in the beginning when you're setting land.ip. 24:33.780 --> 24:42.760 Otherwise, what will happen is, if you remember, during the actual RCE, it is running telnet at the land.ip address. 24:42.760 --> 24:45.800 So, if you don't do that, a. 24:45.800 --> 24:48.280 your router won't work properly and b. 24:48.280 --> 24:53.900 you won't be able to actually telnet into the device because there's nowhere to telnet to. 24:53.960 --> 25:03.660 This can only be fixed if you have physical access to the device, which in our case, or in a normal attacker's case, we won't have. 25:03.660 --> 25:18.280 Since, anyways, we're going to be running the script and because we know that land.ip isn't going to actually run until we reboot it and obviously when we're running the script, we might as well have, you know, our port connect back to the router. 25:18.440 --> 25:29.040 So, it makes sense to also, which is what we're doing here, to download the shell and then again change the permissions and run the shell. 25:29.300 --> 25:39.300 So, once we've created the script, it's obviously still being served on our server and we're going to go ahead and download our sizzle script. 25:41.940 --> 25:51.440 And then we will change the permission and go ahead and run it. 25:52.660 --> 26:10.180 So, our connection has been received and yeah, there's nothing to see detail, but um, when we list out our files, this is obviously all the files in the temp folder. 26:10.340 --> 26:12.040 But is this persistent? 26:12.040 --> 26:13.840 And this is something that we still want to check. 26:13.840 --> 26:21.820 So, we would think it's persistent and hopefully because of RCE, everything should work according to plan, but it's still good to check this. 26:21.820 --> 26:23.640 So, we're going to go ahead and reboot. 26:23.660 --> 26:31.300 Before we reboot, this is something that I kind of screwed up on a little bit when I was initially testing this out. 26:31.760 --> 26:39.760 Again, when you're trying to exploit systems, it's very important to understand how the system is processing things, or like in this case processing the RCE. 26:40.060 --> 26:45.020 But everything in the lambda.ip gets executed as soon as the router starts up. 26:45.020 --> 26:54.480 So, what I initially was doing when I was netcatting is that I was netcatting too late after the router, you know, had already started up. 26:54.480 --> 26:58.680 So, my netcat listener was missing the connection. 26:58.740 --> 27:07.020 So, that's why we're going to go ahead and first make netcat listen on port 8123 before we actually reboot the router. 27:07.020 --> 27:16.340 So, now that it's listening, we can go ahead and reboot the device and wait for it to reboot. 27:16.340 --> 27:26.040 And so, as soon as it starts up, we have access to the device with everything that Zoomers want to achieve in life. 27:40.470 --> 27:41.350 Cool. 27:41.350 --> 27:46.950 So, hopefully you guys had fun with the live-ish demo. 27:46.950 --> 27:54.250 And now that we've talked about how you can actually exploit the device, we're going to talk about responsible disclosure. 27:54.650 --> 28:08.370 So, the thing with responsible disclosure is before you can actually apply for CVs, it's good to talk to a manufacturer and see if you can get things fixed so that other people can't do the same exploits that you did. 28:08.430 --> 28:14.150 So, this is what responsible disclosure should actually look like. 28:14.150 --> 28:21.350 So, ideally, I would initially contact Tenda and they would reply to me within 45 days. 28:21.350 --> 28:30.670 We would talk about litigation, see if they need any extra information from me, and then hopefully I would get free swag. 28:30.670 --> 28:35.830 And then we'd go move on to public disclosure and I would apply for CVs. 28:36.090 --> 28:44.850 What ended up happening was that January 2nd, I made my first initial vendor contact to Tenda. 28:44.850 --> 28:46.310 They ghosted me. 28:46.450 --> 28:50.410 January 17th, I did my second vendor contact. 28:50.830 --> 28:53.530 I think they checked my email. 28:53.530 --> 28:55.950 Oh yeah, by the way, I obviously tracked my email. 28:55.950 --> 29:01.690 So, I think they checked my email January 18th at about 8 a.m. 29:01.690 --> 29:05.150 PST and I was like, why are you ghosting me, bro? 29:05.150 --> 29:07.690 But it's okay, I'm so used to it by now. 29:07.830 --> 29:15.530 So, July 10th, I got tired of waiting and I decided to write my blog and apply for CVs. 29:16.490 --> 29:23.590 This is something that you guys should look out for when you actually start researching and you move on to the Responsible Disclosure Conference. 29:23.590 --> 29:25.490 Try to get free swag. 29:26.090 --> 29:31.910 So, the next part and the last part of my presentation is a short call to action. 29:32.070 --> 29:35.110 So, this was the Zoomer's Guide to Hacking Shit. 29:35.110 --> 29:39.590 These are a couple of resources that can get you started in your research career. 29:39.670 --> 29:42.410 This is the QR code for my slides. 29:42.410 --> 29:46.750 So, if you guys want to check out the links, this is a good place to get started. 29:46.750 --> 29:53.670 The first is a link to my blog, which has a little more details on the actual walkthroughs of each vulnerability. 29:54.410 --> 30:01.030 The next is the AC-15 firmware version 15.03.05.19. 30:01.190 --> 30:11.470 So, a little backstory here is that they definitely did check my email and this is my proof because they removed this firmware from their global firmware site. 30:11.470 --> 30:13.050 But, it still exists on the US site. 30:13.050 --> 30:17.590 So, if you guys want to play around with it, I definitely encourage you to do so. 30:17.770 --> 30:22.990 The next is a MITRE link, best place to get started with checking out old CVEs. 30:23.210 --> 30:27.210 And then, Verbsuite and NRAP, if you guys don't already have this. 30:27.210 --> 30:30.470 IDA Pro, great resource for disassembling code. 30:30.470 --> 30:33.450 And then, there's a short more resources link. 30:34.770 --> 30:41.010 So, that was the Zoomer's Guide to Hacking Shit and Picking Devices and Taking CVEs. 30:41.010 --> 30:46.430 I will be joining the Discord channel for extra questions.