With the evolution of the cameras, attackers have also become more skilled and better equipped. We are seeing many attacks on camera infrastructure where the attackers exploit various loopholes in the system. Recently, there was an attack on a security startup where the attackers breached data of nearly 150,000 cameras and were able to view camera feeds from jails, hospitals, schools, and offices. Earlier this year, cloud-connected cameras of more than 200 individuals were hacked, and the hacker had access to over four years of footage that was backed up online). Some years back, there was an incident where hackers had breached the security cameras of a casino and made millions by gaining an advantage in the high-stake games.

It has become imperative to secure every component in the smart camera ecosystem, as ‘security is as strong as the weakest link.’ Even if a single element in the architecture possesses a vulnerability, it can compromise the whole system.

This blog explains the different attack vectors and security considerations to follow while securing your camera’s ecosystem.

Architecture

Let us consider the architecture of smart cameras installed in a home. It would have wired or wireless cameras connected to a gateway, which would subsequently connect to the Internet, where it would also accept communication from the developer’s server. A user can access these cameras using their phone’s custom-built app to manage the cameras in two modes – (a) by connecting to the gateway via Wi-Fi, or (b) by connecting over the Internet and getting routed to their camera.

Here is a typical architecture with different components of the smart camera ecosystem.

All these components, regardless of whether ownership lies with the user, the camera company, or the public, could possess vulnerabilities. Eight different components are tagged in the architecture diagram indicating points of vulnerability.

1. Gateway

As the central controller in this setup, the gateway would be responsible for almost all the configurations, management, access, authorization, maintenance, and update. Hence it becomes significant to secure this component. Also, the attack surface is from both sides – public Internet as well as an internal network. Firmware is exploited in such an attack, and there is continuous research to find ways and means for gateway and router exploitation.

A study of nearly 100 home routers last year revealed that almost all of them had severe unpatched security flaws. Similar is the case with home gateways – varying functionalities but same techniques. The attacker can control all the smart endpoints connected to a particular gateway by attacking routers or gateways.

Ensuring that the firmware undergoes a periodic and ad-hoc security audit by internal and third-party teams is one way to protect yourself from such an attack. Any security issues reported should be fixed on high priority, and the updated firmware needs to be provided to the users at the earliest. It then becomes the users’ responsibility to keep their gateway device updated with the latest version of the firmware.

The main areas you should consider focusing on, from a security perspective, are:

1. Authentication and authorization mechanism for accessing the gateway and its different modules
2. Secure and encrypted communications between various internal and external components
3. Coding practices to keep the code free from any security issues
4. Proper handling of input, errors, and exceptions
5. Robust cryptographic algorithms for encryption
6. Secure storage of sensitive information

2. Connection from the Mobile device to the gateway

All the internal components present in a typical home would be connected via Wi-Fi signals. This mobile device would be connected to the gateway mainly to manage the cameras. When the mobile device accesses this environment using public internet touchpoints, there would be more authentication mechanisms and security controls – compared to a device connected via local Wi-Fi network. However, it is always better to have the same level of security for the internal network too.

Some of the attack scenarios and security considerations for this case are:

1. A guest or a neighbor can try to get access to the gateway or cameras. Hence even if it is on a local network, there should be at least one level of authentication. This would also protect against any rogue or compromised devices in the same network
2. The SSIDs should not be the default and should be hidden for all connected devices, reducing the attack surface of a brute-force attack
3. Guest accounts should be disabled for the Wi-Fi network or gateway
4. Wi-Fi should be secured using a robust WPA2 key
5. Wi-Fi network should be secure against protocol-level attacks like KRACK

3. The connection between the camera and the gateway

These are the two core nodes in the architecture – and their communication is important as, without this, they serve no purpose. The transmission can be wired or wireless.

Several security considerations need to be taken care of to ensure the overall security of this communication. The most basic is the availability of the network – the protocol should be such that it can handle the DoS attacks – which a hacker can trigger in an authenticated or unauthenticated manner. Next comes the MITM (Man-in-the-middle) attack in which an attacker can sit in between the two nodes and sniff or modify all the traffic – this endangers the confidentiality of the traffic. Enforcing proper encryption can mitigate such attacks.

4. Camera

The camera device is the heart of this ecosystem. Securing the camera’s internal functions and data flow becomes the primary goal to reduce the overall risk, while the next step is to secure the camera’s firmware.

