Ocean 11 Camera Hack Real World?

I just saw this article on gizmodo about hackers being able to tap into an ethernet cable and create a loop on the camera feed. Is this something that is a current or future risk in the real world? Can this type of hack be prevented?


Here's a whitepaper from the researchers on this. Most interestingly, the software itself has been open sourced (see the code and documentation on Github).

There are 2 key parts to this:

(1) detecting RTSP video feeds and then replacing them with manipulated outputs, excerpt:

"The camera sends its network stream over RTSP (Real Time Streaming Protocol), which uses TCP to set up the video stream, RTCP (RTP Control Protocol) over UDP for synchronization, and RTP (Real Time Protocol) over UDP to transport the H.264-encoded video. Each layer in lens parses apart incoming packets, applies any modifications, and reconstructs outgoing packets."

"In practice, video encoded with H.264 can be looped without re-encoding by concatenating the looped segment indefinitely. However, by re-encoding the stream with mpeg, an attacker can apply standard mpeg transformations to the video. For example, the attacker could loop most of the video, without modifying the corner of the frame that contains the timestamp."

(2) Tapping into a network cable, described below:

The software part is available but I am trying to figure out what the status is of the tap / hardware.

This is the most advanced / general attempt I have seen, especially the open sourcing of the software (compare to the 2009 Defcon attempt).

Anyone have thoughts on this?

I've never done the RTSP insertion part of this but the physical tap is pretty easily done. I've done it for voice and T1/PRI, but not Ethernet. But same concept, just more wires. You can do it yourself with a couple of jacks.

The tricky part for most people is skinning the cable and untwisting pairs of wire to terminate them to the tap without dropping the connection. Though to be honest, if a camera goes down for a minute and then comes back up seemingly normal and stays that way, I doubt most operators would notice anyway.

the physical tap is pretty easily done... But same concept, just more wires. You can do it yourself with a couple of jacks.

For a passive tap, that's true.

But this is more than that, this is an active injector.

An USB controlled A/B switch for ethernet essentially. It requires electronic relays to make the cut-over on all pairs with split second accuracy.

Interestingly, it sounds like it would even defeat 802.1x because 802.1x only does supplicant authentication when a new device is detected.

Not that many use 802.1x for IP cameras in the first place...

What about HTTPS? My understanding that for IP cameras, even with HTTPS enabled, the video / RTSP stream would still be unencrypted? Agree/disagree?

Also, it seems still possible to do the hack without the tap but it would require taking out the link for a short time. Yes/no?

My understanding that for IP cameras, even with HTTPS enabled, the video / RTSP stream would still be unencrypted? Agree/disagree?

It depends on what port you connect to, (e.g. 554,443). If you are still connecting to the camera via RTSP (554) then the setting won't do anything.

If however you setup the camera to tunnel RTSP thru HTTPS and make then connection to the https port, then the session will be encrypted.

RTSP tunneling thru HTTPS actually interleaves RTSP, RTCP and RTP data before being wrapped in HTTP and then all of it is encrypted using TLS.

Also, it seems still possible to do the hack without the tap but it would require taking out the link for a short time. Yes/no?

Yes, sure that makes it much easier. Assuming the hackers were skilled slammers as well, they might be able to cut the cat and terminate two rj-45s and then insert a hacked switch in under 30 seconds.

Cabling Icons go Defcon...

"If however you setup the camera to tunnel RTSP thru HTTPS and make then connection to the https port, then the session will be encrypted."

Who does that in commercial video surveillance? What manufacturers even support that?

ONVIF insists on it, if the device supports HTTPS:

5.2.1.2 RTSP over HTTP

The RTSP over HTTP/HTTPS shall be supported in order to traverse a firewall. See Section 5.1.1.4 RTP/RTSP/HTTP/TCP.

5.1.1.4 RTP/RTSP/HTTP/TCP

The data stream shall be sent via HTTP to traverse a firewall. A device shall support media transfer using RTP/RTSP/HTTP/TCP. And if a device supports TLS1.0, the data stream shall be sent or received via HTTPS to traverse a firewall, and a device shall support media transfer using RTP/RTSP/HTTPS/TCP.

ONVIF Streaming Specification

The RTSP over HTTP/HTTPS is a tunnel, IMHO.

"Insists" That's pretty strong.

They say: "shall be supported in order to traverse a firewall"

I would like to provide an acceptable answer to your question:

What about HTTPS? My understanding that for IP cameras, even with HTTPS enabled, the video / RTSP stream would still be unencrypted? Agree/disagree?

But I guess I am not certain what you are asking.

Are you saying, for instance, that connecting a https enabled camera to Milestone Corporate via HTTP Secure is not really secure because video data itself, e.g. the rtsp/rtp streams, are actually transmitted unencrypted? Or?

Yes, that is my understanding. That HTTPS encrypts the authentication / signaling but not the video stream. I do not know as it is not an area we have ever tested or even seen clear vendor comments on.

This is from a recent Milestone white paper entitled, "Ensuring end-to-end protection of video integrity"

If there is actually a concurrent, but unencrypted, rtsp/rtp stream for the video, then this paper is misleading to say the least.

