Using unencrypted protocols with IoT devices

Question

Old IoT devices and some low-power devices are not capable of doing encryption or use weak encryption methods like TLSv1.0. What could be the risks of using such devices and unencrypted protocols like HTTP?

Answer 1

The same as using plaintext (unencrypted and unauthenticated) communication elsewhere.

What exactly that means, depends on your threat model.

Smart Bulb, Dumb Protocol

Imagine you had a smart lightbulb in your home. You could use an app to control the brightness and the warmth of the bulb. It even offers an API, so you can control it via a Raspberry Pi too, if you wanted. Sadly, the bulb doesn't offer HTTPS, so all your communication is in clear text.

It may sound terrible, but it's probably fine. Why? Because in order for an attacker to do something about it, they'd need to be in the same network as you. And if the attacker is already in your home network, then you probably have more problems than a dumb smart bulb.

But what could an attacker do?

For once, an attacker can read what you send to the bulb, and what the bulb sends in return. This is most likely something like:

POST /api/brightness HTTP/1.1
Host: smartbulb.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

brightness=0.73

And the response would be something like:

HTTP/1.1 200 OK

{"error":false, "status":"STATUS_SUCCESS", "data":{"newBrightness":0.73}}

All in all, very boring data. Yes, technically, your confidentiality was violated, but in this scenario, that's not very problematic. The attacker knows your bulb is set to 73% brightness.

Of course, an active attacker could do more. They could modify what you send to the device, and also what the device returns. Depending on what you do with the data, this might be dangerous.

How can I protect myself?

You can't. Well, technically you can, but it requires some fiddling. Okay, a lot of fiddling. If an IoT device does some task like sending e-mails, but doesn't encrypt them, you can at least use a proxy to remove any sensitive information before an e-mail is sent. It's a lot of work, and will give you very little benefit.

It's easier to just forbid communication with the outside world, if this is possible.

How can developers fix this mess?

Developers can use ciphers specifically designed to require low power consumption and low memory requirements. Yes, it'll make the product more complex to design, and it will make the end result more expensive, but it's more secure than the alternative.

Answer 2

The big concern with unencrypted IoT devices is not just privacy issues so much as the vulnerability of the device itself. Let's say you have a smart refrigerator that sends unencrypted API calls to a server that also communicates with the app on your phone to let you know when you need to buy more milk.

IoT devices with unencrypted connections tend to have have a weak security posture across the board. (No anti-virus, no SFW, weak data validation, etc.)

If that API call gets intercepted, a bot could correlate the package parameters with a known vulnerabilities list to determine that you device belongs to a family of vulnerable products. The bot then responds to the API call by swapping out a normal data parameter with a script injection. This injection then executes to add your device to his bot net that he can then use for doing anything from launching DDoS attacks to bitcoin mining. You may not personally notice a huge difference other than your refrigerator becoming a bit unresponsive or a slight increase in your power bill, but, it can make you an unwitting accomplice in cyber crimes that can cost other people millions of dollars.

But, maybe you don't care about other people? ... well, there is also the issue that the transmission to the server may be modified as well. If the server itself accepts a malicious injection, then it can pass that injection along to the app on your phone that is supposed to receive the notice. When your app executes the injection, there is the possibility for it to do all sorts of things which could lead to compromised credentials, PPI, etc.

The MITM attack vectors on unencrypted connections are so numerous that in many cases, an attacker will be able to find at least one that works, but properly encrypting your connections makes it impossible to analyze your traffic to begin with which prevents them all.