I Hacked This Temu Router. What I Found Should Be Illegal.

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 security. 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 several egregious vulnerabilities. And this device here on

vulnerabilities. And this device here on Teimu, you know, it's kind of fun. Go on

T-Mo, you buy a $5 device and you see what you can do. Now, I want to highlight here uh that this not only was $30 and now it's only $5. There's 84%

savings, but also it is the number one bestselling item on Teimu in Wi-Fi and networking with over a 100,000 sold. 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, opened the firmware, and found some pretty egregious issues. And watch as my hair

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 uh weird embedded device is I typically

try to put this little oneliner 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

input. A way that I can quickly validate that without pulling any of the firmware out of the device is by doing a reboot command injection by putting the dollar sign in these two brackets. It's a

command injection, which means that it'll run an arbitrary system command if it's vulnerable. And the system command

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.

Uh, but we'll see here after a couple refreshes that uh it does not come back to life. What this means is I have

to life. What this means is I have rebooted the device in NVRAM. I put the password of the device in NV RAM and then every time it tries to come back

up, it's pulling that password out from NV RAM and triggering a vulnerability, rebooting it. I have now soft bricked

rebooting it. I have now soft bricked the device. But what's good about this

the device. But what's good about this 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 VRAM 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

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 Wireshark to see if

me. I had to look in Wireshark 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

the CPU and like the firmware on the thing. But if you do a quick little uh

thing. But if you do a quick little uh Chinese to English uh translation here, the one thing that caught my eye as a vulnerability researcher is firmware backup. Now to me, this meant one of two

backup. Now to me, this meant one of two things. Either I was able to upload new

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

better. And luckily, if I press the programmer firmware button, I can download the entire system full.bin.

You'll see I've done this other times for previous takes of the video. Uh, 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 desolder a chip off the board, for example, like maybe like a 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, what we can actually do now is go into our downloads

here. Let's go to downloads and we can

here. Let's go to downloads and we can do a little bin. Binwalk uh recursive extraction of full 2.bin.

And what we should get at a certain level is the file system for the device.

Typically, these things contain file system. So, if I go into extractions

system. So, if I go into extractions here and I go to the SquashFest route, I now have the entire file system for the device. This is great. Now, after

the device. This is great. Now, after

resetting the device, getting it back to its normal configuration, doing a 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 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 there being a vulnerability in that server. The server we have access to

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 and when I reload a page, I see like are there any strings that pop out as something that may be uh 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

this protocol.csp fname equals net option equals wizard config. There's a bunch of it looks like

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 grap around for protocol.csp. Maybe there's a binary name to this. And pretty quickly we see that we have an etsy

lightyroxy.com and we could see what's going on in here. So, what this means is that every

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?

interesting. What about wizard comp?

Let's see if we can copy that value and do the same kind of thing. Again, we're

literally just doing searches for strings because the strings, we see them in the request, so they kind of have to exist on the system. And pretty quickly, we see they exist in two places. one the

router.js JS which gets served to us and we use it to talk to the device. But

more importantly this user espin commuos little little communism reference in there kind of interesting. Uh so what we can do now is use this comm binary. We

can put it into a decompilation and analysis framework and maybe find some weird vulnerabilities. Let's go try that

weird vulnerabilities. Let's go try that out right now. And what I've done is I've opened this com binary. The binary

literally hosts the web server on our device. I put it into gedra. GEDra is a

device. I put it into gedra. GEDra 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 when this binary operates. And then on the right we have the decompilation. The

decompilation is Gedra's best guess at what the C code looked like for the device. I'm zoom in a little bit here to

device. I'm zoom in a little bit here to see if I can make it bigger for you guys. And so what we have to do now is

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

they do? And can we find maybe either other hidden features like back doors or vulnerabilities in this program that we can exploit for this device? So we can do now is go to the defined strings.

Let's just search for this wizard string, right? And we can see pretty

string, right? And we can see pretty quickly Gedra 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 that this is just a lookup table. If I go to the wizard

lookup 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

function. What we can do to kind of validate this assumption is go into Gedra'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 WAN mode string, and then compare this to reality, right? If we 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, all the 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

the device. But if you go into here and start to read some of the code, you may uh if you have any experience in this world, uh immediately see a variety of issues. So first of all, we have this

issues. So first of all, we have this statically defined user buffer. I'm

going to call this uh 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

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 the 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. And this makes sense, right? Because the time parameter

sense, right? Because the time parameter is likely what we're going to need to configure the time. This is the time comp function. So I'm going to name this

comp function. So I'm going to name this time comp. And I'm going to call this

time comp. And I'm going to call this little function here uh get param.

