Hacker News new | past | comments | ask | show | jobs | submit login
IOT Developer Security Checklist (sensedeep.com)
70 points by aeronautic on May 25, 2017 | hide | past | favorite | 34 comments



There's a fundamental problem here, and I don't know how it should be addressed. I agree that manufacturers should be able to silently patch firmware for security holes. But I decidedly do not want them silently adding, removing, or changing functionality.

I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a changelog, and I don't want to have to do this on someone else's schedule.

There seems to be no technical way to allow manufacturers to provide transparent security updates without also allowing them to pull the rug out from under you when you least expect it. I think we need some sort of social contract for this, but unfortunately my view seems to be a minority one, given the amount of bullshit that the public seems to tolerate from self-updating devices and apps.


Very good point. Even requiring the user to specify a maintenance window can ruin the experience.

Some patches should be able to be made "hot", but that takes extra ram which is often squeezed to a premium in a device.

I would recommend:

- We not put devices on the internet that do not have a core, hard requirement to be on the internet. This rules out toothbrushes, toilets, pillows etc.

- Devices do not open listening ports and only connect out. This eliminates a whole class of shodan visible attacks.

- Devices give users some option of when an update is required and when the user can apply it. If the device can be managed via a HomeKit or Phone UI - these options can be made pretty usable. Alternatively a yellow light on the front of the device if suitable to indicate an update is available.

Regardless, the current path of listening devices on the internet and not being patched is untenable.


What you seem to propose is a separate stream of updates and security fixes. For this to work the way you describe would mean the company releasing all security fixes for every revision of updates. That's a lot of work in testing, release management, and support, and I don't expect any small sized company to bother.

Actually, I don't know of any project that does this - you may get fixes for a number of supported releases, but the expectation is that you upgrade at some point, or its eol for your product.


If you compare to the Linux ecosystem, you can see why IoT upgrades are broken. In the Linux ecosystem, software releases are typically independent from packaging, as well as from package managers and their update configurations, allowing users the freedom of being somewhere on the spectrum from completely unstable rolling release distributions to highly stable releases like Debian Stable. Software which auto-updates itself, instead of relying on the package manager to update it, is widely considered to be an anti-pattern.

IoT needs a packaging ecosystem to protect the freedom of its users, instead of allowing IoT devices to independently connect upstream to the manufacturer to get updates. Of course, auto-updates should be the default, because most users won't pay attention, but the user's freedom should be protected and preserved.


The packaging system is only a part of puzzle. I can control what happens with my Linux laptop, but it's much harder when 10+ devices around you are constantly updating. There's also the thrust issue - we all want exploit patches to be applied automatically while feature changes are different thing altogether (remember when Sony pushed update to PS3 that disabled OtherOS support).

Maybe a good legal solution would be to allow automatic updates, but only if user is informed about changes and she can downgrade/revert at any time. Also, the stuff that Microsoft does with Win 8/10 upgrading should be punishable.


You could get your operating system from one vendor, while the application code be inside of an isolated container from the product vendor, with you easily controlling changes to each one. Same could go for the cloud.

I think Android things is built around this idea, with manufacturers having no control on security updates.

For simple, standalone features, this could work well. But when your features are dependent on interacting in some way with other people's connected products, this might not work.


Realistically, IoT devices are and will continue to be made by small development teams under considerable time pressure with little motivation to care about security over the life of the product.

One solution to this problem is to institute consumer protection laws that say that consumers can return the product for a full refund if an exploitable security flaw is discovered in the device, and that products must disclose the privacy implications of using them.

Another option is to improve the software ecosystem for IoT to the point where everything is secure-by-default and you have to go out of your way to do something in an insecure manner. That will require a lot of careful API design and probably abandoning C and C++ in favor of something safer. (Rust seems like the most promising alternative at the moment.)

A useful test of whether or not we've succeeded is whether a hobbyist with basic programming knowledge can, with low effort, deploy a custom embedded device that connects to the Internet and have high confidence that it isn't a privacy threat or vulnerable to known security attacks and it will continue to be secure for the life of the product.

I think the full solution has got to be some mix of consumer protection laws and better tools for deploying secure devices. Maybe also some third-party validation organization could get involved, analogous to UL listing for electrical things.


Agree.

While I love rust and think it (should) replace C for web servers and the like, the majority of the issues with IOT devices are just basic security oversights and design errors.

You raise some very good points:

