This post originally appeared (ages ago) on my personal blog. These devices are certainly still kicking around so the information is still relevant.

A few months [now years] ago I ordered a generic IP webcam from Amazon. A COOLEAD L610WS arrived the next day. The reason behind this purchase was to act as a baby monitor for our new daughter.

Paranoid much?

There has been much discussion about the security of IoT devices such as this webcam. This even broke out of the confines of geek sites and into the mainstream press.

I knew that this device would be insecure when I purchased it. My view was that securing it was just a matter of changing the default passwords and updating the configuration — as I would do on any device I purchased.

This was not the case and the more I dug, the more fail I found.

Danger!

• This webcam is massively insecure if you just plug it in and use.
• Even if you spend some time updating passwords and configuration, it is not much better.
• The firmware and set-up do not look to have seen any form of quality control.
• By default this webcam is immediately accessible from the internet and due to some bad code, can’t be disabled.

External Access

In an attempt to make it easy for people to view the webcam from outside the confines of their home network, a number of options are typically offered by these sorts of device:

• The webcam will use a p2p system and open up ports on your router via UPnP.
• You can upload images to an FTP site.
• You can send images via email.
• The documentation will suggest opening up ports on your router to allow access.
• A dynamic domain name service (DDNS) will ensure you can always connect, even if your router changes IP.
• An even scarier alternative is that the webcam will upload images/footages to the manufacturer’s servers for you to view from their website.

My webcam offers a p2p system, a dynamic name service, FTP upload and email.

Software

Browser

Plugging in the webcam and browsing to the IP address serves me a standard HTTP authentication screen.

Note ‘Your connection to this site is not private’. This means that your user name and password are sent over the network (or internet) in cleartext and can be trivially intercepted.

After authentication, you are presented with a number of options to view your camera based on your OS/browser (IE, not IE, mobile).

The IE option offers the download of some software via a link which helpfully includes your username and password. I’d go nowhere near any software bundled with this webcam — I don’t need it and would not trust it anyway.

So far, nothing I have seen is instilling any confidence in the software. Let’s inspect the page which displays the video/image from the webcam:

That looks like commented out development code. It also betrays the default admin user and password (admin, with no password).

Configuration

I tried locking down the DDNS configuration on this device but I can’t. The option is there, but my choice is not actioned or even saved after clicking either of the mislabelled buttons.

A look at the source shows more commented out code, this time its JS.

Thanks to that code snippet, the following request would disable DDNS. I don’t trust this device though.

There is no option in the admin section to turn off the p2p option. I’d guess it probably would not have worked anyway!

The script declarations at the top of the index file reference a couple of cgi files. These are used to set variables for every configuration option for each page. Let’s take a look at them.

get_status.cgi

get_params.cgi

Highlights:

• Username and passwords for all other users.
• Network configuration, including the SSID and WiFi password.

(I’ve stripped out some consecutive variables to save some lines).

set_alias.cgi

This script is used to set the alias of the device — to give it a friendly name. I decided to pick on this particular cgi as it is simple (one value) and is displayed on most (if not all) pages outside of the admin area.

What I was looking for was a cross site scripting (XSS) vector.

Credit to Lud for beating me to it [_here](http://www.drolez.com/blog/?category=Hardware&post=jw0004-webcam)._

Now look what happens when I log in:

I expect the other forms which take text input are equally as susceptible, but are likely limited to the admin pages.

The XSS injected here is a harmless popup but it is not inconceivable that something much more malicious could be cooked up. As Lud points out, the lack of cross site request forgery (CSRF) protection could allow the users browser to be taken over.

Device

Firewall Logs

I'm going to guess the latter three servers are something to do with the p2p functionality of this webcam. I’ll maybe investigate these further with Wireshark at some point.

54.247.103.91

This looks to be a box hosted with AWS (in Ireland).

Hitting this on port 80 returns the following from a very online Apache 2.2.22 instance.

54.217.201.148

This looks to be an Ubuntu box, also hosted with AWS (in Ireland).

Port 80 gives up a default configured Apache 2.2.22 instance.

Others

• 128.138.141.172 — This is an NTP server at the University of Colorado.
• 54.245.98.57 — Another AWS box located in the US.
• 123.56.159.92 — This is a box located in Hangzhou, Zhejiang, China and is hosted by Aliyun Computing Co.

Services

Let’s see what services are running on the device. We’ll use the stalwart of network scanners, nmap.

The options used are;

• -sS — Scan TCP ports (SYN)
• -sU — Scan UDP ports
• -sV — Try and figure out what version of the service is running

Telnet

Telnet has no place on this device. It certainly shouldn't be enabled by default and I wonder why it is. Its worth noting that the username and password which is set for the web interface does not work here.

Let’s point Metasploit at this and see if we can get a login.

Metasploit is a framework for developing and executing exploit code against a remote target machine. It comes bundled with a bunch of scanners. We’ll make use of auxiliary/scanner/telnet/telnet_login.

I've presumed that the root account is going to be accessible (and not locked down by disabling its access). This presumption is based on what I have seen so far.

It took less than 3 minutes to find that ‘123456’ was the root password.

Lots of people have beat me to this!

• PenTestPartners — Hacking the IP Camera: part 1 | part 2
• Krebs on Security — This is Why People Fear the ‘Internet of Things’
• Lud’s open source corner — Wanscam JW0004 IP Webcam hacking

Conclusion

The IoT is great — you can pick up a wireless infra-red webcam for under £30. However, you get what you pay for.

• The firmware makes use of insecure technologies (telnet, FTP, no SSL on web, SMTP) which allow for data to be easily intercepted.
• The software seems to have been clobbered together without any thought for best practices, security, review or testing.
• The infrastructure the device talks to doesn't give me any confidence — a service which displays a default (Apache) page has not been configured correctly. I’d not fancy trusting it with my personal information.

It seems that these devices, which look to be essentially the same but made by different companies, all use a similar software base. This is then tweaked occasionally at the whim of the given manufacturer.

These devices are not aimed at tech-savvy individuals and most people won’t know how easily these can be exploited by inquisitive or malicious parties.

The only way I can see to safely use this webcam is to prevent the device from accessing the internet at all.

At this point my ‘Internet of Things’ device is more accurately an ‘of Things’ device.

Ghosts?

This is a question which I’d not considered when making my choice.