[00:00.000 --> 00:05.560]  Welcome to Kicking Devices and Taking CBEs, The Zoomer's Guide to Hacking Shit, presented
[00:05.560 --> 00:11.220]  by yours truly, a fellow Zoomer. In this talk, I'm going to first introduce you to the life
[00:11.220 --> 00:18.180]  of a Zoomer, what happened before 2020, things I found instead of lost stocks, the methodology
[00:18.180 --> 00:23.380]  I used to find things instead of lost stocks, the actual hacking shit, which is why you
[00:23.380 --> 00:28.380]  guys are here. Hopefully, we'll get through a live-ish demo, and then I'm going to take
[00:28.380 --> 00:34.360]  you through a responsible disclosure and a call to action. So, the life of a Zoomer,
[00:34.360 --> 00:40.380]  aka me. I'm a junior security analyst at ISC, a rising electrical engineering senior at
[00:40.380 --> 00:46.880]  UCLA, and I'm primarily focused on cryptography, IoT and hardware security, and hiding from
[00:46.880 --> 00:53.000]  my dog. I enjoy researching IoT devices and collecting CBEs, and my research has been
[00:53.000 --> 01:02.120]  covered by publications such as Motherboard, Daily Swig, and ISMG. So, before 2020, aka
[01:02.120 --> 01:09.000]  before shit hit the fan, unlike Sam, I'm not a polite hacker, but it's okay. So, last year,
[01:09.000 --> 01:14.100]  in September, two weeks before I had to go back to school, my manager had like a mini
[01:14.100 --> 01:17.600]  dead week, so my manager grabbed her out of nowhere, and he's like, okay, do you want
[01:17.600 --> 01:21.360]  to poke around and find some derivatives? And I was like, sure. So, this presentation
[01:21.360 --> 01:28.320]  is the story of how I found five CBEs in about three days, and if a Zoomer can do it, pretty
[01:28.320 --> 01:34.680]  much anyone can. So, what do Zoomers want? There are two things we want, more than anything
[01:34.680 --> 01:40.120]  else in the world, the first being persistent remote shell, and the second being CBEs, because
[01:40.120 --> 01:47.860]  as you guys know, Zoomers love fame and fortune. So, what is a persistent remote shell? A persistent
[01:47.860 --> 01:53.160]  remote shell permanently allows an attacker to execute shell commands on another computer,
[01:53.160 --> 01:59.360]  in this case, the Tenda device, across the network, even if the device is reset or reboot.
[01:59.360 --> 02:03.540]  And obviously, you guys know why this is so important, because effectively, once we have
[02:03.540 --> 02:10.280]  persistent remote shell access, we have complete control over the device. What are CBEs? So,
[02:10.280 --> 02:15.600]  according to MITRE, CBEs are common vulnerability and exposure entries, and these are unique,
[02:15.600 --> 02:20.620]  common identifiers for publicly known information security vulnerabilities. So, of course we
[02:20.620 --> 02:24.460]  want them because, you know, if we get our name out in the security field, but also they're
[02:24.460 --> 02:28.340]  just a good way to keep track of the research that's going on in the field, and, you know,
[02:28.340 --> 02:35.740]  you might find it might be a stepping stone for further research. So, in this talk, we're
[02:35.740 --> 02:43.100]  going to be using the Tenda AC-15, AC-1900, smart dual-band gigabit Wi-Fi router, a really
[02:43.100 --> 02:49.760]  long name, as our scapegoat. And this device was running the 2019 firmware, which is the
[02:49.760 --> 02:59.660]  latest at the time when I began researching the 15.03.05.19 firmware version. So, the
[02:59.660 --> 03:04.720]  reason why we start, like, you should start your IT-embedded device research journey with
[03:04.720 --> 03:09.340]  routers is because, like, not only are they super easy to find, and, you know, they're
[03:09.340 --> 03:13.640]  pretty much everywhere, and they're also, like, the main pivot point for most smart,
[03:13.640 --> 03:19.660]  you know, homes and IoT networks, but they're also generally pretty cheap, and you can generally
[03:19.660 --> 03:25.560]  find them everywhere. Also, when you, you know, find something in a router, it's more fun to talk
[03:25.560 --> 03:32.140]  about. So, things I found instead of lost socks. So, I keep losing my socks. I'm really good at
[03:32.140 --> 03:37.500]  it. And, obviously, when I try to find them in my router, I'm not going to get anywhere. Instead,
[03:37.500 --> 03:46.700]  I found five CVEs. So, the first CVE, the first two instances were RCE, or remote code execution.
[03:46.840 --> 03:52.880]  So, this allows attackers to execute code or commands on a target device remotely over a
[03:52.880 --> 03:58.480]  network. And the reason why we want this is because it allows us to read, write, and delete
[03:58.480 --> 04:03.820]  content, gain persistent access, which is something similars want, and build botnets. I think there
[04:03.820 --> 04:09.080]  was a talk yesterday about how teams have too much time on their hands and enjoy building botnets,
[04:09.080 --> 04:17.740]  and I agree with this. The second attack we found was XSS, cross-site scripting. This allows
[04:17.740 --> 04:23.520]  attackers to inject malicious client-side scripts in web applications that will typically affect
[04:23.520 --> 04:29.040]  several users when executed by the browser. The reason why we want this is because it allows us
[04:29.040 --> 04:35.620]  to capture sensitive information, perform phishing attacks, and perform unauthorized actions. The
[04:35.620 --> 04:42.740]  third attack we found was CSRF, or cross-site request forgery. This forces end-users to execute
[04:42.740 --> 04:48.140]  unwanted state-changing actions on web applications in which they're currently authenticated. And the
[04:48.140 --> 04:53.580]  reason why we want this is because it allows us to indirectly perform unintended actions,
[04:53.580 --> 05:00.640]  exploit vulnerabilities that require authentication. Something to note here is that
[05:00.640 --> 05:07.940]  the user has to be authenticated for this attack to work. However, if you can chain this with other
[05:07.940 --> 05:12.800]  attacks, then, like I mentioned before, you can exploit vulnerabilities that require authentication
[05:12.800 --> 05:18.180]  and thereby increase the severity of those vulnerabilities, something that we will talk
[05:18.180 --> 05:24.560]  about a little more later on in this talk. So the last vulnerability I found was the hard-coded
[05:24.560 --> 05:29.900]  Telnet password in the source code. And this allows attackers to log in to the unencrypted
[05:29.900 --> 05:36.640]  Telnet daemon. And as you can see, this allows attackers to bring hell on earth. Okay, maybe not
[05:36.640 --> 05:42.460]  exactly hell on earth, but it definitely allows us to gain direct root shell access and basically
[05:42.460 --> 05:50.480]  persistent, which is something we want, and to build botnets. So generally, routers aren't
[05:50.480 --> 05:57.300]  supposed to allow Telnet, and usually it's not an option that's always on. And even if they do,
[05:57.300 --> 06:04.700]  usually the IoT devices will have the option for users to toggle this on or off. Unfortunately,
[06:04.700 --> 06:10.140]  or well, fortunately for us, the Tenda router does not do this, and the Telnet daemon remains
[06:10.140 --> 06:17.980]  on perpetually forever. Okay, so the methodology. So in this section, we're going to talk about the
[06:17.980 --> 06:22.800]  recon and areas of interest that you guys should look at and pay attention to when you're beginning
[06:22.800 --> 06:31.480]  your IoT research. So recon, again, is the most important part when you're formulating a task
[06:31.480 --> 06:39.140]  against any hardware or software. So the main things I looked at was four things. First, we
[06:39.700 --> 06:45.080]  because this is a good place to, you know, figure out what vulnerabilities exist in the device to
[06:45.080 --> 06:50.500]  start with, and also just because generally vulnerabilities will, you know, show up in the
[06:50.500 --> 06:55.740]  different endpoint or instance of the same device, or like a different device produced by the same
[06:55.740 --> 07:01.460]  manufacturer. The other things we looked at are, I looked at our network ports, the web interface,
[07:01.460 --> 07:09.980]  and again, because this is an embedded device, the firmware. So for the network ports, so I used
[07:09.980 --> 07:15.500]  Nmap. Again, something I should mention before going in further into this is that all of the
[07:15.500 --> 07:20.980]  methodology that we're going to talk about basically focuses on the vulnerabilities I've
[07:20.980 --> 07:25.440]  found. So we're going to be focusing on the Telnet and the hard-coded Telnet password,
[07:25.440 --> 07:31.680]  RCE, and then XSS and CSRF. So because you're looking for Telnet, you should check out and
[07:31.680 --> 07:39.340]  try to see if you can find port 23, 2323, or check if 9527 is open. It's also really cool to
[07:39.340 --> 07:46.040]  check for other open ports and check for unencrypted and unauthenticated communications.
[07:46.120 --> 07:52.000]  I think I found a really weird port called CSRListener or ERCListener, something I didn't
[07:52.000 --> 07:58.280]  really have time to check out. So I only had three days to work on this. But if you guys ever do feel
[07:58.280 --> 08:03.100]  like playing around with the Tender router, that's something I encourage you to check out and play
[08:03.100 --> 08:11.020]  with. Okay, so the web interface. So this router actually came with a web interface, not all
[08:11.020 --> 08:18.380]  embedded devices do. A good place to start, you know, your analysis is just manual testing and
[08:18.380 --> 08:24.220]  then later on use Verbsuite to try and help yourself out. So we began this process by
[08:24.220 --> 08:27.900]  mapping out the application, you know, going through the web interface, looking for injection
[08:27.900 --> 08:33.420]  points through user supply data, and then going through the request and looking for user control
[08:33.420 --> 08:40.660]  data. Something I want to mention here is that if you can see in this picture, many people overlook
[08:40.660 --> 08:46.460]  user control data, such as the headers here or the cookie. And because you have access to this
[08:46.460 --> 08:51.900]  data, you have the power to change it. It's something to keep in mind when you're beginning
[08:51.900 --> 08:58.460]  your research careers. The next thing we're going to look at is firmware. And as I mentioned before,
[08:58.460 --> 09:05.420]  we're focusing on hard-coded passwords and RCE. So I use Binlog to extract the files from the
[09:05.420 --> 09:11.200]  firmware, and then IDA Pro to, you know, disassemble the code and parse it. So because
[09:11.200 --> 09:16.140]  we're looking for hard-coded passwords, the best thing to do is to parse this assembled code and
[09:16.140 --> 09:21.400]  run strings. In this case, as you can see, we found this hard-coded password, but sometimes
[09:21.400 --> 09:27.400]  you might not always find hard-coded passwords. Generally, although if you do run strings and you
[09:27.400 --> 09:33.300]  do look for other cool, you know, strings in your firmware, you might find other interesting behavior,
[09:33.300 --> 09:40.160]  which is cool to look out for. The next thing we're going to be looking out for is RCE. So
[09:40.160 --> 09:47.100]  it's good to pay attention and search for system.cmd, popen, and exec. As you can see here,
[09:47.100 --> 09:52.760]  I found two instances of do system.cmd in the firmware, and we will talk about that a little
[09:52.760 --> 10:03.130]  later. So now it's time to actually hack shit, which is why you guys are here. So we're going to
[10:03.130 --> 10:10.950]  start with ccert. So I found the first instance of ccert that I found was on the sys.tool.reboot.get
[10:10.950 --> 10:15.910]  endpoint. Something to mention here is that, you know, state changing GET requests, as I mentioned
[10:15.910 --> 10:24.450]  previously, are inherently susceptible to ccert. This, again, works because of the lack of anti-ccert
[10:24.450 --> 10:30.450]  tokens and other anti-ccert protections. But, for example, if an attacker used this payload,
[10:30.450 --> 10:37.370]  image source payload, and successfully socially engineered the end user to run this, then the
[10:37.370 --> 10:42.490]  router would reboot. And if the attacker found a way to persistently send this to the router and
[10:42.490 --> 10:46.930]  persistently get that to the end user and persistently get the end user to submit this
[10:46.930 --> 10:54.250]  request, you would have persistent denial of service. The second vulnerability attack that
[10:54.250 --> 11:00.410]  we're going to talk about is XSS or cross-site scripting. So I was really prepared to go all
[11:00.410 --> 11:05.410]  out and, you know, use body tags and image tags and, you know, figure out a complicated payload
[11:05.410 --> 11:11.690]  to get this to work. I was very determined to get XSS working. I ended up just using a really basic
[11:11.690 --> 11:17.250]  script tag and that too on the Wi-Fi name, so I was kind of disappointed. But it's okay. I mean,
[11:17.250 --> 11:24.890]  efficiency is good. So here, I'm just using this to output and display the document cookie,
[11:24.890 --> 11:28.690]  which you can kind of see here. The document cookie, this is something I kind of want to
[11:28.690 --> 11:37.130]  mention for later, is that this is the password and this is the MD5 hash for mouse. So, first
[11:37.130 --> 11:41.570]  of all, it's good to pay attention that, you know, the router is using MD5 hashes, which is also
[11:41.690 --> 11:46.970]  really easy to, you know, crack. And there's tons of software out there such as, you know,
[11:46.970 --> 11:51.250]  Hashcat and John the Ripper. So, first of all, that was the biggest problem, but also
[11:51.850 --> 11:57.050]  this is something to look out for in the later parts of this talk.
[11:57.950 --> 12:05.650]  So, something I want to mention here is that, as you can see, for XSS to work, the attacker has
[12:05.650 --> 12:11.470]  to be authenticated, which makes this, you know, attack have really low severity. However, because
[12:11.470 --> 12:18.030]  we found Csurf, we can change this and, you know, increase the severity by training XSS with Csurf.
[12:19.130 --> 12:24.830]  And you can use a payload like this. So, what this does, it's kind of hard to see here, but
[12:24.830 --> 12:30.290]  all this does is it sends the document cookie, which, as you know, is the password to the attacker.
[12:30.370 --> 12:37.010]  Okay, so the next thing to look at, since we've gone through the web interface, is to start
[12:37.010 --> 12:42.350]  parsing the firmware. So, as you remember from the recon section, this is the first instance of
[12:42.350 --> 12:48.290]  the do system cmd command. So, we found this in the form set USB on load function and the
[12:49.130 --> 12:57.190]  httpd binary file on variable v2, which was device name. So, our next logical conclusion
[12:57.730 --> 13:02.890]  would be to look for this endpoint in the web interface, since we have access to the web
[13:02.890 --> 13:08.610]  interface, which is what we do. And we come across this endpoint and, as you can see, there's the
[13:08.610 --> 13:14.110]  device name. So, here we're just going to do a simple reboot command and the device reboots.
[13:14.110 --> 13:20.370]  Nothing much to see here. But, as you can tell, this is an authenticated request, which means that
[13:20.370 --> 13:27.070]  for this RCE to work, the attacker needs to be authenticated. So, we're going to increase
[13:27.070 --> 13:33.510]  the severity here by chaining this with CSRF again. So, if the attacker is able to successfully
[13:33.510 --> 13:40.410]  social engineer the end user, we can get this to reboot. And we basically... or, well, reboot is a
[13:40.410 --> 13:49.330]  very simple thing, but we could... we basically have RCE here, unauthenticated. So, as I kept
[13:49.330 --> 13:54.950]  parsing the firmware and playing around, poking around, I came across this string in the tendo
[13:54.950 --> 14:01.650]  login binary file. So, because it was, you know, the tendo login binary file, I figured I have to use it
[14:01.650 --> 14:07.670]  to log into something. So, and since I knew that Telnet was running on the device, I tried, you know,
[14:07.670 --> 14:14.430]  running this on the device. Okay, by the way, this is the md5 hash for fired up. Like, legit, just
[14:14.430 --> 14:22.470]  fired up. So, here I just Telnet it into the device and use fired up and I have persistent
[14:22.470 --> 14:29.290]  shell access to the device, which is one of the things Zoomers want and my goal has been achieved.
[14:29.610 --> 14:36.950]  Again, as... so, as I mentioned, we found another instance of do system cmd. So, this one was in
[14:36.950 --> 14:44.430]  the tendo Telnet function in the httpd binary file. And as you can see here, this was on variable v3,
[14:44.430 --> 14:49.690]  which was land.it. So, we're going to try something a little different here instead of going through
[14:49.690 --> 14:55.830]  the web interface and instead go through Telnet, since we have, you know, root shell access.
[14:56.010 --> 15:01.610]  So, what we're going to do is we're going to figure out how to set the value of land.it
[15:03.430 --> 15:10.790]  to, you know, to something that will get us a remote code execution. So,
[15:11.370 --> 15:17.450]  you go a little below this, you know, function, there's a command called cfm,
[15:17.450 --> 15:23.610]  which you can see here. So, what I'm going to do is I will set the value of land.ip using cfm,
[15:23.610 --> 15:28.410]  and I'm just going to set it to, like, the simple land.ip address and then, you know,
[15:28.410 --> 15:34.050]  touch a trash file. Something to note here is the reason why we're putting this in the temp folder
[15:34.050 --> 15:40.950]  is because that was one of the few read-write folders on the device. Something to keep a
[15:40.950 --> 15:46.090]  lookout for is when you're trying to, you know, change the state of an embedded device, you want
[15:46.090 --> 15:50.910]  to find a read-write folder so that you can actually do stuff with it, because most folders
[15:50.910 --> 15:57.550]  will be read-only. So, as you can see here, the trash file doesn't exist. And one thing to note
[15:57.550 --> 16:04.070]  here is that for this to work, you want the router to reboot first, because, like, it'll get executed
[16:04.070 --> 16:10.590]  once you actually turn that into the device. So, until you turn that into the device, this
[16:10.590 --> 16:15.370]  command won't work, so that's why the trash file doesn't already exist. So, what we're going to do
[16:15.370 --> 16:21.250]  is I've rebooted the device, and then we turn that back in, and once we see the end of temp,
[16:21.250 --> 16:26.950]  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:42.280]  So, for the first demo, I hope to show you guys a small glimpse in the kind of damage you can
[16:42.280 --> 16:48.640]  do with root shell access, and we will be demonstrating this through TomNet. So, since
[16:48.640 --> 16:55.400]  the router is an embedded device, we want to see where stuff is stored. In this case, basically,
[16:55.400 --> 17:02.020]  the non-volatile memory, which is the flash memory. So, in general, in embedded systems,
[17:02.020 --> 17:08.340]  you can usually find MTVs, which are memory technology devices, and these are device files
[17:08.340 --> 17:15.980]  created in Linux to interact with flash memory. So, a good way to see this is to figure out first
[17:15.980 --> 17:23.620]  how they are being partitioned in actual device memory. So, we will be doing this by cd'ing into
[17:23.620 --> 17:30.300]  the proc folder and outputting the contents of the MTD file. What's interesting to note here
[17:30.300 --> 17:39.940]  is the MTD6 block partition and the MTD7 block partition, where the 6th is cfm-backup and the
[17:39.940 --> 17:46.360]  7th is cfm. The cfm function is something that we discovered while we were playing around with
[17:46.360 --> 17:56.180]  the RCE on the lan.ip parameter, and hopefully we will find similar parameters such as the lan.ip
[17:56.180 --> 18:03.060]  in one of these block partitions. So, now we will go into the dev folder.
[18:03.240 --> 18:09.740]  So, we will first display the contents of the MTD6 block partition, which is the cfm-backup
[18:09.740 --> 18:17.040]  partition. The first param that pops out is the 2G wifi password, and as we keep scrolling up,
[18:17.040 --> 18:21.600]  we can see a lot of other interesting parameters that we could potentially, you know, play around
[18:21.600 --> 18:29.480]  with or observe. But if we keep scrolling up, we find the sys.userpass parameter, which as we know
[18:29.480 --> 18:38.360]  from previous results, consists of the md5 hash of mouse. And now we are going to output the
[18:38.360 --> 18:45.820]  contents of the MTD7 block. So, as we can see, the wifi password is obviously still the same.
[18:45.820 --> 18:51.460]  Also, by the way, this is the cfm partition. But now when we go to the sys.userpass parameter,
[18:51.600 --> 18:59.540]  the value is slightly different. And this is the md5 hash of mouse2. So, a little bit of backstory
[18:59.540 --> 19:06.320]  here. I originally set the password of the admin console to be mouse2, and then later on I changed
[19:06.320 --> 19:13.500]  it to mouse. So, what's interesting is that the cfm-backup partition stores the actual password
[19:13.500 --> 19:22.580]  that's being used on the admin console, aka mouse. And the cfm partition stores the most recent,
[19:22.580 --> 19:30.080]  previously used password. So, now we basically have access to the router's wifi passwords,
[19:30.080 --> 19:36.880]  both 2G and 5G. And we also have access to the user's admin console password,
[19:36.880 --> 19:42.040]  among other interesting information. Now, although this information is certainly fun,
[19:42.040 --> 19:48.660]  it would be definitely way cooler if we could change this. So, now our next goal is to figure
[19:48.660 --> 19:56.240]  out how to change, say, either the wifi password or the admin console password so that we're the
[19:56.240 --> 20:03.100]  only people who have access to it, and the OG user isn't able to access either their admin console
[20:03.100 --> 20:08.980]  or, you know, the router's wifi. What we're going to do is we're going to use a similar method to
[20:08.980 --> 20:15.160]  how we change the value for the lan.ip parameter, where we use cfm-set. So, here we're going to use
[20:15.160 --> 20:24.020]  cfm-set sys.userpass, and we will be changing it to the mouse is alive. So, a quick note here,
[20:24.020 --> 20:28.760]  while analyzing hardware or software, it's important to understand how the system is doing things.
[20:28.780 --> 20:35.720]  So, in this case, when you enter a password to log in on the admin console, it gets md5-hashed,
[20:35.720 --> 20:41.460]  and this hash is compared to the actual value stored in flash memory. So, here it's important that
[20:41.460 --> 20:46.720]  when you're actually setting the user pass, you're setting it to the md5-hash and not the actual
[20:46.720 --> 20:53.680]  plain text password that you want. So, now we will set this, and again, important to note that you have
[20:53.680 --> 21:00.840]  to reboot for this to actually, you know, take into effect. Once the router reboots, we will try
[21:01.400 --> 21:08.140]  logging in onto the admin console with our new password. Okay, so now that the router has rebooted,
[21:08.140 --> 21:20.490]  we will log in with the mouse is alive, and boom, we're in. So, for the second demo in this talk,
[21:20.490 --> 21:25.290]  we are going to find another way to gain persistent access to the device. Of course,
[21:25.290 --> 21:29.570]  we can always tell that into the router. I think also this is a good place to mention
[21:29.570 --> 21:38.970]  that Tenda has not released any updated firmware. So, as long as the AC1900 routers are using the
[21:38.970 --> 21:45.390]  2019 firmware, even potentially older firmware versions might have the hard-coded telnet password,
[21:45.710 --> 21:53.150]  then you should be able to use FireItUp to gain access to the router. But, come on, that's so basic.
[21:53.490 --> 21:58.650]  So, instead, we're going to try to see if we can chain one of our previously found
[21:58.650 --> 22:06.170]  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:19.210]  The best way to do that is to check if Wget is available on the embedded system that the device
[22:19.210 --> 22:27.370]  is using. So, when we type Wget here, we can see that the device is running a BusyBox version 1.19.2,
[22:27.370 --> 22:34.470]  which is a commonly found Linux system that's used a lot in embedded devices. And we can obviously
[22:34.470 --> 22:42.510]  see that Wget also exists, so this makes our life so much easier. I've already set up a reverse shell
[22:43.050 --> 22:50.130]  that connects to port 8123. So, here I'm going to serve it. I will be using Netcat to listen on
[22:50.130 --> 22:58.030]  port 8123 for incoming connections. So, my first step is I'm going to download the shell
[22:58.030 --> 23:03.290]  because we're hosting it, change the permission so that we can actually run it, and then run the
[23:03.290 --> 23:19.680]  shell. Okay, as we can see, the connection has been received and we have access to the device.
[23:19.680 --> 23:25.680]  But the first question to ask is, is this persistent? And we kind of know that it isn't,
[23:25.680 --> 23:31.340]  but a good way to check is by rebooting the router. What happens when the router reboots?
[23:31.340 --> 23:38.160]  But obviously, what we're expecting is that we won't find the shell in the comp folder
[23:38.160 --> 23:44.240]  because it's not persistent. And obviously, this is what happens. So, now what we're going to do
[23:44.240 --> 23:51.800]  is we're going to see if we can use the RCE to change this. So, we're going to first go ahead
[23:51.800 --> 23:57.480]  and connect cat to 8123 and start listening for incoming connections so that we don't accidentally
[23:58.120 --> 24:03.860]  run our script and forget to connect cat. I'm going to make a new fast script here
[24:03.860 --> 24:12.620]  called sizzle where we're going to use the RCE in land.ip. So, basically, we're going to do a
[24:12.620 --> 24:17.700]  cfm set land.ip and then run the same commands that we ran initially. So, we're going to cd
[24:17.700 --> 24:24.160]  attempt, download the shell, change the permissions, and run the shell. Something really important to
[24:24.160 --> 24:30.980]  note here is that you want to make sure you actually include the actual land.ip address
[24:30.980 --> 24:36.800]  in the beginning when you're setting land.ip. Otherwise, what will happen is, if you remember,
[24:36.800 --> 24:45.080]  during the actual RCE, it is running telnet at the land.ip address. So, if you don't do that,
[24:45.480 --> 24:51.360]  a. your router won't work properly and b. you won't be able to actually telnet into the device
[24:51.360 --> 24:57.780]  because there's nowhere to telnet to. This can only be fixed if you have physical access to
[24:57.780 --> 25:04.640]  the device, which in our case, or in a normal attacker's case, we won't have. Since, anyways,
[25:04.640 --> 25:10.120]  we're going to be running the script and because we know that land.ip isn't going to actually run
[25:10.120 --> 25:14.820]  until we reboot it and obviously when we're running the script, we might as well have,
[25:14.820 --> 25:20.900]  you know, our port connect back to the router. So, it makes sense to also, which is what we're
[25:20.900 --> 25:29.040]  doing here, to download the shell and then again change the permissions and run the shell.
[25:29.300 --> 25:33.740]  So, once we've created the script, it's obviously still being served on our server
[25:34.160 --> 25:39.300]  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:00.040]  So, our connection has been received and yeah, there's nothing to see detail, but
[26:00.040 --> 26:10.180]  um, when we list out our files, this is obviously all the files in the temp folder.
[26:10.340 --> 26:14.780]  But is this persistent? And this is something that we still want to check. So, we would think
[26:14.780 --> 26:19.560]  it's persistent and hopefully because of RCE, everything should work according to plan,
[26:19.560 --> 26:24.720]  but it's still good to check this. So, we're going to go ahead and reboot. Before we reboot,
[26:24.720 --> 26:31.300]  this is something that I kind of screwed up on a little bit when I was initially testing this out.
[26:31.760 --> 26:36.220]  Again, when you're trying to exploit systems, it's very important to understand how the system
[26:36.220 --> 26:40.940]  is processing things, or like in this case processing the RCE. But everything in the
[26:40.940 --> 26:46.720]  lambda.ip gets executed as soon as the router starts up. So, what I initially was doing when
[26:46.720 --> 26:53.980]  I was netcatting is that I was netcatting too late after the router, you know, had already started
[26:53.980 --> 27:00.360]  up. So, my netcat listener was missing the connection. So, that's why we're going to go
[27:00.360 --> 27:07.560]  ahead and first make netcat listen on port 8123 before we actually reboot the router. So, now
[27:07.560 --> 27:16.340]  that it's listening, we can go ahead and reboot the device and wait for it to reboot.
[27:16.340 --> 27:22.780]  And so, as soon as it starts up, we have access to the device with everything that
[27:22.780 --> 27:45.870]  Zoomers want to achieve in life. Cool. So, hopefully you guys had fun with the live-ish
[27:45.870 --> 27:51.390]  demo. And now that we've talked about how you can actually exploit the device,
[27:51.390 --> 27:56.750]  we're going to talk about responsible disclosure. So, the thing with responsible disclosure is
[27:56.750 --> 28:02.990]  before you can actually apply for CVs, it's good to talk to a manufacturer and see if you can
[28:03.710 --> 28:08.370]  get things fixed so that other people can't do the same exploits that you did.
[28:08.430 --> 28:15.170]  So, this is what responsible disclosure should actually look like. So, ideally,
[28:15.170 --> 28:22.090]  I would initially contact Tenda and they would reply to me within 45 days. We would talk about
[28:22.090 --> 28:30.670]  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:53.530]  They ghosted me. January 17th, I did my second vendor contact. I think they checked my email.
[28:53.530 --> 28:58.130]  Oh yeah, by the way, I obviously tracked my email. So, I think they checked my email
[28:59.930 --> 29:06.050]  January 18th at about 8 a.m. PST and I was like, why are you ghosting me, bro? But it's okay,
[29:06.050 --> 29:13.010]  I'm so used to it by now. So, July 10th, I got tired of waiting and I decided to write my blog
[29:13.010 --> 29:20.030]  and apply for CVs. This is something that you guys should look out for when you actually start
[29:20.030 --> 29:25.490]  researching and you move on to the Responsible Disclosure Conference. Try to get free swag.
[29:26.090 --> 29:32.370]  So, the next part and the last part of my presentation is a short call to action. So,
[29:32.370 --> 29:37.090]  this was the Zoomer's Guide to Hacking Shit. These are a couple of resources that can get
[29:37.090 --> 29:43.810]  you started in your research career. This is the QR code for my slides. So, if you guys want to check
[29:43.810 --> 29:49.190]  out the links, this is a good place to get started. The first is a link to my blog, which has a little
[29:49.190 --> 29:57.150]  more details on the actual walkthroughs of each vulnerability. The next is the AC-15 firmware
[29:57.150 --> 30:05.510]  version 15.03.05.19. So, a little backstory here is that they definitely did check my email and
[30:05.510 --> 30:11.690]  this is my proof because they removed this firmware from their global firmware site. But,
[30:11.690 --> 30:15.810]  it still exists on the US site. So, if you guys want to play around with it, I definitely encourage
[30:15.810 --> 30:22.990]  you to do so. The next is a MITRE link, best place to get started with checking out old CVEs.
[30:23.210 --> 30:27.910]  And then, Verbsuite and NRAP, if you guys don't already have this. IDA Pro,
[30:27.910 --> 30:33.450]  great resource for disassembling code. 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.