CWE: what developers of connected embedded systems need to know

A lot has been written about the potential risks that could exist if insecure software is used within military, infrastructure or medical systems, and it is easy to understand why they need to be secure.

The growth in the number of remotely controlled, connected consumer devices is accelerating and now includes televisions, entertainment systems, home security, heating and even refrigerators. The associated demand for instant connectivity means that the security implications need to be understood.

Incidents of security breaches within consumer devices are on the increase and steps need to be taken now to ensure that personal information held within the home environment is protected and system functionality maintained.

For example, the broadband router supplied by an ISP was found to contain a CSRF (cross-site request forgery) vulnerability that allowed a remote user to gain full administrative access by using a web browser and a specially manipulated URL.

It was possible to steal security keys and configure the router to forward any traffic to any of the systems connected behind it, even though the user thought they were protected by a firewall.

Another ISP supplier whose power line networking equipment was found to be unsafe due to a manufacturing defect issued a safety notice and replacement units.

Some users were surprised when, some months later, they were sent letters informing them that they were still using the faulty devices. The units were not able to connect to the Internet themselves, and their continued use could only have been detected by means of firmware running in the ADSL modem/router that was supplied by the ISP, even though this included a firewall to prevent unauthorized external access to the private network.

Any security issue, such as the one identified above, within such a customer support feature would compromise the security of the whole network.

While the firewalls within broadband routers are designed with security in mind, this is not necessarily the case with the firmware that provides other functionality.

However, the security of the system needs to be treated holistically to ensure that there are no exploitable vulnerabilities within code not considered as security-related that could otherwise lead to security compromises.

Unfortunately, “Security by obscurity,” where an attempt is made to secure a system by hiding its design and implementation details, has often been considered adequate to protect non-critical systems such as consumer electronics.

The deployment of large numbers of consumer devices means that the chances of this security being maintained are negligible as many, many people have the opportunity to investigate its behaviour.

An example of such a failing occurred in 2008 in Poland when a teenager modified a remote control unit so that he could change the signals for the tram system. His actions lead to the derailing of at least four trams, resulting in twelve people being injured.

The signals for the trams had been designed so that the driver could control them by using a remote control. The system was considered to be secure as the hardware was not commercially available and no thought was given to the injection of commands from any other external source, resulting in the use of data without encryption or validation.

The recent compromise of the Sony PlayStation Network clearly demonstrates how a security breach can impact a large number of people and be extremely costly to those affected. The abundance of connected devices now available to the general public possibly requires them to have stronger security attributes than those that are maintained by competent persons as only a small percent of users even consider the security aspects of their deployment. Given the size of the code-base associated with these devices, it is a non-trivial task to ensure that they are secure – tools, processes and best-practice must all be brought to bear.