There have been many attacks wherein weak firmware security allowed the attackers to take control of the camera. Earlier, it was not easy to fetch the firmware and analyze it, but recently, several resources have become easily accessible, making this process easy and quick.

The firmware should undergo rigorous auditing to check for any security bugs – in the code, data flow, various logics, and even the configurations. Most of the security issues observed recently are related to authentication – thus, it is mandatory to change the default credentials and remove any hardcoded passwords. It would also provide additional security to enable multi-factor authentication.

5. The connection between Gateway and Cloud server

Typically, this connection would be between the cloud environment of the developer and the home-based gateway device using the public Internet. Since it is traveling through the public network, there is a high probability of attackers lurking to attack the communications. The primary security considerations for this scenario should be:

1. Gateway checking the authenticity of the cloud server
2. Cloud server checking the authenticity of the gateway device
3. Integrity of transmitted data remaining intact during communications
4. This communication should not be eavesdropped on, where proper cryptographic algorithms are in place to encrypt all the data
5. Privacy of the user data coming through gateway should not be compromised – only the required data to is be shared to cloud server and in a very secure manner

6. Cloud server

The cloud server, in this instance, refers to the developer or company-managed server located in the cloud. This server could consist of many machines used for different purposes such as live streaming, video storage, user authentication, firmware upgrade, user configuration, web application, backend programs, logging.

A security team should first audit the cloud environment, and establish boundaries on who will manage the security of which component – the hosting provider or the cloud server owner. The next step is to check for any misconfiguration, followed by checking for efficient access control.

The security considerations are as below:

1. Implement proper authentication, which should consist of multi-factor authentication
2. Establish access control mechanisms with a proper IAM plan
3. Encryption of data at rest (storage) and data in transit (network)
4. Continuous security monitoring of all the assets and a tight and updated vulnerability management process to keep all the systems secure
5. All the assets should be compliant with relative standards and certifications

7. The connection between the Mobile device and the Cloud server

A valid user can manage and access his or her cameras from any point of the world using the Internet. This is made possible via the cloud server, which connects to the gateway to provide exact access to a user’s resources. For the cloud server, it becomes significant to identify and provide the perfect access type to each user. Here are the security considerations and attack scenarios helpful in this case:

1. Authentication becomes the main pain-point here – a strong authentication system should be in place to allow only valid users. There should be arrangements to mitigate any authentication related attacks by using rate-limiting and multi-factor authentication.
2. Authorization comes next, which checks that a valid user has access only to the allowed resources. This should also cover privilege escalation, where an attacker can escalate his rights to gain higher privileges and perform activities that are usually not permitted.
3. Trust between the mobile application and cloud server should be adequately established so that both parties know and trust each other. This can be achieved using SSL pinning.
4. Encryption of traffic between the two parties should be mandatory.

8. Mobile application

The security considerations for mobile applications are also applicable to other platforms used to manage and control the camera. Typically, this would be the application used for various purposes, such as controlling the camera, watching live streams, managing users, recording, and so on.

There can be different attack scenarios in this case:

1. Other application(s) on the device being able to read the password or other sensitive data on the user’s camera application
2. The attacker being able to bypass authentication on the application if he/she has physical access
3. On the same network, a third party being able to read the communication
4. A third party being able to reverse engineer the application to read data
5. An authenticated user being able to tamper with the code to enable or disable features not intended for that particular user

You should properly audit the mobile application to find any such security or privacy loopholes and mitigate all the risks within a defined timeframe. Since the code resides on the client’s phone, a user can decrypt it to read the actual code – hence it should be obfuscated. This testing should be done in accordance with OWASP Mobile Testing Guide.

eInfochips provides end to end cybersecurity services. Our expertise spans across strategic assessments and transformations, turnkey implementations, and managed security operations. To know more please contact our cybersecurity experts today.

References:
[1] Verkada Security Breach
[2] Home security technician admits hacking customers’ security cameras
[3] Crooks Spy on Casino Card Games With Hacked Security Cameras, Win $33M
[4] Popular home routers plagued by critical security flaws
[5] KRACK Attacks
[6] Intro to Hardware Hacking – Dumping Your First Firmware
[7] How to Explore the Camera Vulnerability (Firmware)
[8] How do you protect your data in transit
[9] 6 Tips for Improving Cloud Computing Security
[10] OWASP Mobile Security Testing Guide – OWASP Mobile Security Testing Guide