Old Hollywood CCTV camera hack actually works on modern security cameras

Image source – freepik.com

I bet you watched Ocean's Eleven movie and many others, where casinos or banks are robbed with an intelligent approach to spoof pictures from surveillance cameras in a different way – starting from just disruption of availability up to looping the picture with empty storage.

In the past, there was research on this topic and even some demos, but they are still presented is not the best for most readers way.

I will show you today a very easy (or almost that) way to substitute the original video stream with a spoofed one for the operator of the surveillance system.

Demo time – no time to explain!

Sorry, but there is something that I should explain.

For our research, we are going to use the most recent version of iSpy software, which is very popular, at least around small and middle-sized companies.

This software will serve as a Central Alarm Station, where the camera's video streams are coming.

As a source of an image, we are going to use a TrendNet surveillance camera. But to be honest, it doesn't matter at all because the attack is camera-agnostic in this case.

Image source – trendnet.com

So, iSpy is running on our Windows client, and the camera is connected to the same network. We can access the camera and connect it to our iSpy software to receive video-stream.

Image source – gizmodo.com

Remember hack robbers receive access to the physical infrastructure of the banks and find signal lines of security systems? They actually need only a router rack or switch box to connect their hacking Raspberry Pi there. Pretty realistic, even for some secure places.

What does the operator of CCTV see?

1. Two identical pictures from two identical streams of the camera to application.
2. You will see the difference when the time comes.

To be very specific, we will need two images from our camera in iSpy so that we can create the parallel stream in the same application.

In this case – the camera is a server, and each new video-stream windows in the application are a newly connected client. So those two streams are running independently as two parallel flows of UDP packets from camera to iSpy. This is important.

I made this demo many times for different audiences and pretty knew what kind of questions to expect, so if you have any – put them into the comments area. But I will try to cover some of them in advance.

If we are connecting to a new unknown network – we will need to discover all services and hosts within the network to find out what IP cameras and what are workstations for CCTV. There are many ways how to do this.

But even if we can't get this data from the scan itself, we can find it out in alternative ways – for instance, trying to sniff traffic between different network hosts.

The very first commands that you will need to perform could be:

sudo systemctl net.ipv4.ip_forwarding=1

Without this command, all traffic that you will intercept while sniffing will be dropped on your side and will not come to the intended target – the CCTV operator. This will be suspicious, and people will very quickly find out the reason – so, evil adversaries tactic.

As any good attacker, we want that victim to thinking that nothing happens, so we need to stay undetectable and gently forward everything we see to the original recipient – no anomalies so far.

While sniffing traffic on the network, we found a video stream between the camera and the application. How will we know about this?

There are a few indicators:

1. Communication is very intensive because of the high frame rate for CCTV. For instance, 30 frames per second in high-quality.
2. It is mostly flying through UDP protocol.
3.  If you sniff at the right time, then you will discover TCP packets with information about the video stream.

We will focus on the UDP stream because it is critical to our replay attack.

Look at the figure below. We see the source of traffic – camera, the destination of traffic – workstation with iSpy, as well as additional info, like port numbers for both applications.

This data is enough for us to filter only required network traffic for our spoofing attack.

You can see the filter in the green area. Without it, the replay attack will fail.

Now we are good to try our technique.

We will use tcpreplay application and command for this attack. It should not confuse you because it is impossible to replay TCP traffic back to the network, but possible with UDP.

After starting the command, we will not see any data about the replay rate. It will appear later, after the whole .pcap file will be played to network. In our case, we had enough packets to play 18 seconds of video back to the network.

Right after the start of the command, the operator will see the old video player instead of the original stream. Below we see two pictures with the same system as before. The first picture has only one indicator of spoof – this is date/time overlay, which is printed into the data packets, and thus images themselves. Without having this overlay, it would be impossible to say that the video stream is spoofed.

Don't forget, that both streams from the camera are running in parallel with replayed packets. Theoretically, when the UDP packets from the replay file are gone, the original stream will be accepted and shown as a camera image.

Practically it is a little bit more complicated, but the result is expected – the camera will deliver equal images to both streams, and they will be equal on operator screens.

This demo is a part of a training exercise, which is provided by the Institute for Security and Safety.

What is the outcome of this research?

The problem today is the same as ten years ago – many devices as video cameras are configured by default to provide more performance rather than security. This creates tons of vulnerabilities and makes hackers life much easier and successful rate of attacks higher than it should be.

It is important to understand a few inputs, which are very different for other IT systems:

1. The CCTV system usually doesn’t have any intrusion detection system implemented. Many devices in sub-net for CCTV make it difficult to monitor that network for intrusion detection, especially on the level of packets.
2. The cameras are smart but still dumb. Modern security cameras can analyze pictures on the fly and even run games on Linux operating system but are still not capable of detecting and notifying about ARP spoofing attacks, which is a very clear indicator of compromise.
3. Operators of CCTV don't know how to recognize a cyber attack. 99% of people watching surveillance cameras on the screens don't have any ideas of what is happening behind screens, thus not capable of detecting the ongoing attack.
4. The default configuration of cameras is focused on the delivery of 2k, 4k, or 8k pictures, which means using a UDP connection for video transfer instead of TCP. This is actually a global problem. Almost any stream today will be broadcast to subscribers without creating separate connections to send a new portion of a stream. That is a fine approach for entertainment but a completely wrong one for security systems.

How to protect yourself from Hollywood-like spoofing?

To give the best answer to this question, we need to know all possible inputs, which is impossible in our simulated scenario. But we can identify a few best practices associated with the use of security surveillance systems without the protection of the security system itself.

1. Use a separate sub-network for CCTV, where you can monitor traffic running around that sub-network. This will give you the opportunity to detect the early stages of preparation for spoofing attacks and mitigate the more disastrous consequences.
2. Assess risk and trade-off of using UDP and TCP communication. While stateless UDP communication provides better performance, it is creating additional challenges, which can cost you more than the advantage of picture quality.
3. Keep all your software updated. This cannot be the most effective measure to protect yourself, but sometimes it plays a crucial role in the incident. It is better to be prepared for that crucial moment and mitigate any additional risks.

Conclusion

This is one of the unique cases when an actual attack can be even much more spectacular than Hollywood analogs, and itself is not more complicated than script-kiddie spoofing.

Stay tuned and watch around!

Editor-in-Chief

Dmytro Cherkashyn

Being a passionate security expert from Ukraine, Dmytro has passed through various security domains for the last 12 years, starting with the physical security of nuclear facilities and coming to operational technology cybersecurity for critical infrastructure in Germany.