Com un encaminador barat de Temu va acabar donant accés root

One of my favorite things to do is to buy weird devices and see if I can find vulnerabilities in them, you know, typically embedded devices tend to have the worst securities. So it's kind of a fun exercise in bug hunting. Now, what I want to show you today is the story of how I found a several egregious vulnerabilities. And this device here on T-Moo, you know, it's kind of fun, go on T-Moo, that $5 device, and you see what you can do. I want to highlight here that this not only was $30, and now it's only $5, 84% savings. But also, it is the number one best-selling item on T-Moo in Wi-Fi networking with over 100,000 souls. So from a general security of the world perspective, not a great place to be, in this video we're going to go into how I took the device apart, open the firmware and found some pretty egregious issues. And watch, as my hair grows and I change my shirt. So when you plug in this device and you navigate to the IP address for that thing, you'll see this interface. Now, A bad habit that I typically have when I audit a new weird embedded device is I typically try to put this little one liner in here and you'll see why this is bad. So what I'm attempting here is my assumption is that it's a piece of trash embedded device and they're just passing this Wi-Fi password parameter to a system call and they're not sanitizing the input. A way that I can quickly validate that without pulling any of the firmware added of ice is by doing a reboot command injection. By putting the dollar sign in these two brackets, it's a command injection which means it'll run an arbitrary system command. If it's vulnerable, and the system command that I want to run is reboot. Now what you'll see here is I go to restart the device which is intentional right. I've set the properties of the device. I'll be we'll see here after a couple of refreshes that it does not come back to life.

What this means is I have rebooted the device in NV-RAM. I put the password of the device in NV-RAM and then every time I try to come back up it's pulling that password out from NV-RAM and triggering a vulnerability rebooting it. I have now soft brick the device. But what's good about this is actually led me to the next piece of the puzzle which helped me get the firmware out of the device on accident. Now, when I typically do this to a device, what I like to do is go to the device and hold the reset button. If you hold it for long enough, what that typically does is it tells the device, hey, I want to reset to factory settings. And that will typically erase the malicious and viewgram that I put in there, and it should undo the soft brick that I did. When I was doing this myself, I held the reset button for 60 seconds and this popped up. Now, you will notice that the IP address here changed. I had to kind of fight with it to get it to respond to me. I had to look in wire shark to see if I was going to get any like random broadcast from a new IP address. But eventually, I got to this breed web interface that showed a fairly low-level diagnostic of the board. It looks like the build date and like the git commit of the server or the software as well as a CPU and like the firmware on the thing. But if you do a quick little Chinese to English translation here. The one thing that caught my eye as a vulnerability researcher is firmware backup. Now to me, this meant one of two things. Either I was able to upload new firmware, which is good, or I was able to download the firmware, which is even better. And luckily, if I press the programmer firmware button, I can download the entire system full.banyl. So you have done this other times for previous takes of the video.

But I'm able to download the firmware for the device, which is great. A lot of the times that you have to do is like, the solder, a chip off of the board, for example, like maybe like a flash chip like one of these, and then put it into a flash reader, maybe there's some weird like locking going on. The ability to just download the firmware automatically like this is super cool. So we can actually do now is go into our downloads here. Let's go to downloads. And we can do a little bin walk, bin walk, a recursive extraction of full two. dot bin and what we should get at a certain level is the file system for the device typically these things contain file systems. So if I go into extractions here and I go to the squash and fest route I now have the entire file system for the device. This is great. Now after resetting the device, getting it back to its normal configuration, doing it factory reset, I'm back into the device. So now the question is like, where do we go from here? We have the firmware over here on this tab and I have like the web interface on this tab. What, and when we're doing research on this thing, what do we do? Well, what I'm interested in is vulnerabilities that arise from a user sending data to a server somewhere, and they're being a vulnerability in that server. The server we have access to right now is the web server. So let's see if we can identify maybe some methods that we can use to trace in the firmware where this data is processed. Typically, I like to go to the network tab when I reload a page, I see like, are there any strings that pop out as something that may be custom or something that may be interesting? The first thing you may see very obviously pretty quickly is this post request to this protocol.csp. F name equals net option equals wizard config. There's a bunch of, it looks like custom stuff going to this protocol.csp function. So what I'm going to do now is go into the root directory and just grab around

