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

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

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

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

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

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

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

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

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

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

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.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

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

here and I go to the SquashFest 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 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

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

fname 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 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

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 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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

doing a set operation to get into this

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

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

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

our our exploit to actually set up the

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.

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

though, I want to get a little more

insight into what's actually going on in

the device. Like what is what is the

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 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

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,

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. 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

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

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

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

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

a telnet D server as I want it to run,

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

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

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.