1. Secure by default should be mandatory. MS learned that one the hard way.

2. Consumer protection laws would certainly get device builders attention. I think that is required. But I doubt the current administration is included to enact such laws.

It is a shame that devices are certified by UL and FCC, but there is no security certification or even a basic audit that would catch: security backdoors, default / blank passwords, auth over http, basic XSS and CSRF vulnerabilities etc.

The bad news is that we don't know how to design a device with Linux and internet services that will be secure without updates for 5-10 years. So we either insist on updating .... or we keep some of the darn devices off the internet.

At at minimum, we should insist on having devices that don't listen on ports just waiting to be hacked. Devices should only connect out.


I feel like the first two items on this list should be:

- does this really need to be online?

- really?


I like to use the XYZ metric. (aka: eXamine Your Zipper)

  1.  Does the zipper on the fly of 
      your pants need to be automated?

  2.  Does the zipper on the fly of 
      your pants ever need costly repairs?

  3.  Does the zipper on the fly of 
      your pants need regular maintenance?

  4.  Does the zipper on the fly of 
      your pants expend disposable accessories?

  5.  Does the zipper on the fly of 
      your pants need to be context aware?

  6.  Does the zipper on the fly of 
      your pants require internet connectivity?

  7.  Should the zipper on the fly of 
      your pants be controllable via cell phone app?

  8.  Should the zipper on the fly of 
      your pants monetize potential advertising space?

  9.  Should the zipper on the fly of 
      your pants collect behavioral analytics?

  10. Should the zipper on the fly of 
      your pants enforce DRM policies?
A sort of 10 commandments of IoT, if you will. Shockingly, some people will answer an emphatic YES to all questions.


Your list is very cynical. "If zipper doesn't need it, why should your TV have it?" This way of thinking prevents the benefits we could have as appliances around us become connected, once the security issues are addressed.

Let's use the fridge as an example:

1,5) I don't need it to be automated, but I would love to get notification when food's about to go bad or when we are out of milk. Temperature is already automated, but we could squeeze out more efficiency if it was context aware and more intelligent (it could keep some compartments on higher temperature than others).

2,3) Appliances sometimes need maintenance anyway, but preventive maintenance would be less costly.

7) Phone apps are terrible way to control anything, to me they are just a stop-gap solution until something better comes (reliable voice control for start, then AR interfaces).

8) This would lower the cost and allow poorer households to own one; I don't mind advertising if full price gets rid of them. Kindle is great example.

9) YES! But for my benefit, and not for benefit of manufacturer and third parties. My fridge could recommend new interesting meals based on my cooking. It could also warn me about unhealthy habits and help with my diet. Over the years it could improve my quality of life without significant effort from my side.

10) No. DRM should not exist.


By my purely speculative opinion, only 4, 5, and 6 apply to televisions, and only 4 applies to refrigerators.


I'm afraid #9 is only a matter of time... sort of the same idea as the "Progressive Snapshot" device.


Love it.


I know! Why do device manufacturers need to be pushed for this? We consumers keep buying stuff that has been put on the internet with little to no thought about security today or tomorrow.

IOT will get much worse before it gets better. I say this from working with device builders for 2 decades. The level of attention to security is sadly lacking.


I think that consumers aren't actually the target market for most of this always-connected-always-listening device stuff. The real products that are for sale are the data these devices generate and the distribution channel that third parties can buy access to that these devices enable.

There's an old saying that "if you aren't paying for the product, you are the product". That saying might need to be updated to reflect modern times, that "if you aren't paying for the product and maybe even if you are, you are the product".

There may also be some manufacturers who put stuff on the Internet not as a deliberate effort to monetize their customer's lack of privacy, but simply because they've bought into the marketing of other device makers and are convinced that some of the features they can enable by being always connected will make their product more desirable.


The guidelines appear rather rudimentary. It is a sad state of affairs that IoT developers need these.


I know, it is a very sad state of affairs.

In doing IOT for 2 decades, this is probably one of the biggest issues. At best, most devices have a "download firmware" option that 99% of users can't operate.

I could go on about dozens of other issues, like back-door field-service passwords, http not https, passwords in the clear, endless XSS vulnerabilities, but this is one of the biggest.


Maybe I'm missing something, but is the general consensus on HTTP Auth that it's poor security? I've seen is suggested a lot of (e.g.) authentication in webapp <=> api scenarios. Specifically to use it to pass the initial username/password, and then stuff an session token into it (after login). What are the added security risks of this (so long as it's done over HTTPS)?