for protocol.csp, maybe there's a binary name to this. And pretty quickly, we see that we have an Etsy-lightyproxy.com, and we can see what's going on in here. So what this means is that every request that goes to this protocol that csp, we go to an internal port 81, interesting. That's not super interesting, though, because I don't really know right now what binary binds to port 81. So let's see if there are any other strings near that are interesting. What about wizard comp? Let's see if we can copy that value into the same kind of thing. Again, we're literally just having searches for strings, because the strings, we see them in the requests, so they kind of have to exist on the system. And pretty quickly, we see the exist in two places. One, the router.js, which gets served to us and we use it to talk to the device. But more importantly, this user has been a commuOS. little communism reference in there, kind of interesting. So what we can do now is use this comm US binary. We can put it into a decompilation and analysis framework and maybe find some weird vulnerabilities. Let's try that out right now. What I've done is I've opened this comm US binary, the binary literally hosts web server on our device. I put it into Gidra. Gidra is a reverse engineering and decompilation and disassembly framework. So we kind of have two main columns here if you're new to this world. Basically here in the middle we have the assembly, the machine code that is being run on the device from this binary operates. And then on the right we have the decompilation. The decompilation is Gidra's best guess at what the C code looked like for the device. I'm assuming a little bit here to see if I can make it bigger for you guys. And so what we have to do now is figure out, okay.

Where do these parameters that are getting put into the program get parsed? How do we know what they do and can we find maybe either other hidden features like backdoors or vulnerabilities in this program that we can exploit for this device? So we can do now. It's go to the Define Strings. Let's just search for this wizard string, right? And we can see pretty quickly. Gidra has found the wizard config string right here. Now you'll notice there is a cross reference to this and it exists inside of what looks like a table. This is a table because there is a series of pointers to strings, and then after the pointer to string, there is a pointer to a function. Now it may be the case, so this is just a look-up table, if I go to the wizard string config right there, this wizard config string, I'm going to run this function. What we can do to kind of validate this assumption is go into Gidra's decompilation of it, and then maybe read what it does. We can read some of the strings inside of this. We have some function on this work mode string, some function on this win mode string, and then compare this to reality, right? If we compare this to the other, you know, like pieces of data in this request, maybe we can see if this is like what's actually going on. So as I was going through all of the available options we have, I'll be available commands that we have here. This one caught my eye. So you see this is time config, right? This is likely what we can use to configure the time of the device. But if you go into here and start to read some of the code.

You may, if you have any experience in this world, immediately see a variety of issues. So first of all, we have this statically defined user buff. I'm going to call this time buff for a reason you'll see here in a second. We take some data that likely comes out of the time variable. You'll see we have the time string here. We have to set this data to be a string for it to resolve properly, right? We have some function of time from Param 2, which is going to be likely our request. So if this is the function that we use, if this is us pulling all these little extra pieces out of this request, right? We have function equals get math. All of these parameters in URL. If that is how we assume that this is being ran, we can assume that this is pulling the time parameter out of the URL. This makes sense, right? Because the time parameter is likely what we're going to need to configure the time. This is the time comp function. Some of the name this time comp. And I'm going to call this little function here, uh, get per So we have get per amp from the request, S printf that into the time buffer date S, so we're going to set the date to our little input and then do system command on that time buffer. Now, this is a wrapper for system. So what we could assume is that this is going to properly sanitize the input, but like any good hacker we're going to test that assumption, right? So what we can do to test this is literally just write the command ourselves. So curl 192681.1 protocol.csp. It was F name equals net from that first request here. And we want to do and opt equals time, and the time is equal to just do garbage for right now. And there was some random math variable that maybe like they're bad attempt at a CSRF or like a seed. We're just going to steal that for right now.

And then the function is equal to it was get, right? I did some more reading and there's actually it does a compare on get or set and it's gonna return that and we have to actually be doing a set operation to get into this function, right? So what we can do is do set for this. I'm gonna wrap this in a single quote because I want to do a command injection at some point and I don't want to command inject myself. And you'll see that it says set error equal to zero, which means that we set the date equal to a, s, df, a, s, df. What we can do now is actually test does our command injection work. Do we have the ability to run arbitrary commands through just to use the simple reboot? And you'll see first it says error zero. And the second time, look at man hangs because the device has rebooted, right? We have turned the device on and off. And now we can no longer connect to the device. So we can run. arbitrary commands on this device, but by that's not cool. That's not cool enough. We want to get a shell on this device. I want to have access to this device via the command line. So what can we do? So going back to our firmware image here, we can see all of the binaries that are on the device. You'll see pretty quickly that we have the lovely Telnet D. So user Sbin Telnet D is a binary that we can use to basically run any other binary on any other port, right? It's something there are no firewall rules in place.

