
IOT Developer Security Checklist - aeronautic
https://simplesecurity.sensedeep.com/do-not-internet-enable-your-device-a02cdb0372ec
======
ohazi
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.

~~~
solatic
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.

~~~
veli_joza
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.

------
elihu
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.

~~~
aeronautic
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.

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

\- does this really need to be online?

\- _really_?

~~~
pavement
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.

~~~
veli_joza
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.

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

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

~~~
aeronautic
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.

------
pyre
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)?

~~~
aeronautic
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.

~~~
jessaustin
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...

~~~
aeronautic
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.

------
seizethecheese
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.

~~~
veli_joza
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.

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

~~~
aeronautic
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.

~~~
trobayhasteman
> 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.

------
mdip
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.

~~~
bitmapbrother
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](https://www.youtube.com/watch?v=U4QBI4PJj8Y)

------
659087
Step 1: stop it.

------
logicallee
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.