For webapp <=> API it's pretty much the same as any other header, but with a subtle semantic indication that the value associated with the header is being used for authentication. Generally the value is a password or a bearer token. The problem is that this token is usually not channel bound (can be stripped and used elsewhere) and often has broad authorization associated with it. The security characteristics depend on lots of details. Usually when people say not to use HTTP Auth they mean don't send the username / password in base64 encoded cleartext over the open internet, as suggested by early HTTP RFCs.


Do you mean basic & digest http auth built into the browsers? If so, yes, they are bad. The issue is you cannot reliably implement log off on all browsers.


Is this still true, for any browser that is still used? It seems a couple of decades would be long enough to get this right...


Still true when I tested last year. The core protocol does not have a defined way to get the browser to forget the login.

You have to resort to different fudges on different browser.

Net/Net: the http auth ui sucks, has bad usability, weak crypto, and is not robust with logout.

HTML/form based auth can be made robust and is a preferable alternative in every case.


I'm taking about using the 'Authentication: ' headers, not relying on the browser's handling of auth (other than making the requests).


Beginner question: what about if the device doesn't accept over the air updates? What sort of security concerns are there for such a device that wakes up periodically to send data over HTTP.


You still have to defend against MitM attacks, that could steal your data. A recent example is Samsung smart TV that could be controlled with voice. If someone can route TV connection to his server posing as Samsung's server, she can eavesdrop you in your living room.

Another problem is that during the lifespan of product, several critical exploits could be found that would compromise the security if not patched. There already efforts to defeat SSL and we may need to upgrade to more advanced protocol in near future.

One last problem is that in your case the device needs to have server address hardcoded. The company could go out of business and you would have no way to redirect it to alternate unofficial server. Therefore, firmware upgrades are pretty nice to have in IoT.


If the device does not listen, i.e. it calls out, then it is inherently much more secure. However, many devices use an embedded web server and do listen for requests.

If the device does not listen, and polls regularly for updates, then that is fine ... perhaps even ideal.


Sure the list has valid points, but those don't pertain anymore to IOT than any other internet connected application.


True point. The difference is that enterprise apps understand the need to patch and update. IOT devices and device builders largely do not.

IOT devices today look pretty much like any other internet device too. Linux, good CPU horsepower, ample memory and internet connection. More than a few exploits that work on enterprise servers can be adapted for IOT devices.

Add to this a lack of awareness of basic security issues among device builders and you've got a problem. That is why we are seeing so many security issues with IOT devices.


> lack of awareness of basic security issues among device builders

I'd hate to think users were just as guilty, after all that would implicate me, but much of the IOT functionality should be firewalled or restricted to LAN, if access via handheld is the target rather than turning the stove on while on vacation. Regarding manufacturers from the POV of a consumer, they should just build devices without malfunctions. That's not a matter of security but quality.


IoT security is a messy problem, quite frankly. Most (is it safe to say all?) of us carry around IoT devices with us every day that are based on software with documented, in-the-wild, security issues -- and the Android ones of us are the most at risk depending on the age, manufacturer and carrier of the device.

I agree with the author's original assessment -- don't make your device internet connected (or even capable of connecting to the internet), if there's not a spectacularly good reason to do so. The downside is just too big, currently. If you plan on it, you need to proceed extremely cautiously and understand that huge companies with top-tier engineers -- Google, for instance -- haven't figured it out completely, yet. While their devices are probably better secured[0] than the IoT white-label power outlet I purchased on the clearance rack at Aldi (US), they still have a long way to go. Is that feature that allows your dish washer to send you push notifications when it's completed worth the lifetime of security patching you're going to have to do (or going to fail to do at your customer's peril)?

The biggest problem with IoT as it's done, today, is a simple one of attack surface. Every device independently accesses the Internet with a poor gate-keeper -- often a consumer-grade firewall which we hope is configured to properly firewall inbound, but is probably also running an out-of-date kernel, or has some other security vulnerability[1]. For the simpler devices, I lean more toward using the 'hub/Z-Wave/Zigbee' approach. At least with a hub, I have one device that is directly on the internet, and several that can't do much beyond talking to the hub. The problem here, though, is that none of these hubs are aiming to be the "leader in security in the IoT space", (which is why my hub is a custom-configured Linux box w/Z-Wave/ZigBee dongle[2] which I can harden myself).

The problem for most IoT devices is one that I don't see an easy solution to -- a common configuration is one of a low-capability device with a general purpose operating system on it with custom software probably written by engineers in a company that is too small to afford the necessary security auditing required -- and, effectively, putting it in the worst war-zone you could put it in. And consumers pretty-much don't care (yet), they just want the feature[3].

There was also one feature I felt was missed by the author, a hard cut-off switch[4]. We put valves on water-heaters, appliances that connect to the gas line, and just about anything of circumstance that connects to electricity. If all else fails, or if I just really wanted the Thing part of the device, I can take it off of the network in a way that leaves no ability for the software powering it to bypass. In a critical situation -- one where something prevents the device from being patched and the device will be recalled, the company can send along instructions[5] along the lines of 'you can still use it while we work out the logistics of the recall, but it'll just be a Thing without any Internet).