I'd agree misleading, but look at what they actually say. They are careful to say "encrypted communication." They never say "encrypted video."

Paging Rodney Thayer....

In this case literally, I just emailed him. Hoping he can shed some light here.

you can't connect cameras to milestone via https. feel free to challenge that, I have a stack of milestone business cards I'd be happy to check with.

you can't connect cameras to milestone via https, feel free to challenge that...

You are hereby freely challenged. :)

Though I must warn you I may have a faded Lars Thinggaard Rookie Card kicking around somewhere.

Thank you. Not what their product management team told me last time we asked them directly. Last test I did (6-ish months ago) had three different people review the doc AND ask the vendor for clarification and nobody pointed out any evidence. I make trouble by RT'ing the FM, I also try to follow up with the vendor if there appears to be a gap (and the vendor is claiming they're talking to me...) I will follow up on this. I have no intention to make incorrect claims about a vendor. I'm quite happy to correct my info if it's wrong.

The general problem with vendors is the clueless suits who think lying to the security consultants will make the problem go away. I'm not going to be shocked if someone points out the code actually does it.

Hmm... On the Milestone forum there are quite a few people talking about wanting and trying to connect cameras via https, and tech support telling them it should work, but I don't see anyone say it's actually working now, so you may have a point..

A different question for you: You know how reckless homesumers often connect their random cameras directly to the Internet by opening port 80?

If instead you were to enable https on such a camera and punch it thru on just 443, and then view it from somewhere on the Internet (using a browser with the mfrs plug-in), would the video be encrypted then?

This is theoretically more doable on a basic system. Unmanaged switches, default camera passwords, unencrypted video.

On many mid to higher-end managed switches the switch will renegotiate the entire link if there is a connectivity drop of more than a few milliseconds. You run a big risk here of upsetting the switch and/or upsetting the VMS, causing it to detect the camera as down and then up, resulting in a full reconnect. If your device isn't able to handle the full auth part, then it will be obvious there is a problem.

A more practical approach might be to insert the device well in advance of carrying out the switchover. That way if a camera dropout becomes visible to the operator they are less likely to notice anything "off" with the feed and might just attribute it to a network congestion.

"You run a big risk here of upsetting the switch and/or upsetting the VMS, causing it to detect the camera as down and then up, resulting in a full reconnect. If your device isn't able to handle the full auth part, then it will be obvious there is a problem."

Theoretically, I would think you let it reconnect at first and then cut over to the tap once reconnection occurs. Yes/no?

people don't use 802.1x. It only authenticates the first hop, it doesn't secure the data.

yes you can do an RSTP loop. No that's not sophisticated. The team that did the hacking demo at PSA TEC this year in Colorado (I did color commentary on the side of their preso) was doing this/prepared to do this with audio and video.

people don't look at link up/down. If you caught that and treated it like an alarm all this stuff could be mitigated. this requires managed switches and a log server that's listening. Some integrators and many large enterprises can handle this, it's not impossible.

yes you should be using TLS, When IT security people say "use TLS" they mean FOR ALL THE TRAFFIC". Not this conmmand-over-tls/critical-video-in-the-clear sloppy engineering prevalent in the VMS world.

In my experience many VMS/camera vendors make protocol-illiterate claims like "tcp is slower" and "you can't do crypto in a camera" and "you can't do TLS in a server" and "you can't do that in a camera". They're all at risk when they do this. What they really mean is they buy crap low-end OEM cameras with weak processors and they're too lazy to re-architect their VMS software away from it's late-90's code base.

No, not sophisticated. About average for real hackers.

Rodney, thanks. When cameras have HTTPS enabled, does that encrypt the video feed as well?

And are there other released open source applications like this that make it easier to hack video feeds?

When cameras have HTTPS enabled, does that encrypt the video feed as well?

I did a test, short answer, yes. Long answer, Encrypting Video By Tunneling Rtsp/Rtp Inside Https.

On the other hand, you could easily believe you were encrypting the video, based on the settings, when in fact you are not.

This article and blog comments might lead one to think IP video in ANY scenario is not secure and maybe shouldn't be used without high level network security applied which most small to medium video customers can't/won't pay for. I think its important to discuss what the actual risk of this kind of hack would be given the type of customer and the application.

John you mentioned: "Two key parts to this"

Part 2 looks like you'd have to have physical access to the network cable attached to each camera? So the first penetration would need to be physical. If that's the case, I can see an Oceon 11 operation hacker taking the time to penetrate the physical security (access control, barriers etc) and doing this but I'd think 98+% of the security systems in place would not be a target for this kind of attack.

That said, if Part 1 and Part 2 are completely separate and Part 1 can be accomplished without ever touching the physical network cable - that would be the one most likely to affect the 98+% and that would be a reason to lose sleep (or go back to stand alone, off network, analog tech)

Am I misunderstanding something? I guess I'm just thinking its a very small risk in the majority of cases and I wouldn't lose sleep over it but it should definitely be addressed for higher security apps.

Meghan, not only do you need to be physically there, you need to be on a cable that is carrying the specific camera you want to spoof. The reason is that you need to intercept the RTSP video stream. If that stream is on another part of the network, you cannot use this.