Top 10 IP Camera Vulnerabilities

Dear all,

I am a researcher in cyber security. I'm currently exploring top 10 security issues with Home or NVR based IP cameras.(I 'm using HiK vision NVR with Hik vision IP cameas + other brand cameras)

A quick search on IPVM leads to the Black Hat 2013 video. It mainly uses binary code analysis and clever sysadmin skills.

http://ipvm.com/forums/video-surveillance/topics/network-camera-security

Of course, I learned a few things from the above.
Question - To make a truly Hollywood style attack as the above video claims, how to mask the image with time stamp present ? (the video masks only the image; No time stamp is present in the demo video). That too, time stamp font colour changes when light change detected; how to achieve that?

In my opinion, if the above hack is achieved to the proper effect, it would definitely be one of the top vulnerabilities with IP Cameras.

Thanks and Regards.


And we are to just take you at your word that you are a white hat hacktivist, being undisclosed and all?

I checked his identity and validated that he is a researcher. Thanks.

Thanks John! I didn't want to help black hat hackers make my job harder! =)

UD1,

If you are looking for an easy target, Dahua has the most gaping holes in security that we've seen. They STILL are using admin/admin for ONVIF connections. No matter how hard you try to lock down their cameras, you can still access them via ONVIF Manager using default creds.

Question - To make a truly Hollywood style attack as the above video claims, how to mask the image with time stamp present ? (the video masks only the image; No time stamp is present in the demo video). That too, time stamp font colour changes when light change detected; how to achieve that?

If you're doing a planned attack and know a little bit about the camera beforehand you could likely install a pre-compiled version of Image Magick to handle encoding a dynamic timestamp on top of a static image.

There's a ton of good Image Magick examples on this site.

To take it a step further, you could download binwalk, decompile a firmware image for the camera, add in your custom IM build and timestamp manipulator and then upload a new firmware payload to the camera. While you're at it you could add a custom .cgi script on the camera that when called flips the camera from "Live" mode to "Fake Stream mode". It could even automatically take a static image from the camera at time of activation.

All this considered, I'm not sure I agree with this statement:

In my opinion, if the above hack is achieved to the proper effect, it would definitely be one of the top vulnerabilities with IP Cameras.

Camera-generated timestamps seem to mostly be used on lower-end systems with simple NVR's like the Hik unit you're using. These systems are less likely to be used in an environment that would have anything worth going to the extreme of spoofing a camera over.

Higher-end systems tend to use a VMS-generated timestamp because it's easier to keep all cameras in sync, and also because sometimes the camera network is so locked down there isn't even access to an NTP server.

Looking at it from a different angle, the more critical systems may be even easier to spoof because they're not expecting any dynamic image overlay on the cameras video stream.

...you could likely install a pre-compiled version of Image Magick to handle encoding a dynamic timestamp on top of a static image.

I think you might find it difficult to install Image Magick on an embedded device, since, IMHO, all the superfluous (from the cameras point of view), libraries are usually absent, as well as many standard utilities. In addition the root filesystem is often Read-only in the places you typically need to add, e.g /lib /bin /etc etc.

Maybe there is a pre-compiled statically linked executable for the cameras target architecture, though these tend to be big as well and not readily available for the many combinations.

Have you used Image Magick on a embedded device? I gave up trying to make it work on a Micro-tek wireless router, though you probably could make it work eventually by pairing down the functionality to what you absolutely need.

In my opinion, if the above hack is achieved to the proper effect, it would definitely be one of the top vulnerabilities with IP Cameras.

Agree with you this is not a big deal, as it requires access to the network AND the camera just to start. In that situation it's anything a hacker wants...

Have you used Image Magick on a embedded device?

Yes, but nothing as "embedded" as a Hikua camera. I installed it on another camera that had a lot more resources and storage.

Considering that the camera already had the ability to embed time-stamps in the image stream you might find that all the libraries and executables you need are already in the camera image in some fashion. Surely in something more lightweight than IM.

If I was planning an attack of this nature and truly had to install a lot of things I'd probably go the custom firmware build route. As long as the image was totally bloated that would be more reliable (IMO) than loading ad-hoc stuff even pre-built. You also wouldn't have the RO filesystem issues.

A custom firmware would require a reboot that interrupted the cameras stream, but switching it from live stream to serving static images would mostly likely have a similar effect. (note: in the demo he's using a browser to view an mjpeg video stream, which isn't very realistic of a common modern use case). You'd have to coordinate the firmware update at a time where a reboot/video loss was less likely to raise suspicions.

Yes, but nothing as "embedded" as a Hikua camera...

One of these days a new member is going to start a discussion titled "Looking for Information on Hikua..."

Higher-end systems tend to use a VMS-generated timestamp because it's easier to keep all cameras in sync, and also because sometimes the camera network is so locked down there isn't even access to an NTP server.

Agree, that higher end systems use VMS generated timestamp, but disagree that lack of access to an external NTP server necessarily prevents the camera from burning an accurate stamp, as the cameras normally can be set to sync to VMS time, while still remaining isolated. At least in the systems I've seen.

@John, Thanks John for your clarification. Gradually, i too realizing not all people are in cyber space white hat.

@Brian: Got some useful input from your reply. but my first thought is, instead of camera ( which is already installed in wall or other place and not easy reach it). But VMS software on NVR seems more attractive a) it is powerful linux machine b) access to all the camera, including a where i wish to manipulate the video stream.

>>browser to view an mjpeg video stream, which isn't very realistic of a common modern use case

Environment like small office and remote viewing over company use LAN or remote viewing, browser is good choice. Right?

So realistic next step, look into Hikvison NVR firmware flaws or getting root access etc. Any thoughts?

Cheers to all :)

Sure the NVR is better, and since the NVR itself has the ability to burn timestamp as well, you could possibly do it all just by figuring out everything that is available on a particular manufacturers NVR.

Again, if you are root on the target camera/NVR, there is really nothing you can't accomplish, given enough time. But it might take a lot of it, and would be different for different mfrs...

Related: Should I Hack 10,000 Dahua Cameras?

For what you're proposing the NVR is probably a better attack point. You exploit that, and you can theoretically manipulate all the camera feeds from a single source. If you're going to load/install other software like ImageMagick, the NVR would likely have a lot more processing and storage resources for running additional packages.

For an NVR a browser is the likely viewer, though sometimes users will also hook a keyboard and mouse up to the NVR and connect a monitor to the HDMI output. This probably doesn't matter, since you are theoretically manipulating the core images that are served to any client.

My comment about the browser in regards to the other thread was that a remote NVR or VMS would, in a modern system, be pulling an RTSP stream from the camera. The browser is more for tech/setup/casual use on the camera directly. So altering what image is served only to the browser UI of a camera is much much less significant than adjusting the image stream sent over via RTSP. For the NVR the browser is a more common interface, so an exploit that affects the browser UI there is more impactful.

Also, it's good to note that some (most?) NVRs have a built in firewall, meaning the cameras aren't exposed. The NVR will be your only internet facing host. You won't be able to see the cameras, unless you are the NVR.