And so what we can do to mess with that guy is first of all, I got to reset my network interface. And then now we can update our exploit to actually set up the right things. What I want to do is user Sbin, Telnet D. So first of all, we're putting this IFS separated and to emulate a space. I'm going to buy a few sometimes in HTTP, the spaces will get escaped weirdly. I'm going to do dash P, IFS, on port, 4, 4, 4, 4, 4. And then we want to set the login binary to be bin. Ash, I believe is the other shell that we have. So now if I do NetCat, 19168, 111, 1444, I don't have a shell. Okay, let's try again. Oh, one. Before we do that though, I want to get a little more insight into what's actually going on in the device. Like, what does a process list? What does the environment look like? Luckily we have command execution on the device and we can run those commands. There's just nowhere to really put that data. Well, sort of. If we actually go to the file system here. We're going to go to the config file for EtsyLighty. We're going to cat the LADY config. You'll see that we're actually serving data. from the web directory for this device. Well, there are actually two instances running of this. We'll see that we have one of them is a rightable folder that's called slash web. So let's see if I can find it here. Do this and then grab web for a quick. So server document route for this instance of light is called slash web. But we can actually do now is run this cute little thing where we do PS. And we just take the process list and write it to web slash he he. And because that's the document route for our server, now we can just curl.

He and Bada Beng Bada Boom, we get the process list. So we can see a bunch of stuff going on. We can see that we have the lady running with that instance of the config that gives us access to the web's folder. We have a drop bear server. We have talent that running. But I want to run though, it's my own version of the Telnet server. I want to get in there and I want to run my Telnet server to give me a shell on device. Now, after a while, I was messing with this curl command that uses the command injection to run TalnetD and we'll tell that D you can specify a port number and a login program to use in place of bin login. And if you can just set bin SH, you can use that as basically a bind shell. Now, the problem is I had a couple issues where it would run, but it didn't actually run the command. I think something is either wrong with TalnetD where it doesn't allow for IFS or there's some issue with this. But what I did find after a little bit of searching is a nice little program on the device. That's called slash webs slash CGI bin slash upload that CGI, which is what you're using to actually upload a temporary piece of firmware before you do a firmware update on the device. The reason I know this, if I'm doing a simple strings on the device or on the upload that CGI, you'll see that it writes the file out to temp temp firmware. And so you can actually use a curl to do a file upload using the exact process to use this multi-part form data. by doing file equals at and then the name of the file, right? So you can literally do that and point it to that URL and in doing that you will get upload.cgi to ingest to script and put it on temp firmware. And what you can actually see here is if we do a LS of temp and we get hee hee.

You will see that this temp firmware file actually exists now is now on the device, which is crazy. So now all we have to do is you a little bit of a Commod plus X to make the file executable. We will come on plus exit and we'll do just the temp firmware run. We're gonna run the temp firmware file which has a script. Oh, I didn't show you the script. Yeah, the script that I wrote by the way is script.s.h which literally just enables a tell-in-the-d server as I wanted to run right. So it runs a script as bin-ash and it runs user s-bin-tell-that-d bin-ash port-4444. And you can see this all works together if we simply just go here and do a little net cat, one, nine, two, one, six, eight, one, one, one, four, four, four, four, about a Bing, about a boom, we're root baby. This is VR guys. This is the world of acquiring weird little devices off of T-Moo, taking them apart and seeing what issues we can find. Let's talk, responsible disclosure, right? I have tried very hard to identify what... Company makes this device I cannot idea one so this is a bug that I could not find anyone to tell about so now I'm telling you guys okay awesome Alright guys if you enjoyed this video, go check out stacks mash. It's my community where we're right teach people how to do stuff like this to not only figure out how to hack how to make the world a safer place but software security and if you like this channel then hit hit that sub button over there. It's right so it's down there somewhere We'll see you in the next one take care. Goodbye