Since founding VDOO, we have been working to analyze a great many IoT devices, in the broadest way possible. We will use this information to achieve a number of goals, including:
- expanding our IoT threat analysis research
- improving device classification
- better understanding the nature of IoT operating systems
- profiling different RF protocols and physical ports
- identifying each and every SW and HW component and their known vulnerabilities
- identifying ‘low hanging fruits’ for attackers
- finding commonalities between devices
- and most importantly – improving our technology in order to be able to do all of the above, and much more, in an automated manner
We believe this initial research is essential in order to fulfill our mission: to change the face of IoT security.
The more we look into these devices and find their vulnerabilities, the further we validate our basic hypothesis: security for IoT must start with the most basic security building-blocks. It is very challenging to add security to an operating device retrospectively, as it is to mitigate security concerns after-the-fact. Hence, security should be in the DNA of the device. There are just a few, key steps which need to be taken care of in order to deal with most IoT attack vectors. From the simple ones that utilize default passwords, to the most complicated that exploit a newly-discovered vulnerability on the attacked device.
These ‘security building blocks’, or security essentials, differ from one device to the next, since they are heavily dependent on the device’s attributes. But how can these principles deal with the unknown? With zero-day vulnerabilities? Is it even possible? We have learned from the traditional IT world that a new and unique security agent had to be developed especially to deal with such vulnerabilities. So how can a mere few security building blocks be all that is needed for IoT?
First, it has a lot to do with the goal of the attack, as well as the nature of IoT versus IT. For the most part, PCs have the ability to receive emails and browse the web, not to mention the endless ways in which the user can interact with the system. With many IoT devices, this is not and will not be the case. User interaction is designed to be very limited, so the malware delivery method would have to depend on other things. In most cases, these would be inherent vulnerabilities, but as the reality stands today, it is primarily missing security essentials that are the cause.
The second answer is no, it is not entirely possible to deal with vulnerabilities with just a small set of security building blocks. However, it definitely makes it significantly harder to exploit vulnerabilities (assuming security vulnerabilities will always exist) if basic security is implemented.
Clearly, many devices suffer from missing security. There are many reasons for this, which I address in another post explaining why we started VDOO. In many cases, these devices do not even have the most basic fundamentals of security, such as enforcing default password change, protecting the boot process, checking firmware integrity or encrypting communication with the app controller or web services. For these devices, attackers do not even need to look for a vulnerability, as the flow of attack is very straightforward.
On the other hand, if devices do have these security essentials, attackers will need to look for more sophisticated ways to get in, and will probably take one of the following paths:
If these basic security building blocks have not been implemented well:
- the attacker will probably find a vulnerability in one of these security building blocks and get in that way;
- the attacker will then probably exploit some other vulnerabilities to execute code, drop a malicious payload on the device and carry out their plan of attack.
If these basic mechanisms have been implemented well:
- it will be hard for the attacker to find vulnerabilities in these security building blocks themselves;
- it will be much harder for the attacker to exploit vulnerabilities they do find which are not part of the security building blocks, as these basic mechanisms will prevent them from doing so successfully.
The last point is worth dwelling on: even if an attacker does find a severe vulnerability, in many cases it will be very difficult to exploit. But what does ‘exploitable’ mean? This depends on context: the attacker’s intention and the kind of device being scrutinized. Here at VDOO, we are striving to make the entire IoT industry better. This includes commercial and consumer devices,as well as automotive, medical and industrial devices. Our initial focus is on the mass market: commercial followed by consumer. For these types of devices, we anticipate that the attackers’ main motivations will not be persistent access or specific assets, but rather for money. Organized attackers will utilize (and already are utilizing) the immaturity of IoT in order to blackmail their users, by hijacking their devices or threatening to expose data they have stolen, usually embarrassing.
From the attacker’s perspective, the effort they are willing to put into carrying out these attacks is dependent on how much money they stand to gain. This will depend on the quality of target, the impact of the attack and the scale. Attackers will always want to make the most efficient use of vulnerabilities they have identified, so are likely to go for mass-market devices. So, when we ask what ‘exploitable’ really means, we are looking in particular at attacks that are conducted remotely and can be executed against a large number of devices to bring about widespread damage. Almost by definition, if an attack against an IoT device can be carried remotely without dependending on the device’s local systems, it can be also utilized for a large-scale attack. To sum up, in this case ‘exploitable’ refers to vulnerabilities which enable full remote access to a device, let alone to a mass of devices.
To better clarify this, I will use a recent example from VDOO’s labs. As part of our research process, we came across a vulnerability in a commercial IP camera produced by a prominent IP security camera company (currently in the process of responsible disclosure). This vendor suffered from several other vulnerabilities and acted promptly to mitigate them. Almost all of the previous vulnerabilities enabled an attacker to execute code on the device, allowing them to download files to the device, run processes, install packages and use the device as a bot or for another purpose. That is to say: all of these vulnerabilities, as well as the one that we found (which was considered to be more ‘sophisticated’), enabled the execution of code on the device, once the attacker had gained access to the device via one of its existing interfaces. In other words, if the attacker finds a way to log in to the device, then this vulnerability will allow them to do whatever they want – which is far from obvious. These vulnerabilities are severe, and are exactly what bot-malware needs in order to make your device part of the botnet.
Let’s go back to the start:
What needs to happen for malware to be able to exploit this vulnerability? First of all it needs to bypass the authentication mechanism to gain access. In simpler terms – it needs the admin credentials to get in. Only then can it exploit the vulnerability to run code on the device.
So how can it bypass the authentication mechanism? There are a few options:
- Default – the simplest way is if the device itself does not enforce changing the default user/password: the attacker simply connects to all the devices of the same type out there, with the same default credentials. Then for all the devices they have gained access to, they simply go on to exploit the vulnerability.
- Brute-force – trying endless user/password combinations until they gain access. If they’re lucky, this will take hours or even days, as each combination has to be checked against the device, which takes time. If they’re not, the device may have a suspension mechanism which kicks in after a number of failed attempts.
- Theft – stealing the user/password somehow, although this requires socially engineering the victim or hacking into their computer/mobile to get the credentials from there. This is difficult, and more importantly, not at all scalable. This can only work for a targeted victim and requires particular effort – it cannot be leveraged to attack many devices at once.
- Research – looking for a vulnerability in the authentication mechanism to enable login to any device suffering from the same vulnerability, then executing code via the exploitation of the initial vulnerability. This takes a tremendous effort, but in some cases can be worthwhile. The better the authentication mechanism is implemented, the harder for the attacker to find a vulnerability in it.
Of these four options, the first is much easier to achieve than the other three, and is very effective. And yet it depends on such a simple mechanism: requiring the default credentials to be changed. Through implementing just this one, simple change, the vulnerability in question becomes much less valuable, and much harder to exploit for a mass remote attack.
Looking at other vulnerabilities in many types of devices (routers, cameras, doors, fire-alarms, smart TVs) we see exactly the same phenomena: ‘severe vulnerabilities’ which are considered to be very sophisticated, but whose successful exploitation by a remote source is highly dependent on a lack of basic security. If only the makers of these devices had taken care to properly implement the security building blocks in the first place, the chances that these severe vulneraries would be exploited could have been dramatically lower.
Basic security, if implemented correctly, can constitute a very efficient way to make it hard for attackers to gain access, even when they do manage to locate a new vulnerability on the victim’s IoT device.
Here at VDOO we are working to make a real change to device security by helping device makers to get to grips with the right security basics for their specific devices, as well as helping them to implement these easily, cheaply, and in an automated way. Our approach is always to start from the very basics, and to deal with more concrete threats via easy-to-deploy mitigation mechanisms. For devices that are secured in accordance with VDOO device-focus-requirements, vendors can receive certification which will be recognized by device buyers, to let them know that the vendor takes security seriously, as well as a ‘smart certification’ engine, which the vendor can use to communicate the device’s security status to other security solutions.
Contact us with any comments or queries at email@example.com