 Welcome to Kicking Devices and taking CBEs, the Zoomer's Guide to Hacking Shit, presented by yours truly, a fellow Zoomer. In this talk, I'm gonna 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, actual hacking shit, which is why you guys are here. Hopefully we'll get through a live-ish demo and then I'm gonna take you through responsible disclosure and a call to action. So the life of a Zoomer, AKA me, 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. I enjoy researching IoT devices and collecting CBEs and my research has been covered by publications such as Motherboards, Daily Swig, and ISMG. So before 2020, AKA before shit hit the fan, unlike Sam, I'm not a polite hacker, but it's okay. So last year, in September, two weeks before I had to go back to school, my manager, I had like a many dead weeks, and my manager grabbed her out or out of nowhere and he's like, okay, do you want to poke around and find some dirties? And I was like, sure. So this presentation is the story of how I found five CBEs in about three days, and I presume I can do it pretty much anyone can. So what do Zoomers want? 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. So what is a persistent remote shell? A persistent remote shell permanently allows an attacker to execute shell commands on another computer. You can just showcase the tender device across the network, even if the device is reset or reboot. 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. What are CBEs? So according to MITRE, CBEs are common vulnerability and exposure entries, and these are unique common identifiers for publicly known information security vulnerabilities. So of course we want them because 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 might find it might be a stepping stone for further research. So in this talk, we're going to be using the Tenda AC-15 AC-1900 smart dual band gigabit wifi router is a really long name as our escape code. And this device was running for 2019 firmware, which was the latest at the time when I began researching the 15.03.05.19 firmware version. So the reason why we start, like you should start your IoT embedded device research journey with routers is because like not only are they super easy to find and they're pretty much everywhere. And they're also like the main pivot point for most smart homes and IoT networks, but they're also generally pretty cheap and you can generally find them everywhere. Also when you find something in a router, it's more fun to talk about. So things I found instead of lost socks. So I keep losing my socks. I'm really good at it. And obviously when I try to find them in my router, I'm not gonna get anywhere. Instead I found five CVEs. So the first two instances were RCE or remote code execution. So this allows attackers to execute code or commands on a target device remotely over a network. And the reason why we want this is because it allows us to read, write and delete content, gain persistent access, which is something similar as want and build botnets. 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. The second attack we found was XSS, cross-site scripting. This allows attackers to inject malicious client-side scripts in web applications that will typically affect several users when executed by the browser. The reason why we want this is because it allows us to capture sensitive information, perform phishing attacks, and perform unauthorized actions. The third attack we found was CSER or cross-site request forgery. This forces end users to execute unwanted state-changing actions on web applications in which they're currently authenticated. And the reason why we want this is because it allows us to indirectly perform unintended actions, exploit vulnerabilities that require authentic and exploit vulnerabilities that require authentication. So something to note here is that the user has to be authenticated for this attack to work. However, if you can change 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. So the last vulnerability I found was the hard-coded Telnet password in the source code. And this allows attackers to log into the unencrypted Telnet daemon. And as you can see, this allows attackers to bring hell on Earth. 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. So generally, routers aren't supposed to allow Telnet. And usually it's not an option that's always on. And even if they do, usually the IoT devices will have the option for users to toggle this on or off. Unfortunately, or well, fortunately for us, the Tender router does not do this and the Telnet daemon remains on, especially, forever. Okay, so the methodology. 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. So recon, again, is the most important part when you're formulating a task against any hardware or software. So the main things I looked at was four things. First, we started with LCBEs because this is a good place to figure out what vulnerabilities exist in the device to start with. And also just because generally vulnerabilities will show up in the different endpoint or instance of the same device or a different device produced by the same manufacturer. So 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. So for the network ports. So I used a map, again, something I should mention before going in further into this is that all of the methodology that we're going to talk about is we focus on the vulnerabilities I found. So we're going to be focusing on the Telnet and the hard coded Telnet password, RCE, and then XSS and CSERF. So because you're looking for Telnet, you should check out and try to see if you can find ports 23, 23, 23, or check if 9527 is open. It's also really cool to check for other open ports. And see it's a check for unencrypted and unauthenticated communication. I think I found a really weird port called CSRListener or ERCListener, something I didn't really have time to check out. I only had three days to work on this, but if you guys ever do feel like playing around with the Tender Riders with something, I encourage you to check out and play with. Okay, so the web interface. So this router actually came with a web interface, not all embedded devices do. A good place to start your analysis is just manual testing, and then later on use Verb Suite to try and help yourself out. So I began this process by mapping out the application, going through the web interface, looking for injection points through user-supplied data, and then going through the request and looking for user-controlled data. Something I want to mention here is that if you can see in this picture, many people overlook user-controlled data, such as the headers here or the cookie, and because you have access to this data, you have the power to change it to something to keep in mind when you're beginning your research careers. The next thing we're going to look at is firmware, and as I mentioned before, we're focusing on hard-cutted passwords and RCE. So I used BinLock to extract the files from the firmware, and then I had a pro to disassemble the code and parse it. So because we're looking for hard-cutted passwords, the best thing to do is to parse the disassembled code and run strings. In this case, as you can see, we found this hard-coded password, but sometimes you might not always find hard-coded password. Generally, although if you do run strings and you do look for other cool strings in your firmware, you might find other interesting behavior, which is cool to look out for. The next thing we're going to be looking out for is RCE. So it's good to pay attention and search for system.cmd, popen, and exec. As you can see here, I found two instances of due system.cmd in the firmware, and we will talk about that a little later. So now it's time to actually hack shit, which is why you guys are here. So we're going to start with C-SERF. So I found the first instance of C-SERF that I found was on the SIS tool reboot, get endpoint. Something to mention here is that state-changing get requests, as I mentioned previously, are inherently susceptible to C-SERF. This, again, works because of the lack of empty C-SERF tokens and other anti-C-SERF protections, but, for example, if an attacker used this payload, an image source payload, and successfully socially engineered the end user to run this, then the router would reboot. And if the attacker found a way to persistently send this to the router and persistently get to the end user and persistently get the end user to submit this request, you would have persistent denial of service. The second phone attack that we're going to talk about is XSS or cross-expressing. So I was really prepared to go all out and use body tags and image tags and figure out a complicated payload to get this to work because it was very determined to get XSS working. I ended up just using a really basic script tag and that, too, on the Wi-Fi names. I was kind of disappointed, but it's okay. I mean, efficiency is good. So here, I'm just using this to output and display the document cookie that you can kind of see here. 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. So first of all, it's good to pay attention that the router is using MD5 hashes, which is also really easy to crack. And there's tons of software out there such as hash pad and John the Ripper. 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. 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 attack have really low severity. However, because we found CSERF, we can change this and increase the severity by training XSS with CSERF. And you could use a payload like this. So what this does, kind of hard to see here, but all this does is it sends the document of you, which as we know is a password to the attacker, aka me. Okay, so the next thing to look at since we've gone through the web interface is to start parsing the firmware. So as you remember from the recon section, this is the first instance of the Deuces and CMD command. So we found this in the form set USB on load function and the HPPD binary file on variable v2, which was device name. So our next logical conclusion would be to look for list endpoint in the web interface since we have access to web interface, which is what we do. And we come across this endpoint and as you can see, there's the device name. So here we're just gonna do a simple reboot command and the device reboots, nothing much to see here. But as you can tell, this is a authenticated request, which means that for this RCE to work, use the attacker needs to be authenticated. So we're going to increase the severity here by training this with CSERF again. So if the attacker is able to successfully social engineer the end user, we can get this to reboot and we basically, or well, reboot is a very simple thing, but we basically have RCE here authenticated. So as I kept parsing the firmware I'm playing around, poking around, I came across this string in the Tendo login binary file. So because it was the Tendo login binary file, I figured I have to use it to log into something. So, and since I knew that town that was running on the device, I tried running this on the device. Okay, by the way, this is the MD5 hash for fired up, like legit just fired up. So here I talented into the device and use fired up and I have persistent shell access to the device, which is one of the things that we want when my goal has been achieved. Again, as so, as I mentioned, we found another instance of due system CMD. So this one was in the Tendo town that function in the HTTP binary file. And as you can see here, this is on variable B3, which was land.ip. 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. So what we're going to do is we're going to figure out how to set the value of land.ip to something that will get us remote code execution. So you go little below this, you know, function. There's a command called CFM, which you can see here. 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. 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. 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 layers will be read only. So as you can see here, the trash file doesn't exist. And something to note here is that for this to work, you want the router to reboot first. So like it'll get executed once you actually telnet into the device. So until you telnet into the device, this command won't work. So that's why the trash file doesn't already exist. So what we're going to do is I've rebooted device and then we telnet back in. And once we see it in the temp, you can see that the trash file has been created. That's giving us, you know, an RCE. Okay, so now it's time for the live-ish demo. So now to the first demo, I hope to show you guys a small glimpse in the kind of damage you can do with Brutio Axis. And we will be demonstrating this through telnet. So since the router is an embedded device, we want to see where our stuff is stored. In this case, basically the non-volatile memory, which is the flash memory. So in general in embedded systems, you can usually find MTBs, which are memory technology devices. And these are device files created in Linux to interact with flash memory. So a good way to see this is to figure out first how they are being partitioned in actual device memory. So we will be doing this by seeding into the PROC folder and outputting the contents of the MTD file. What's interesting to note here is the MTD6 block partition and the MTD7 block partition, where the six is CFM backup and the seventh is CFM. 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 parameter in one of these block partitions. So now we will go into the dev folder. So we will first display the contents of the MTD6 block partition, which is the CFM backup partition. The first parameter that pops out is the 2G Wi-Fi password. And as we keep scrolling up, we can see a lot of other interesting parameters that we could potentially play around with or observe. But if we keep scrolling up, we find the sys.usrpass parameter, which as we know from previous results, consists of the MD5 hash of mouse. And now we're going to output the contents of the MTD7 block. So as we can see, the Wi-Fi password is obviously still the same. Also by the way, this is the CFM partition. But now when we go to the sys.usrpass parameter, the value is slightly different. And this is the MD5 hash of mouse 2. So a little bit of backstory here. I originally set the password of the admin console to be mouse 2, and then later on it changed it to mouse. So what's interesting is that the backup, the CFM backup partition stores the actual password that's being used on the admin console, aka mouse. And the CFM partition stores the most recent previously used password. So now we basically have access to the router's Wi-Fi passwords, both 2G and 5G. And we also have access to the user's admin console password, among other interesting information. Now, although this information is certainly fun, it would be definitely way cooler if we could change this. So now our next goal is to figure out how to change, say, either the Wi-Fi password or the admin console password so that we're the only people who have access to it and their OG user isn't able to access either their admin console or their router's Wi-Fi. What we're gonna do is we're gonna use a similar method to how we change the value for the LAN.IP parameter where we use CFM set. So here we're gonna use CFM set sys.usrpass and we will be changing it to the mouse is alive. So a quick note here, while analyzing hardware or software, it's important to understand how the system is doing things. 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. 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. So now we will set this. And again, important to note that you have to reboot for this to actually take into effect. Once the router reboots, we will try logging in onto the admin console with our new password. Okay, so now that the router has rebooted, we will log in with the mouse is alive and boom, we're in. So for the second demo in this talk, we are going to find another way to gain persistent access to the device. Of course, we can always tell them that into the router. I think also this is a good place to mention that Panda has not released any updated firmware. So as long as the AC-1900 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 Fire.pick-in access to the router. But come on, that's still basic. 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. So when we start, the first thing to do is to check if you can download files onto the router. The best way to do that is to check if Wget is available on the embedded system that the device is using. So when we type Wget here, we can see 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. And we can obviously see that Wget also exists. So this makes our life so much easier. I've already set up a reverse shell that connects to port 8123. So here I'm going to serve it. I will be using that tab to listen on port 8123 for incoming connection. 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. Okay, as we can see, the connection has been achieved and we have access to the device. But the first question to ask is, is this persistent? And we kind of know that it isn't, but a good way to check is by, you know, rebooting the router. What happens when the router reboots? But obviously what we're expecting is that we won't find the shell in the comp folder because it's not persistent. And obviously this is what happens. So now what we're going to do is we're going to see if we can use the RCE to change this. So we're going to first go ahead and connect catch to 8123 and start listening for incoming connection so that we don't accidentally run our script and forget to connect up. I'm going to make a new batch script here called sizzle where we're going to use the RCE in LAN.IP. So basically we're going to do a CFM set, LAN.IP, and then run the same commands that we ran initially. So we're going to CDS attempt, download the shell, change the permissions and run the shell. Something really important to note here is that you want to make sure you actually include the actual LAN.IP address in the beginning when you're setting LAN.IP. Otherwise what will happen is if you remember during the actual RCE, it is running Talmud at the LAN.IP address. So if you don't do that, first of all, A, your router won't work properly and B won't be able to actually Talmud into the device because there's nowhere to Talmud to. 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. Since anyways, we're going to be running the script and because we know that LAN.IP isn't going to actually run until we reboot it. And obviously when we're running the script, we might as well have our port connect back to the router. 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. So once we've created the script, it's probably still being served on our server and we're going to go ahead and download our sizzle script and we will change the permission and go ahead and run it. So our connection has been received and yeah, there's nothing to see detail, but when we list out our files, this is obviously all the files in the temp folder. But is this persistent? And this is something that we still want to check. So we would think it's persistent and hopefully because of RCE, it should, everything should work according to plan, but it's still good to check this. So we're going to go ahead and reboot. Before we reboot, this is something that I kind of dug up on a little bit when I was initially testing this out. 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. But everything in the Lambda IP gets executed as soon as the router starts up. So what I initially was doing when I was netcadding is that I was netcadding too late after the router had already started up. So that my netcat listener was missing the connection. So that's why we're going to go ahead and first make netcat listen on port A123 before we actually reboot the router. So now that it's listening, we can go ahead and reboot the device and wait for it to reboot. And so as soon as it starts up, we have access to the device because everything that is in there wants to achieve in life. Cool, so hopefully you guys had fun with the live-ish demo. And now that we've talked about how you can actually exploit the device, we're going to talk about responsible disclosure. So the thing with responsible disclosure is before you can actually apply to CDs, it's good to talk to a manufacturer and see if you can get things fixed. But other people can't do the same with what you did. So this is what responsible disclosure should actually look like. So ideally I would initially contact Tenda and they would reply to me within 45 days. We would talk about creation, see if they need any extra information from me, and then hopefully I would get free swag. And then we'd go move on to public disclosure and I would apply for CDs. What ended up happening was that January 2nd, I made my first initial vendor contact to Tenda. They go to Sydney. January 17th, I did my second vendor contact. I think they checked my email. Oh yeah, by the way, I obviously tracked my email. So I think they checked my email January 18th at about 8 a.m. PST. And I was like, why are you ghosting me, bro? But it's okay, I'm so used to it by now. So July 10th, I got tired of waiting and I decided to write my blog and apply for CDs. This is something that you guys should look out for when you actually start researching and move on to the responsible disclosure process. Try to get free swag. So the next part and the last part of my presentation is a short call to action. So this was the Zoomer's Guide to Hacking Shit. These are a couple of resources that can get you started in your research career. This is the QR code for my slides. So if you guys wanna check out the links, then this is a good place to get started. The first is linked to my blog, which has a little more details on the actual walkthroughs of each vulnerability. The next is the AC-15 firmware version 15.03.05.19. 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, but it still exists on the US site. So if you guys wanna play around with it, I definitely encourage you to do so. The next is a minor link, best place to get started with checking out old CDs and then Verb Suite and Endmap. If you guys don't already have this, I'd approve great resource for this assembly code and then there's a short, more resources link. So that was the Zoomers Guide to Hacking Shit and the Kicking Devices and Taking CVPs. I will be joining the Discord channel for extra questions.