Many connected cameras, video doorbells or surveillance systems have been found to contain security flaws.The implications of these flaws vary from data exposure (such as broadcasting user data – like IP address, email addresses, username and password combinations in an unencrypted manner) to those that could allow attackers to gain unauthorized access to the video stream the device controls – or a combination of all of those.
Let’s talk about RTSP interception.
RTSP (Real-Time Streaming Protocol) is a network protocol for streaming media such as video and audio. It should be noted that RTSP is a streaming protocol, while RTP is a network transport protocol. In other words, RTSP controls the stream (play, pause, etc) which itself travels over RTP.
Though SRTP (Secure RTP) supports encryption and authentication, and there are other methods to encrypt RTP as well, in many cases there is no authentication at all needed to access the RTP stream. This means someone can simply utilize software such as VLC (a free and open source media player) to request access to the video feed /stream / media with a simple RTSP url request – which looks like this:
rtsp://[ip]:[port]
Devices that work like this either give anyone (or anything) connected to the network access to the video (and audio) stream. Depending on the configuration of the devices and/or network, this could include access via a Guest network, or even remote access from the internet.
Weak authentication is next to no authentication.
Even if the RTP stream is password protected, it is sometimes the case that access can be gained by simply including the credentials within the stream URL itself such as the following:
rtsp://[username]:[password]@[ip]:[port]
Sometimes the device accepts this information if it is in a different format, such as Base64.
As you may have noticed, this authentication method allows appending different username and password combinations to the stream URL, with the hope of eventually guessing correctly. Using an existing tool or creating one to check against simple/common usernames and passwords (for instance admin:admin, admin:password, etc) is relatively trivial.
So how would someone go about doing / discovering this?
It’s surprisingly easy. An attacker/interested party may simply run a port scanning tool (such as NMAP – a popular free port scanning tool) on a network that they are connected to. What this can do is list all the devices connected to the network, and also list out what ports are open on those devices, and thus what services those devices might be running.
These ports commonly map to known services, for example:
:554 – RTSP
:80 (:8000, :8080) – web (http)
:443 – web (https)
Some of these devices have a web interface (or other potentially exploitable services) running on them – whether it is documented or not. Focusing on web interfaces for the moment, it may be possible that the interface has no authentication at all, or that the login mechanism can be bypassed. Some of those interfaces use HTTP (Port 80, sometimes 8080, 8000, etc).
What this means is that anyone on the network may be able to access the web interface simply by visiting the IP address of the device in a web browser. What that also means is that because http is used, it is not encrypted data, so even if the web portal had an account with a complicated password, an attacker with network access would be able to capture the credentials when the user logs in, and use those credentials themselves – allowing them to take complete ownership of the device.
In other cases, even with a web interface using https, there may be other weak security protocols, such as a lack of rate limiting on the login page – meaning an attacker could run password guessing tools against the interface to gain access.
In the course of our testing, we have found we had the ability to intercept the streams of several devices back in August of 2023. We reached out to the manufacturer regarding our findings and concerns for the following devices (The manufacturer has not responded to us):
- Swann 4K Floodlight SWIFI-4KFLOCAM Security Camera (App version: 3.0.136 / Hardware version: 3 / Software version: V3.1.3.19 / Agent version: 4.1.12).
- Swann SWiFi-SpotCam-GL Security Camera (App version: 3.0.136 / Hardware version: 3 / Software version: V3.1.4.13 / Agent version: 3.3.10).
- Swann SWIFI-TRACKCM32GB Security Camera (App version: 3.0.146 / Hardware version: 3 / Software version: V1.0.2 / Agent version: 1.0.10).
- Swann CorePro-GL (App version 3.0.446) (Firmware version 1.0.41)
In these cases, no authentication of any kind was needed to access the feeds. Anyone connected to the same network as the cameras can easily intercept the video and audio from the device(s) in a manner such as described above:
Screenshot of the video interception
Additional analysis of the network traffic (see screenshot below) revealed unencrypted device and environment information such as the device model, Internal IP address, the network SSID, etc, being broadcast in an unencrypted manner from the device to the mobile app (phone). Note that for the purposes of this testing, the phone was using a separate network (Wifi) connection (10.215.173.1).
Analysis of the network traffic
This type of information can allow access to information that may be used for further attacks of opportunity (for instance, identification of a potentially vulnerable RTP enabled device or devices without the need to even scan the network).
We want consumers to be aware of, and take steps to reduce security risks related to cameras such as these by considering the following:
- Placing cameras on a separate network or VLAN – setting appropriate firewall rules
- Avoid port forwarding cameras to the internet
More security tips and guidance can be found at securityplanner.consumerreports.org.
