More information about TP-Link backdoor

During the analysis of this TP-Link backdoor, I found other issues, which can be handy when analyzing other devices. finally the following path leads to remote root exec (useful for debugging purposes ). let's see.

The router allows for ftp connections. But the ftp session is somehow chrooted (ie. one can access only ftp root and USB shared directories ):

Standard ftp connection

Let's try a little trick now. After plugging a USB flash drive into the router we can share a folder from the USB to be available on FTP:

 

Folder sharing

By clicking 'save' I issue an HTTP request, which I can intercept in local http proxy, and modify it like this (ie. path traversal ):

Path traversal

After this I can traverse all the filesystem-also in write mode:

Path traversal-ftp

But how can I have interactive root-shell? OK, after searching/tmp directory, there is/tmp/samba/smb. conf which can be overwritten. Brief analysis of samba documentation shows gateways of executing external binary. For example:

123	Root preexec (S) This is the same as the preexec parameter t that the command is run as root. This is useful for mounting filesystems (such as CDROMs) when a connection is opened.

As you can see, this option (root preexec) apart from CDROM mounting can be used to debug routers After modification the config looks like this:

Modified smb. conf

/Tmp/szel is just a netcat binary (compiled for MIPS architecture) and uploaded by ftp (see the earlier path traversal trick). Now we can try out remote root shell:

Remote root

Interactive root is nice, but how can it help with locating issues like this? OK, let's search httpd binary for strings (httpd can be downloaded from the router-for example-using ftp ):

Here we can seeStart_art.htmlString mentioned in the original disclosure. But how does it work? Let's check what is going on the router when start_art.html is launched:

Now it's clear-192.168.0.100 is my IP address and nart. out is 777 chmoded and then executed...

Educational use only! We are also not resposible for any potential damages of the devices which are tested for this vulnerability.

-Micha unzip Sajdak (michal. sajdak <at> securitum. pl)