[0] I'm thinking 'home' rather than the general Android ecosystem since a lot of Android's problems are related to the phone vendors and carriers (at least in the US).

[1] And with IPv6 rolling out from ISPs, how many of these devices will have public IPs that will be able to be discovered every time they reach out to pick up the current time. Don't think that can't happen -- I was shocked to find that my dad's PC had an IPv6 address and a quick check from the first hit on 'IPv6 Firewall Test' yielded all red. I'm not sure how many of these devices have IPv6 enabled by default, but I wouldn't be surprised if some vendors enabled it (or didn't realize it was enabled when it was).

[2] Which have their own problems -- but the worst they could do is turn my lights on and off ... at least my lightswitch won't be participating in a bot net AFAIK. I also don't own any ZigBee door locks or the like (however, I can personally attest to the low quality of the physical lock I do have after spending a Saturday on YouTube making a 'key' based on a video that showed how to break my specific, Schalage brand 'high-security' lock).

[3] I've said more than a few times that I need to attach a smart plug to my washer and dryer because the buzzer is too quiet to hear and I always forget about my clothes during a cycle. It'd be nice to get a text message. It's a stupid feature when measured against the risk (though, as mentioned, my smart plug isn't directly internet connected).

[4] 'Hard' as in a mechanical switch that actually disconnects the Wi-Fi/network module from the hardware.

[5] And the honest ones will ship with the button in the 'off' position with the 'Connecting the Device to the Internet' part of the instructions explaining what it does, how to enable connectivity, and a little bit about the risks they're entering into by choosing to connect it.


If IoT is a messy problem and Android is the device most at risk depending on the age, manufacturer and carrier of the device then where are all of the Android based IoT attacks? Android has been around for 10 years and nothing has materialized. What ever happened to the supposed armageddon like the one predicted by the technology blog pundits when Stagefright was revealed? The fact is that not 1 Stagefright exploit has ever been seen in the wild by Google's SafetyNet telemetry system. And even if an exploit does manage to bypass the Android security mitigations in place the diversity of the ecosystem makes it so that an exploit for one device isn't going to work on a device from another OEM.

The real source of all of these IoT attacks are linux based IoT devices that have been compromised by users not changing the default login credentials or attackers using one the many Linux exploits available. And I won't even get into the never ending damage inflicted by Windows. That's what you should really be worried about.

Here's a video of how Google plans to secure their Android Things IoT devices. If another company has a better plan than what they presented at I/O 2017, short of unplugging it from the Internet, then I'm not aware of it.

https://www.youtube.com/watch?v=U4QBI4PJj8Y


Step 1: stop it.


The truth is, IOT is, if not exactly, a natural monopoly, certainly something that benefits from economies of scale.

Fifty extremely experienced security engineers can come up with a pretty good IOT security infrastructure in six months.

But should EVERY company have to reinvent that wheel, somehow finding 50 extremely experienced security engineers, and making them do that?

What would work better is if the fifty extremely experienced security engineers did it once, in a way everyone can use.

I must say I do trust Google to autoupdate my Chrome (haha, as though I had a choice), and they can do anything on my computer that they want. It's not a big stretch to let them autoupdate my lightbulbs, toaster, fridge, anything else.

I think Google should get on the ball and centralize IOT security. (Uh, no, not by putting android on everything.) It would be a pretty natural fit for them and not that big of a burden.

I mean what are these small companies supposed to do? There is a natural market opening.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: