Author

Published

12/27/2016

It's Not Just a Lightbulb: 12 Fundamental Parts of a Secure "Thing"

Image with an icon that shows a computer screen with a chain and lock around it.

The presence of “Internet of Things” is continuing to grow as every “thing” around us is increasingly being connected in some fashion. Connected directly to the internet, our phones, beacons, etc. Security has also become even more important as these “things” become more accessible making it a core requirement no matter how trivial or life-supporting.

This article will review several key points and approaches for your company to focus on when building a “thing”, which we’ll refer to as a device from here on.

“But it’s just a lightbulb”

You might already be asking though, “Simple devices with only one or two functions, like a lightbulb, don’t need security, right? Who is really going to bother attacking that?” — That might be the case. But let’s say that there was a security disclosure that allowed anyone to permanently disable the lightbulb? Or anyone having the ability to download all the data from your company’s fitness tracking device? No company would want that kind of bad press.

One recently published exploit was with Philips lightbulbs within the ZigBee protocol that allowed them to be infected and controlled. The infected lightbulb could then go on to infect other lightbulbs within range. It’s rather annoying actually to have a light bulb blinking on and off constantly. Even worse is the potential to permanently “brick” them, which requires physical replacement. Now imagine that damage to a city-wide scale.

Security is a necessary investment

All new devices should have an investment of penetration testing applied to it. Investment is a key word because it isn’t cheap to hire an expert security consulting company to spend several days trying to attack your device. Then after a discovered flaw is patched having to re-hire them to “pentest” it again. The costs do add up if they’re driving security instead of just verifying it.

Before you begin spending time on pentesting, what are some fundamental, low-hanging fruit that your company’s device can focus on? This list is pretty close to the usual web app security list, with some additions for devices.

What are some high level areas to focus on?

Do not reuse usernames & passwords

It is fascinating how this is still a common security issue these days. Just a few months ago there was major internet disruptions by the Mirai malware infecting IoT devices and then using them to take down sites of the attacker’s choosing. How did Mirai get access to the devices? Default vendor username & passwords!

It’s great for end-user convenience and generating user manuals since nothing needs to be changed. However, wireless router WPA keys are typically dynamic per device now and printed on a label, so why can’t usernames & passwords as well? Usernames and passwords should be sufficiently complex as well. Eg., no single dictionary-word passwords.

Implement bruteforce protections

The device shouldn’t allow endless guessing of the user/pass. After a few incorrect guesses it should close the connection. It should also require a certain timeout between guesses making it infeasible to crack a sufficiently difficult password.

Constant-time cryptographic algorithms protecting the password are also a requirement nowadays. An insecure algorithm helps reduce the number of guesses an attacker needs to make by essentially allowing them to guess the password one character at a time rather than the whole password.

Avoid any kind of “guest” access

One of the main problems with guest access is that increases the security fingerprint of the device. For example, if the device allows a restricted shell to run commands. Now the security scope has to cover the entire shell and any commands it can run or even the kernel that accepts those commands, which can be much more than very restricted login shell.

Again, with the recent infection of IoT devices, the BASHLITE malware utilized an exploit within the shell. Avoid granting any unnecessary device scope if possible. This can involve some tough decisions, but some are rather obvious: does an unauthenticated user need to be able to get the current time on the device? Most likely not.

Utilize encrypted connections

This one is also interesting that it’s still an issue. In some cases the device may be too underpowered, but unless the device has a minimal embedded situation requirement, any connection to it should employ some kind of secure encryption. Encrypted connections prevent interception of sensitive info and spoofing, especially for wireless communications.

Utilize secure encryption ciphers and software library

However, encrypted connections isn’t sufficient in itself; just because there’s encryption though doesn’t mean it’s secure. Avoid implementing your own encryption protocol, there’s plenty of algorithms with acceptable implementations, especially if you have a processing chip that has a specific offload for that encryption.

