IP Camera Finder
When my daughter was born I decided to get an IP camera to put over her cot so I could keep an eye on her at night. The one I chose was from Storage Options. Looking through the info that comes with it I spotted this line:
The software supplied manages the set-up process for you. Includes support for dynamic IP address and DDNS and with wireless connectivity you don't have to worry about running cables around your home or office.
There are also mentions of things like "automatic registration" and "easy remote monitoring", I didn't like the sound of these so I decided to dig a little deeper.
The device will run over a wired or wireless network so I set it up so all traffic passed through my laptop, started Wireshark and powered it on. Two things stood out, UPnP traffic heading to my router and web traffic to the domain ipcam.hk. The UPnP traffic was attempting to get my router to open up a PAT hole through it, basically allowing the outside world full access to the camera's web interface - not good! Dissecting the web traffic, that turned out to be the DDNS setup.
The device comes with a unique 6 character code which the manual says can be used for external viewing, for example if my code is abcdef then it says to browse to http://abcdef.ipcam.hk to see my camera. The way this is set up with the DDNS is quite interesting, rather than having the subdomain return the external IP of the camera, all subdomains resolve to the ipcam.hk domain. If you browse to the subdomain the page you get does a 302 redirect to the IP of the camera. This is a neat idea because the cameras use a default port of 81 rather than the normal 80 and so users would have to know to add :81 to their URL which would go against the ease of use they are aiming for.
So, what is wrong with this? Camera enumeration. Every camera which successfully registers with the service has its IP and port available to anyone who decides to query the service. If I want to see if a camera with code xxxxxx is registered I simply browse to xxxxxx.ipcam.hk and see where I get redirected to. If the UPnP request to that users router worked then I'll end up on the web interface for their camera. It isn't hard to request a bunch of URLs, ask HD Moore!
So I wrote a script to scan a range of codes, look at the IP returned and see if it required authentication or not. I found quite a few open cameras, most boring but a couple of fun ones.
A couple of months went by and unfortunately I didn't get time to write up all the work I'd done, I was then asked to speak at OWASP Leeds and thought it would be a perfect opportunity to release the info. I decided to get fresh data but unfortunately found that the ipcam.hk service was dead so all I had was the data I'd previously collected. I presented and pointed out that as a researcher your findings are often only valid for a short time window so should be released as soon as possible. I thought that was that and moved on.
All this was two years ago, we've now has a second kid and decided to get him a camera as well. I ended up getting a very similar one as it turns out that there are a lot of companies re-branding the same basic camera. This camera also boasted the same features as the first except this time with a different DDNS provider, tenvis.info. This time I wasn't going to let the data get away.
Armed with previous knowledge I decided to abandon my previous Ruby script and write my first nmap script in Lua. This turned out to be fairly easy and had the big advantage of having someone else worry about threading, networking and all the other underlying things that I didn't really care about. I set the script to make the HTTP request to the tenvis.info domain then parse the result. For cameras which were registered I did a HEAD request on a password protected page that should exist on the camera if it was online. This told me whether the camera existed or not and if it did whether it required authentication. It would be a fairly simple addition to check for the very guessable default credentials of "admin" with no password if I chose to.
All this was logged to a nice text file to process later.
The Results
Text is good but pictures are better and a fully interactive Google map is even better than that so I decided to throw the IP address of the cameras which I found through a geo-ip service and see what came out. Every camera I tested came back with a location. The final step was to manipulate all the data into JavaScript and see how it looked and even though I say so myself, it looked really good! See what you think...
The World
The data here comes from scans of various ranges from aaaa to zzzz and there is a total of 616 cameras dotted around the globe.
The UK
Spot the little red marker, that is a camera without password protection
Germany, Belgium and The Netherlands
A few cameras and another unprotected camera
More Info
I added a balloon popup to the markers so I could click on them and find out more about the camera.
Releasing the code and data
I had a think about releasing the code and data I've collected and decided I'm not going to. While it would be relatively easy for someone with some coding skills to reproduce what I've written I want to put at least an entry level bar in place to stop people completely abusing what is a pretty large vulnerable ecosystem. I am however happy to talk to anyone in any depth about this provided I feel they can be trusted.
Conclusions
These can be split into three categories...
Users
Make sure you know what any product you put on to your network does, if you don't know how to find out then ask. That is much easier said than done I know but, if you have found your way to this blog, then you are probably have at least a passing interest in security so check out the forums and mailing lists.
If you are going to put something on the Internet, make sure that it is properly protected. Always replace default passwords and, if possible, usernames. This doesn't always help if the developers have left undocumented backdoor accounts open but at least do as much as you can.
If you have one of these cameras then check your router, see if a hole has been set up. If you don't use it then remove it, if you do then consider adding extra protection, maybe add some obscurity and move it to a high random port. My camera allows disabling of both the DDNS and UPnP features so I'd recommend doing that as well.
Developers
Think about the potential attack surface of any features you create. Adding a feature to make an end users life easier unfortunately often ends up reducing security but it should have to. In this scenario asking the user whether they would like the camera open to the entire Internet before just doing it would solve a lot of problems, I doubt most people with one of these cameras access them remotely so don't require the feature.
Forcing the user to set an administrator username and password when they first use the device would remove the problem of default accounts.
Put mitigation strategies in place for things you can't directly prevent. An example here would be to rate limit the requests to the DDNS service. A single IP does not need to be able to make over 1000 requests in an hour, detect this early and block it.
Researchers
If you do research, publish it. I'm lucky that this all came around again and I've been able to publish it otherwise it would have just been lost in source code directory somewhere.
