For a while, researchers have been publishing almost every week new security breaches linked to bad design or configuration errors in the Internet of Things: unprotected security cameras, connected objects serving as Trojan horses, and so on. As we also manufacture network modules enabling you to build connected systems, we must take stock of the situation, so you know what to expect.
First of all, remember that computer system security must be analyzed in context: you don't protect in the same way a web server exposed to the public and a development machine protected by a firewall. We now know that absolute security doesn't exist and that security breaches are monetized on the Dark Net. The key is to adapt the protection level, and therefore the effort necessary to work around the protection, to the security stake. We can distinguish between three network environments:
- The Internet public network, where machines can be directly reached and are therefore the most vulnerable.
- Semi-private networks, such as Wi-Fi networks, for which security protocols like WPA2 are supposed to prevent non-authorized access, but for which we know that there are vulnerabilities and that security is therefore quite relative.
- Protected networks with a firewall, where all physical accesses are controlled, and for which the global security level depends on the weaker link that is connected to it.
The effort spent on protection obviously depends on the object to be protected as well: you don't protect in the same way a machine control room and a garden watering system. Nevertheless, the danger of this argument is to forget side effects that the violation of a minor system can have on critical systems, in particular as a gateway to lower the security level of a protected network.
We are going to review the different types of security flaws to which you can be confronted through the Internet of Things, in order of increasing severity, to analyze the risk when using Yoctopuce modules:
- loss of confidentiality: an outsider gains access to information that is not intended for that person;
- denial of service: an outsider blocks access to the system;
- system integrity violation: an outsider modifies data or changes how a system works;
- use for malicious purposes: an outsider diverts the use of a connected object to participate in a malicious act, for example a distributed denial of service (DDOS) attack;
- use as a Trojan horse: an outsider diverts the connected object as a gateway to attack other machines on the local network.
The basic method to protect confidentiality is encryption. To be efficient, it must be based on recent methods, such as TLS: indeed, SSL is not considered as safe anymore. Unfortunately, because of the size of the processor used in our modules, we couldn't directly include TLS. Communications are therefore not encrypted. If our modules were used to transfer sensitive data, it would be an issue. But the data sent by our modules are a priori not critical, as they are only measures or the state of command modules. Moreover, on a modern protected network (without Wi-Fi), a user cannot access the communications of the other users unless the network infrastructure is already compromised, which would in any case be a much more serious flaw. Therefore, this limitation is usually not critical.
In exceptional cases where encrypting communications with our modules would be essential, the solution is to put our modules behind a firewall with a VPN (Virtual Private Network) function, as with ZyWALL devices for example. A VPN offers much more serious encryption than a simple HTTPS connection, as well as an improved protection against all the other security risks.
For sensitive applications, a firewall with VPN offers a much higher level of security than HTTPS, and also protects against all other security risks
Denial of service
Denial of service attacks consist in preventing a system from working normally. This can be done either by making it crash using a known bug, or in overloading it with useless communications, so that it is not able to answer legitimate requests.
It is almost impossible to protect a system against an active attack by useless communications: by putting up the means, an attacker with sufficient resources can always find a way to overload a system connected to the network.
However, you can protect your system against bugs causing denial of service. Yoctopuce modules are well positioned in this area. You must know that contrary to most connected objects, Yoctopuce modules are not based on a Linux system or another OS kernel of this type. Therefore, most bugs known in the dark corners of the Internet don't apply to Yoctopuce modules. Also, Yoctopuce modules are equipped with a watchdog: in case the module loses connection for a specified duration, the module automatically restarts to get back to its normal state.
To protect the integrity of a system based on connected objects, you must implement an access control on the incoming connections. On all of our modules, you can configure passwords to secure direct access through the network. When accessing by HTTP, identification is performed by the HTTP Digest method. When accessing with a WebSocket, a similar exchange based on a SHA challenge is used. In both cases, the secret is checked without transiting over the network. Therefore, the absence of encryption doesn't represent a risk for integrity.
If necessary, you can obtain increased integrity protection by hiding the system behind a NAT firewall: in this configuration, no one can directly contact the Yoctopuce module. However, thanks to the HTTP and WebSocket callback mechanisms, Yoctopuce modules can still transmit their data and receive commands, but only from the host designed in the module configuration. This greatly reduces risks to the integrity, as one must compromise the control server to modify the system behavior. In case a direct connection is occasionally required, using a firewall with a VPN can provide a secured direct access if necessary.
We reach here the center of current preoccupations, as relayed by press reports. In Fall 2016, the French hosting company OVH and a few other targets were victims of the largest denial of service attack to this day, through the malicious use of 145'000 connected cameras and other objects of this type. These devices were hijacked to be at the service of a malicious control server. How did this come to pass?
The first error of the camera owners was to omit changing the factory password, thus enabling anyone to connect to the cameras. Then, these cameras were using an embedded Linux system which of course was not updated with the latest security patches. Known security breaches therefore allowed the injection of malicious code into these cameras and therefore their diversion from their intended behavior.
Could this problem happen with Yoctopuce modules? It's highly improbable. Indeed, in the opposite to small Intel or ARM systems used by Linux machines, the program run by Yoctopuce modules is not located in the RAM or in a file system: it is run directly from the processor nonvolatile memory. A Yoctopuce module doesn't have an operating system: code doesn't transmit through RAM used for data treatment. Therefore, you cannot exploit a buffer overflow to run any kind of code on a Yoctopuce module: the only code that can run is that defined in the nonvolatile memory. And the nonvolatile memory cannot be written with the instructions used to write data in the RAM. Thus, injecting code in a Yoctopuce module is possible only by writing a new firmware and updating the module with the official procedure, which requires a much larger time investment from the attacker.
A device running on a standard OS is more vulnerable to buffer overflows than a YoctoHub, which is based on a Harvard architecture with code separate from data
Use as a Trojan horse
The same code injection principle applied to a connected object can cause a direct damage to the object owner. Indeed, if the connected object is in a secured network, it becomes a gateway for non-authorized entry into this network, lowering the global security level and allowing attacks to be launched on all other machines. It's therefore a very important risk which is avoided, thanks to the fact that Yoctopuce modules are not based on an operating system kernel.
Connected objects depending on a Cloud service provided by the object manufacturer are a second risk factor. If an attacker takes control of the Cloud service, that attacker can -- depending on the system design -- indirectly take control of all the objects connected to the service. The stakes are high, which can justify important resources to secure it.
Yoctopuce modules are intentionally free of any proprietary Cloud system. Each company can connect them to their own web server, under the control of its own security team. Finally, the effort required to attack a server driving Yoctopuce objects must be spent again for each company one wants to attack, as all the configurations are different. The investment is therefore much less profitable for the attacker.
As many small connected objects, Yoctopuce modules are limited as their capacity to protect themselves with traditional cryptography methods. However, their original architecture very efficiently reduces the risks of denial of service and of malicious use, making them particularly uninteresting as attack points to gain entry into a secured network.