For example, wireless keyboards back in the day used (and probably still do) a very basic XOR method of encryption. That made it trivial to listen and crack the encryption with ease. Basically someone parked in a parking lot could see every key typed. Imagine all those usernames and passwords that could easily be harvested.

Force the device to use secure methods

The device should be as restricted as possible to maintain the smallest security footprint and expected behaviors. It’s unfortunately common for devices to use HTTPS encryption, but then not be required to use a verified SSL certificate. That makes interception rather trivial if anyone can impersonate the end-point it thinks it’s talking to.

A more advanced step can utilize “certificate pinning” which requires that a very specific SSL certificate is the only one approved, and also logs any invalid certificates encountered that informs the cloud service when a valid certificate is detected again. This can greatly reduce the scope of an interception attack.

The cloud service security is important too

Don’t forget to apply the same, if not greater, security to the cloud service. If your device can connect to it, assume any device can connect to it. The native app will be disassembled, the API interactions will be intercepted, there won’t be any “secrets”. A cloud will potentially have a different set of security risks than the device so this list will be different. OWASP maintains a nice collection of web security to follow.

The cloud service holds all of the various user accounts. FitBit recently had to deal with an exploit in their cloud presence that leaked a lot of user information. Due to that potential a cloud service’s security should be just as important as the device.

Use a secure programming language, libraries, and techniques

This is a bit more advanced because in some cases the choice of libraries is defined by the vendor and the device’s capabilities limit what can potentially run on it. Low-level languages like C require secure programming practices; they’re notorious for typical flaws like buffer overflows. Instead, if device specs allow, consider a higher-level language but don’t consider it a panacea for security.

Even extremely popular libraries like OpenSSL have been repeatedly shown to have various vulnerabilities that can compromise a server or even a client. As a more advanced technique, it may make more sense to utilize a restricted library such as AWS’ “s2n” or OpenBSD’s “LibreSSL”.

Implement easy but secure firmware updates

Expect the need to update the device after it’s been released, and potentially often. New vulnerabilities are announced often, and they might impact the platform. Because of this updates should be as easy as possible for the end-user to apply, if not automatic. All updates should be securely signed with a cryptographic algorithm.

The signing key should be closely guarded. Since firmware builds and signing isn’t a frequent process, it should be stored in a Hardware Security Module, physically backed up to a secure environment, and should also require more than one actor to unseal it to allow a firmware to be signed. This will minimize the ability of a malicious person compromising the firmware release with their own infected version.

Operate a bug bounty program for both device, app, and cloud environment

Keep in mind that even after pentesting security isn’t proven, especially if updates are being released. Consider setting aside a “bug bounty” program that rewards people for finding vulnerabilities in your stack instead of selling them on the black market or using for their own gain. The incentive is a sizable monetary reward, so avoid skimping or downplaying too much on a vulnerability’s significance.

Build trust with long-term support

Supporting the device beyond the initial release is a requirement nowadays. If you want your device to be trusted and minimize the chance of an end-user converting to a competing brand a long-term support plan must be in place. Fortunately that might also work to require a subscription depending on the market. Some products are moving to a subscription-basis, otherwise that long-term support cost needs to be factored in. A main issue though is that a device that’s still usable without a subscription can later become vulnerable and depending on the severity an update could be expected anyways.

Use a trusted vendor known for security

Similar to how an end-user trusts the device brand, a brand should trust the vendors of its device’s hardware and software. Several questions are helpful to get an idea: How often does the vendor release new updates? What versions of OS and libraries is their platform compiled with? Is their hardware also physically secure or does it also have easy attack vectors like an exposed JTAG? Does the vendor operate their own bug bounty program?

The main question to consider is after an exploit is announced, how long does it take the vendor to release an update? If it’s on the order of several weeks then the devices are sitting ducks. Once a vulnerability is publicly announced hackers are working on producing exploits within hours, not weeks.