OSM-S Logo

IP Camera Security Horror

Would you like to buy a nice (and cheap) wireless surveillance camera to monitor your entrance or other areas of your property? That was exactly what I wanted and after doing some research I found hundreds of offers for wireless cameras with Wi-Fi, SD-Card Storage, Pan & Tilt functionality and much more between 20 and 60 Euros. These are sold through various websites and shops, most of them look quite similar and also offer more or less the same functionality. I randomly picked a model with the features I required and ordered it online. About 3 weeks later the package arrived, but while waiting for it I rethought the whole idea of buying security equipment from an unknown manufacturer called "e-scam" and planned for a small review before really putting it to use.

Doing some research online showed that the security standard for these types of devices are very low in general and especially unknown and smaller brands reuse software and code from other manufacturers. Some camera models are sold under multiple different brands and model names but share nearly the same hard- and software and therefore also the same vulnerabilities. Researchers around the globe have already done a great job in identifying various critical vulnerabilities including backdoor accounts, remote code execution and authentication bypasses so I decided to only invest a couple of hours to see if I wanted to use this camera in my home network.

After the usual unpacking, I did not plug the camera into my home network but used an isolated and fully monitored test network so I could analyze and test the camera without the risk of compromising my home network. The results of a couple of hours of security analysis where shocking and led to my decision of not installing the camera, not even in an isolated network. Here are some of the highlights of the analysis that I carried out:

  • Requires Internet Explorer with a Custom Version of ActiveX
  • Unencrypted Transmission of Sensitive Data
  • Backdoor Account
  • (Remote) Password Reset Tool
  • Cloud Services

Internet Explorer with a Custom Version of Adobe ActiveX

First things first, after plugging in the power and network cables I wanted to check the functionality and configuration options of the camera. The extensive manual tells you to use your web browser to access the admin webpage of the camera to setup and watch the video streams so I entered the URL into my web browser. What I got back was a non-functional login screen with a link to a Windows executable file. I checked the manual again and found that only Microsoft Internet Explorer was supported and ActiveX Support was required. So, I fired up a Virtual Machine running Windows and tried with the latest Versions of Internet Explorer and ActiveX without success. After wasting about an hour of disabling all security settings there are and installing the custom ActiveX plugin as prescribed on the login page I finally was able to log in and start the ActiveX-based application to configure the camera. This was really bad news for me. The fact that I would have to install Microsoft Windows, Internet Explorer and some dodgy ActiveX add-on, then disable most of the security functions disqualified the camera from further use already.

Unencrypted Transmission of Passwords

If I can’t make use of the camera, why not have some more fun playing with it? I checked for open ports and services running on the device and captured the in- and outgoing traffic to see what was actually going on behind the scenes. Wireshark showed traffic between my test computer and the camera on TCP port 34567 while using the web interface of the camera and I found the content to contain unencrypted control messages including the login username and password.

Password transmitted in plaintext
Password transmitted in plaintext

Everybody on the same network could sniff the traffic, extract usernames and passwords and use the same channel to control and reconfigure the security camera. Not ideal, especially considering that plaintext protocols like Telnet (developed in 1969) were practically replaced in favor of secure protocols (e.g. SSH released 1995) about 20 years ago.

Apart from the traffic on this control port, web traffic is also not encrypted and plaintext username and password are not only transmitted via port 34567 but also via HTTP for the login screen and as parameters in the RTSP requests.

HTTP Login POST
HTTP Login POST

Backdoor Account

After looking at the traffic I fired up nmap to see if there were any other services exposed on the device, apart from the ports for the web interface (HTTP), streaming (RTSP) and the control socket discovered previously.

PORT STATE SERVICE
80/tcp open http
554/tcp open rtsp
9527/tcp open unknown
9530/tcp open unknown
34567/tcp open unknown

There are two additional ports, which seem to be used for non-standard services, port 9527 and 9530. Both accepted connections and seemed to talk plaintext so I connected to the first one and saw something that looked like debug output of the camera software. Hitting enter a few times got me to a login prompt which accepted the admin credentials that I configured previously. After logging in I realized this was not busybox or similar but some type of debug interface that allowed configuration and some other actions to be triggered. The help screen showed what actions could be triggered, the most interesting being “shell”, as I wanted root access to the cameras operating system.