Right? So we have get param from the request s sprintf 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 uh 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 192.16811.1 protocol.csp

protocol.csp it was um fname equals net from that first request here and we want to do and opt equals time comp and the time is

equal to let's just do garbage for right now and there was some random math variable that maybe like their bad attempt at a CSRF or like a seed. So

we're just going to steal that for right now. And then the function is equal to

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 going to return that. And we have to actually be

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

function. Right? So what we can do is do set for this. I'm going to 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 them the the date equal to asf asf. What we can do now is actually test does our command injection work? Do we have the ability

injection work? Do we have the ability to run arbitrary commands through just the use of a simple reboot? And you'll

see first it says error zero and the second time the command 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 but that's not cool. That's

device. But but 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 um our firmware image here, we can see all of the binaries that are on the device.

And you'll see pretty quickly that we have the lovely tnetd. So user espin tn netd is a binary that we can use to basically run any other binary on any

other port, right? Assuming there are no firewall rules in place. And so what we can do to uh mess with that guy is first of all I got to reset my network interface. And then now we can update

interface. And then now we can update our our exploit to actually set up the right thing. So what I want to do is

right thing. So what I want to do is user sbin tn netd. So first of all we're putting this IFS separator to to emulate a space on the device cuz sometimes uh

in HTTP the spaces will get escaped weirdly. We want to do -ps on port 444.

weirdly. We want to do -ps on port 444.

And then we want to set the um the login binary to be uh bin ash I believe is the the shell that we have. So now if I do netcat 192168

uh 1114444 I don't have a shell. Okay, let's try again. Hold on. Before we do that

again. Hold on. Before we do that though, I want to get a little more insight into what's actually going on in the device. Like what is what is the

the device. Like what is what is the process list? What does the environment

process list? What does the environment look like? Luckily, we have command

look like? Luckily, we have command execution on the device and we can run those commands. There's just nowhere to

those commands. There's just nowhere to really put that data. Well, sort of. If

we actually go to the uh the file system here, we're going to go to the config file for Etsy lighty and we're going to cat the lighty config. You'll see that

we're actually serving data from the webs directory for this device. Well,

there actually there are two instances running of this. But you'll see that we have one of them is a writable folder that's called /webs. Let's see if I can find it here. Do this and then grab webs. So server document route for this

webs. So server document route for this instance of lighty is called /webs. What

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/he hehe and because that's the document route for our server now we can

just curl he he and bada bing bada boom we get the process list so we can see a bunch of stuff going on we can see that we have the lighty running with that instance of the config that gives us

access to the webs folder we have a drop bear server we have tnet running what I want to run though is my own version of the tnet server. I want to get in there and I want to, you know, run my Tnet

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 TNETD. And with TNETD, you can specify a port number and a login program to use in place of bin

login. And if you can just set binsh,

login. And if you can just set binsh, you can use that as basically a bind shell. Now, the problem is I had a

shell. Now, the problem is I had a couple issues where it would run, but it didn't actually run the command. And I

think something is either wrong with TNETD 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 /webs/cgibin/upload.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 is by

device. The reason I know this is by doing a simple strings on the device or on the upload.ci, CGI. You'll see that it writes the file out to temp temp firmware. And so you can actually use uh

firmware. And so you can actually use uh curl to do a file upload using the exact process they use this multi-art 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

URL. And in doing that you will get upload.cgi to ingest the script and put

upload.cgi to ingest the script and put it on temp firmware. And what you can actually see here is if we do a uh ls of

um of temp and we get hehei, you will see that this temp firmware file actually exists now. It's now on the device, which is crazy. So now all we have to do is do a little bit of a a

commod plus x to make the file executable. We will commod plus exit and

executable. We will commod plus exit and we'll do just the temp firmware run.

We're going to run the temp firmware file which has a script. Oh, I didn't show you the script. Uh yeah, the script that I wrote uh by the way is uh scripts.sh, which literally just enables

scripts.sh, which literally just enables a telnet D server as I want it to run, right? So it runs a script as bin ash

right? So it runs a script as bin ash and it runs user spin tnet d b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b bin aash port 4444. And you can see this all works

4444. And you can see this all works together. If we simply just go here and

together. If we simply just go here and do a little netcat 192.16811 4444, bada bing, bada boom, we're root, baby. This

is VR, guys. This is the world of acquiring weird little devices off of Teimu, 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 ID one. So,

this is a bug that I could not find anyone to tell about. So, now I'm telling you guys. Okay, awesome. All

right, guys. If you enjoyed this, do me a favor. Go check out Stack Smash. It's

a favor. Go check out Stack Smash. It's

my community where I 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

it's down there somewhere. Uh we'll see you in the next one. Take care. Goodbye.