Do you develop an IoT product? Read the Top 10 vulnerabilities you should be aware!

If you are an indi-developer, a hardware company or a software company, you must be protected against the following vulnerabilities. The following are the ones we often come across while performing security testing against IoT gadgets.

Denial-of-Service

Many developers may put a lot of effort in properly configuring the network settings or even updating the libraries, however, their device may end-up being vulnerable to denial-of-service attacks. Such attacks make the device being unusable by the user, having the user blaming the vendor (that is, you). The user doesn’t have the training or the background to understand what went wrong, and thus the user won’t be able to understand that he may be under attack.

There are two forms of denial-of-service, a temporary DOS and permanent DOS. A temporary DOS is happening when the attack lasts as long as the attacker is performing the attack. On the other hand, the permanent DOS is when the attacker managed to alter the state of the device in a way that is now unusable, and thus the communication, or the state of the device, cannot be recovered.

The DOS attack may not be solely mistake during the development time, but of integration time. The vulnerability may lie in a dependency packet which is vulnerable to denial-of-service.

Hardcoded Passwords

A product may use any of the myriad software solutions out-there to ensure the confidentiality of the user’s data. Depending on the implementation mechanism used, the process may not be so easy. For example, in Bluetooth Low Energy, setting up a password may have some some hardware requirements depending on the configuration settings. Therefore, the developers often use to set up a basic configuration using a static hard-coded password (or PIN), with the hope that he or she, will replace it with a dynamic one later on. However, due to the nature of the mechanisms, it may be impossible to change the project to reflect the dynamic allocation of the key. Then, the developers are based on what we used to say “security by obscurity” and continue to use the hardcoded password in production code.

By using the user’s data by a static key, isn’t protecting the confidentiality at all. Actually, it is like it never existed, as the key is there fore anyone to find. Given enough time and resources, the key can be found.

Firmware extraction

Many vulnerabilities were found by extracting and analyzing the firmware. When the source-code is not available, the firmware can provide a low-level insight of the code. Even though extracting and reverse engineering a firmware is tedious and demanding task, this is achievable. Therefore, your software shall not keep “secret” keys or files, as those can be compromised. Moreover, the software may have vulnerabilities which could be found and used by malicious actors without disclosing them to the vendor. Finally, during the development time, the development teams tend to create debug code, or some functionality that will be removed during the production time. However, some functionality may be left-over without noticing. When found, there are cases where can be used maliciously and can be used as a backdoor into the user’s device. Even this does not occur in firmware extraction category and should be mentioned separately, remember that such functionality is found only when the firmware has been extracted.

Misconfigured network settings

Many gadgets wish to communicate with the user through another device (ie a Mobile Application). In this case, other protocols (supported by both peers) are needed. Often, such protocols are WiFi and Bluetooth. Therefore it is vital to configure such networks to communicate effectively and securely. A misconfiguration of the network or the connection parameters, one may be able to sniff the connection and perform Man-in-the-Middle attack. Additionally, the malicious actor may cause a denial-of-service to the device.

Lack of privacy protections

The privacy of the user is very important and you should keep it in mind while developing any kind of commodity hardware. It’s sad to see that most vendors don’t care about user’s privacy, even when it’s on OWASP Top 10 proactive security list.

The user’s privacy must be protected in all layers of the product, such us in hardware and software. For example, in software, the device’s address such as the MAC address can be static and thus leaking the user’s identity. One can stalk the user by using the MAC address. A mitigation is to configure the device to use randomized address or generate a random resolvable address. Another example, is when broadcasting data containing user’s personal identifiable information (PII).

Default Settings

Currently, there are ten of million of devices produced and delivered having default configurations, including default credentials. Various vendors tend to provide products having a default password, having the user to change the password (or settings – ie Network Settings) as needed. However, most users don’t, which often leads to a compromise of their device. Therefore, the brand gain bad reputation as multiple devices are being targeted, remotely or locally, because of the product is shipped with default settings including default passwords and weak network settings.

Outdated or unmaintained OSS

A hardware takes some months to be developed and a lot of effort is put onto it. Having a major change in the software-side may delay the project for weeks. Equivalently, that means man-hour which translates to money.

Many developers rush into selecting the libraries which works best, and to quickly catch-up with the deadline of the project. However, often, many of the currently used libraries are outdated and contains several vulnerabilities. Such vulnerabilities are now part of your product, thus making your product vulnerable to attacks.

In the past, there wasn’t such an issue for gadgets. However, modern gadgets contain much more software and interacts with other systems, transferring keys and sensitive data. When i’ m talking about sensitive data am not referring only to PII but also to even more sensitive data. For example, imagine having a device which transfers data through a vulnerable implementation of Bluetooth, and thus transferring cryptographic private keys (i.e it may be part of a crypto-currency network). As you can see, the wallet of the user may lie in the security of your product.

Sometime, the developer is not who to blame, but the same development environment. For developers to speed-up the development cycle, may choose to use IDEs that have installed plugins which help in installing the necessary libraries and/or dependencies for the project. However, such plugins pulls the software database, binaries or source-code from a predefined source. Such source may integrate outdated software and thus, the version of the dependencies must always be checked against known vulnerabilities. Even more severe issue, is when integrating with unmaintained software. Even if such software works now, and even when no known vulnerabilities exist, the system may be vulnerable to future attacks which will remain unresolved and unfixed, as the vendor stopped supporting such software.

The best practice for outdated and unmaintained software, is getting your-self updated. Make sure you have the latest versions of your software, and that the version you are using isn’t affected by known vulnerabilities. I could have said that there are known software that may help you handle all of this, but then i would lie. The best solution, is you!

Insecure update mechanisms

Software needs to be updated. The reason may be bugs needs to be fixed, features has been added or vulnerabilities discovered and have been resolved. In any case, a software update must be pushed to the gadgets. A common way to easily update hardware gadgets is through WiFi access (if the device has any), or through a mobile app (communicating via Bluetooth).

The update mechanism is very important to be secure as a malicious actor could push a different update which could lead to the full compromise of the end-device.

There are multiple ways to attack an insecure mechanism, starting from the endpoint’s configuration (ie server’s communication – HTTP/HTTPS), to the delivery mechanism (such as Bluetooth DFU). The vendor, that is, you, must be sure the packet is transferred directly to the device in a secure way, and that has not been modified by anyone in between.

Some of the vendors we have seen out-there used to encrypt their update payload and transfer the data through an insecure network. That way, nothing needs to be secure right? The data may be signed as well. Well, almost. What they have not calculated right, is that the decryption and signing has been done by using a key which was burred inside the hardware, and that key, was same for everyone. That way, by extracting the key once, one can intercept and modify the intercepted payload of any other device.

Insecure in-house protocols

When a gadget is controlled by another device (i.e an application), often developers tend to create their own custom protocols to communicate with it. In such case, the protocol is stacked on top of other network protocols. However, a malicious actor may be able to connect and communicate to the device via an unauthenticated way. The protocol must be hardened and vulnerability-free otherwise the device may be compromised.

Lack of proper education & training

Many companies are afraid to spend a significant budget to properly train their employees. The fear comes from the common pattern of “training following a resignation letter”. The companies have seen this pattern repeated many times, as the company may spend a fortune on an employee which is then leave the company in a short period of time. This is not always the case though.

Over the hundred penetration tests I carried out as a penetration tester in the past, I have seen the same mistakes over and over again, from the same companies, even from the same developers. Even though we explained the mitigation and the root cause of the problem, the developers were unable to understand the problem completely. This is because they fundamentally lacked the core concepts of web security (in case of web applications for example). The same happens in hardware, especially when things becomes tough as both hardware and software attacks exist.

I will end this with the following: I would not worry about a company having up-to-date and fully trained people which may, or may not, leave the company after some time, but I would mostly worry on having employees which haven’t been educated for a long time and stay in the company forever!

The knowledge of your employees is reflected in your products, either you want it or not.

Cybervelia helps its customers to solve this problem, by providing in-depth trainings with organized hackathons which are totally focused on security and tailored to the needs of the client. A specialized platform is provided and we ask for our clients to dedicate a day or two, so the employees have fun, learn and team-up to solve security coding challenges together.

Conclusions

We have explained multiple vulnerabilities that may arise during the development of any gadget. However, there is a chance that even when you are proactive in security section, you may still be affected by unknown and undiscovered vulnerabilities.

The developers are very good in what they do: they develop software. However, they might oversea a configuration parameter, may lack knowledge to the protocols, or they may have designed a vulnerable code snippet which may put the whole product at risk.

Why don’t you put your trust in us, to make sure your products are secure?

At Cybervelia, we can protect your users by securing your products. We will have a look to the product without requiring you to give us any kind of code or design blueprints. We can then use our own customized hardware and software, and attach them to your product in order to assist in finding any kind of hardware and software vulnerabilities, as well as misconfigurations of the product.