admin$ help
----------------------Console Commands----------------------------
232 Comm dump
485Pro 485 Protocol!
ability Net Ability Utility!
ad AD debug interface!
alarm Alarm status!
bitrate Dump BitRate infomation!
cfg Config Help Utility!
cloudupgrade CloudUpgrade console utility!
comm Comm Input String
consumAlarm consumer alarm device
encode Encode commands!
front front board utility!
fs Fs debug interface!
heap Dump heap status!
help Try help!
infoframe InfoFrame Console Utility!
log Log utility!
magic magic tools!
netitf NetInterFace Dump!
netm NetManager Dump!
packet Packet usage!
ptz ptz dump!
quit Quit!
reboot Reboot the system!
record Record console utility!
rtp RTP Dump!
shell Linux shell prompt!
shutdown Shutdown the system!
snap Snap Console Utility!
thread Dump application threads!
time Set SystemTime!
timer Dump application timers!
upgrade Upgrade utility!
user Account Information!
ver version info!
xmcloud XmCloud Dump!
To see details, please use 'cmd -h'

The shell command allowed execution of any command (who might have thought so), but more important executed all strings as root which was exactly what I was looking for. I used telnet to open another port on the device allowing me to connect directly to the operating system shell as root.

/bin/busybox telnetd -l/bin/sh -p 9090

I logged in and extracted the accounts and password hashes. No real surprises there except that the root account, which seems to be the same for all cameras using the same firmware could be used to log in. Nevertheless, there was no corresponding service active that would allow usage of the account, my assumption was that after a couple of instances where these default root accounts were used to spread malware and “recruit” new bots for huge IoT botnets the related services are now disabled by default in the latest firmware.

(Remote) Password Reset Tool

The fact that there was an active root account on the device that would not really be required for normal operation of the camera kept me thinking. I browsed the support pages for camera model and found an interesting piece of software: “Password Reset Tool: this software is applied for resetting camera”. I started the binary and the only input required was the IP address which I entered and nothing happened. So, I analyzed the binary and found that the only thing this was doing was to connect to the IP, log in using the default root account and change the user accounts to their defaults.

Really? This means I can reset and own any camera by only entering their IP? Well, not in my case as with the firmware installed on my camera the related service was disabled by default. Nevertheless, this might still be an issue for all the models using the older firmware or different vendor configurations.

Cloud Services

When sniffing the cameras network communication, I already saw that it was trying to talk to all kinds of update and cloud servers and I wanted to see if I could reduce this unwanted outbound traffic. As you probably would have guessed, as with most of the IoT and Cloud connected devices nowadays this turned out to be an impossible task. I basically turned off all features including auto-update, cloud connect and others but the device kept talking to various servers including secu100.net and servers registered to AliSoft (part of the Alibaba Group).

All of the traffic going back and forth was unencrypted and the communication really did not look very sophisticated (more like an old command and control protocol for botnets). Even if I would trust the cloud service owners, attackers could easily inject data or extract sensitive information from the communication.

Conclusion

I’m sure the little problems discovered in an afternoon of very rudimentary analysis are just a few of the existing ones and the risk of using this camera or similar models is much higher than that. I would really not recommend using these types of IP cameras at all. If you really need to use them, I would suggest you isolate them in a separated network without any internet connectivity and do not monitor any sensitive areas.

2 responses

  1. Ah, they fixed the ‘shell’ command, in the previous versions it just crashed the connection.
    That version did still have telnet open, so the password reset tool worked fine, as did root login via telnet.

    I actually use these camera’s (on a isolated network) and as for being a camera they are fine.
    As for security, I’ve seen worse camera’s (e.g. accepting GET ../../../../etc/passwd via HTTP).

    An isolated network is a must, especially since some camera’s are really extreme with ‘call-home’ functions.
    One haunting example was that if someone installs a camera in their home, their internet provider thoughlessly provide a modem with UPNP default on, the camera also has UPNP default enabled and suddenly the web configuration is accessible on the public ip address…

    I also worry about the software quality of IoT devices, until there is a requirement to fix it I’m afraid not much will happen.

    1. Yes, looks like some vendors just disabled telnet and fixed the shell command to still be able to execute commands on operating system level.

      Totally agree, I’ve also seen worse but that was years ago. I thought in the last 2-3 years security must have improved in this area but learned that consumers and industry just do not care enough to prevent these things from happening.

      Considering the huge impact of security implemented in IoT on privacy (and other) aspects I would expect governments to react to the threat on individuals by mandating security certifications before any product launch. You cannot buy electronics or cars that have not been tested for safety, but you can buy electronics that were never tested for security… weird, isn’t it?

Leave a Reply

Your email address will not be published. Required fields are marked *

Get a Quote!