On IoT and security

Is it time to make smart devices dumber?

Favorited Favorite 0

On October 21st, there was a coordinated Distributed Denial of Service (DDoS) attack on an internet infrastructure company called Dyn. The attack resulted in a nationwide slowing of many web properties on the internet.

alt text

The image above shows the areas affected by the internet outage. This attack had widespread effects for hours that day.



The attack was strongly assisted by Internet of Things (IoT) devices that still had the default, out-of-the-box username/password configured. This was a low moment for the IoT world. Changing default logins is basically Security 101. I can clearly remember in just about every training class I’ve ever been in -- whether for hardware or software -- that there is a default, and the absolute first thing you have to do is change the password. On the flip side of this, one of the first things you learn when you learn to hack is to look to see if the default has been changed, because people don’t always change it. Friday the 21st showed us what can happen when you don’t.

IoT, The idea of "smart devices" that don’t require human interaction, is growing up fast. There are more devices out in the wild every day. In fact, we sell them. The ESP32 Thing is another example of a device, in the wild, that is perfectly suited for helping you create great IoT computer systems.

SparkFun ESP32 Thing

SparkFun ESP32 Thing

DEV-13907
$21.95
61

IoT systems are computer systems, and computer systems are inherently insecure. An individual computer will have clear vulnerabilities. Networks will have flaws. The Zero Day attacks will always exist. It is simply true that the business of computer, network and systems security is large in and of itself because the threat is ever-present. IoT will probably not be any different. We've seen this issue with large distribution of firmware problems before, and we'll see it again. The fact that IoT devices are computers makes them at once the same and, because of the scale, pretty different.

There will be no magic bullet for IoT, just as there isn’t for any other type of compute device. Any device inside of an IoT system will be a vector for attack.

Smart devices, or IoT end points (basically any compute devices on a network), need to become dumber. If you are going to have a large-scale network of nodes, they need to do less, especially if they are commercially built. These devices will be inherently smaller and have less compute power. Running complicated security routines on the device will be one of the first things removed in the name of cost and simplicity. In my opinion, more things should be removed. Devices become a problem when a standard function gets exploited. Maybe it’s time to strip down what these devices can do and simplify their functionality.

Simple firmware that shouldn’t inherit extra functionality includes protocols designed from the ground up to do the simple tasks their creators actually intended, and nothing extra that doesn’t need doing. Do you need a single-board computer for this, or will a microcontroller with a simple command and no way to remotely update the code work in your situation?

How can you make your system safer? I asked this very question to friend of SparkFun Josh Datko. Here is what Josh had to say:


When I talk about this I consider three entities:

  1. How does the maker secure their projects?
  2. How does the consumer buy secure products?
  3. How does the professional engineer build secure products?

For all of them, the answer is to think about what's called in security jargon a "threat model" – basically, a risk analysis. So I'd say to the maker, if she is trying to blink an LED over WiFi for a demo, the security needs are probably pretty low. BUT, what happens with that ESP32 when you are done? Did she wipe the WiFi creds before throwing it away?

The answer to #2 is a bit harder. Right now, we don't have a good way for consumers to know things are secure. But what I say is, "Do you need that connectivity feature?" For example, take smart door locks. I would never buy a smart door lock; I don't want it connected because, to me, the risk of electronic attack is greater than the risk of physical lock picking.

However, UL is making a good effort here. There is a new standard, UL 2900 (full disclosure, Josh is on the technical panel), where vendors can get a UL certification for their product. It's a pretty comprehensive certification.

I do think certifications will help the industry here. It puts the onus on the OEM, where it belongs. UL 2900 isn't a silver bullet, as you point out, but it is progress.

Finally, #3 is harder still. It's the same answer as to the joke, "How do you get to Carnegie Hall? Practice." Building secure stuff takes study and practice.


With Josh's thoughts in my head, I want to give you some things to think about when trying to make your system more secure. Think along the lines of the threat model:

  • At every link in the chain, what is the security layer?
  • Can I remote into the device? Do I need to?
  • Did I change the password?
  • Do I have a better method of gaining access? Network?
  • Did I create a standalone IoT WiFi network? Is it secure? Does it share passwords or connection points with anything else in my home?

What about servers? Do I have passwords on them? Are there safer ways to connect? (There are.) Am I using a third-party system? Is the password on that different from other systems? Is two-factor authentication an option? If so, turn it on!

Does this seem like a lot? It should – security is complicated.

Michael Collins, a good friend of mine, just happens to have actually written the book on network security. I asked Michael about these issues as well, and his response was perfect: "One of my basic points about security... security is restrictive. Security is fundamentally about restricting functionality, whereas most design is about broadening it."

The devices that SparkFun sells are open by design. When discussing the concept of security vulnerabilities with our hardware, our engineers see them as an accessibility feature designed to lower the barrier of use for our products. They are right. The problem is that access, by its very nature, is insecure. Making devices that are simple to connect means they’ll be a little less secure. Hopefully you can follow our advice and ensure that a device with a little less security is now connected to a network with a bit more as the trade-off. Worried that isn’t enough? You can always grab our CryptoShield:

SparkFun CryptoShield

DEV-13183
1 Retired

Overall, good computer and network security practices don’t go away with IoT; they actually become more important. If any compute device, end point or node in the network can be vulnerable, having more of them can only increase the problems. IoT security will be a field in the near future, but it is just an extension of the computer security field as it exists now.


Comments 13 comments

  • Tutorial idea: Basic IoT/network security. Topics could include disabling unnecessary functionality in common hobbyist boards, segmenting one's home network into multiple VLANs, and setting up separate wifi networks for IoT devices.

  • I have a few comments:

    BUT, what happens with that ESP32 when you are done? Did she wipe the WiFi creds before throwing it away?

    throwing it away? That is HORRIBLY WASTEFUL! Things like the ESP32 Thing should be REUSED -- put it "in the junk box" for future use. While it's in there, it's pretty safe. I've yet to hear of a "bad guy" break into a computer that is powered down... other than in the fantasy world of Hollywood (or should I say "Hollyweird").

    Next, WHY do we persist in putting "full stacks" into these things? Yes, the laptop computer I'm typing on needs a "full stack" -- it's hard to predict what URL I'll want to look at next, so it needs to be able to be able to do an IP address lookup for anything I feel like putting in. However, if I had an internet connected thermostat, or fridge, or toilet, those devices should NOT have the capability to get a DNS lookup. From my understanding of what happened on Oct. 21, though I may be wrong, if the "cracked" baby monitors had only been capable of going to very specific IP addresses (likely only one or two), that DDoS wouldn't have happened.

    I also have a problem with using DHCP servers: in my home network, I use only static IP addresses, and my firewall only allows a precious few of them to have masquerading access to the Internet. There's no legitimate reason, for instance, why my printer should be looking at, say, Amazon.com! (I also protect against "war-driving" by using wired networking.)

    Being able to transfer data (e.g., temperature readings), over WiFi is one thing, but being able to program my IoT stuff, IMHO, should, in general, require that I physically plug into it. (I will make an exception for things that have a full Linux OS, like Beagle Bone Black or Raspberry Pi, as they are not in that "grey zone" between being too stupid to cause harm and not smart enough to be able to implement good security. But I acknowledge that the average consumer probably should not be entrusted with this sort of thing.)

    There's also one glaring thing that the so-called security experts always seem to ignore: Just as important as keeping the "bad guys" out is making sure that the owners of the system DO have access to it. (I get really sick of fighting insanely paranoid security when I install mySQL on a new VM that has zero access outside the computer it's running on.)

    • Good point about not throwing it away. Thinking about how these boards are used by Maker Spaces to do projects and then possibly put back in a bin for others to use, boards should be able to be wiped before returning to the bin. In the DOD world if a board with Non Volatile memory is plugged into a classified network that board must be maintained in a secure environment unless it has a sanitization procedure to wipe all non volatile information. Perhaps SparkFun can include on the product page a sanitization procedure or some executable that can be flashed onto the board and run that will remove all stored user parameters.

    • You're point about local access with mySQL is the perfect example of restrictive (security) or permissive (easy to use). The fight is always there. mySQL is widely distributed and is used in a lot of stacks. If the default is to be restrictive, it is the decision they made, but it annoys or hurts casual users when they are just trying something out.

      • I can see two reasonable solutions (and note that they are NOT mutually exclusive):

        • Have documentation that CLEARLY explains how to get it set up and going "despite" the built-in paranoia
        • Have a separate non-paranoid build (or an install option) that makes sure that's the version you want

        FWIW, I ran into the problem trying to set up mySQL to be able to develop some stuff "off-line" that I would then later transfer to an account at a hosting service. I want to have some degree of confidence in the system before it goes "live".

    • I hate to say it, but implementing a full stack on any IoT device is probably laziness masquerading as efficiency. It's much simpler to throw a standard stack library at something than to go through and create a custom stack that only has the features needed. In the hobby realm, the person crafting their own IoT device may not know enough of how a stack works, but they want to be able to control the flashing LEDs from their phone. In industry, not many organizations want to pay for someone and/or spend the time to reinvent a caster-wheel when the off-the-shelf skateboard truck will work. (Ok, not a perfect analogy, but hopefully you get the idea.)

      I don't know what (if anything) can be done for the hobbyist besides having educational material available, but industry doesn't change unless they have a reason (either market pressure or regulation).

      • People provide the market pressure for products demand to know the security modules in your products.

        With IoT, if consumers feel threatened by a lack of security, they could forgo adoption of the platform all together.

        • The average customer isn't going to know what the current state of the art consumer security models are. The average customer thinks the internet is the broswer icon on their desktop. The details are just too confusing and obtuse for Joe/Jane Customer. They just want things to work.

          We as more informed consumers (who are usually answering the "what should I get" questions from our friends and family who are Joe/Jane Customer) need to be the ones spear-heading market pressure. While regulations can provide a baseline, the way legalese works any regulation needs to be very specific and will significantly lag behind the threshold of state of the art. (Yes, once upon a time WEP was state of the art in the consumer world.)

          But, I've started to see a little gleam of light... I recently was setting up the latest Verizon FiOS router for my mother and while I couldn't change the admin username from "admin", the default password actually looked like it came out of an algorithmic password generator. Recognizable syllables from english strung together with digits into a nonsense word. Less hard to remember than truly random, but was long enough to appear be fairly secure.

          • I see SparkFun customers on the forefront of technology (and that isn't me shining apples, it's true) and instrumental to helping develop and implement and champion these solutions. That's why I've been pushing these ideas and why I'll continue to push them.

            When I go and talk at conferences, I'm not pushing our products (well, just a little). I'm calling for the community to step up and work with us to solve the big challenges we are going to face. We face these challenges together and a solution found together is the answer.

            A secure and open internet is important for the world.

  • Try not to take your own IoT gadgets to work. There are loads of potential security attentiveness toward wearables. Each endeavor ought to have an unmistakable BYOD approach, and it's regularly a smart thought to deny individual IoT gadgets from associating with the system, or if nothing else restrain them to a visitor arrange. Track and evaluate gadgets. Organizations need to track everything associated with the system and screen the stream of movement. Gadgets should be evaluated to decide the level of get to they ought to have, to keep them completely fixed and state-of-the-art, and to secure information end-to-end to safeguard its respectability (read more). Obscure gadgets ought to hail a caution. Understanding which gadgets are associated and what they're doing is an essential for appropriate security.

  • We also need to consider other aspects of "security": My girlfriend has this habit of mislaying keys, cell phone, etc. Her sister sent me links to a couple of "tag" thingies that work through Bluetooth to do short-range "make a beeping sound" commands, either from the keychain or "wallet card" to the phone or vise-versa. The problem comes that they include an "app" that "crowd-scans" for "missing" items, and if a reported-missing tag is noticed by some stranger's app, then it sends you a message with the GPS reading from the stranger's phone.

    Nice idea on the surface, but BIG security risk! Some cracker can figure out how to know when YOU are away from home, making it safe[r] to break in.

    I nixed the idea based on that. (There are also questions about battery life, but the ones with replaceable batteries will admit to a bulk-order of batteries from DigiKey rather than buying them onesie-twosie from the corner drug store at outrageous prices.)

  • Actually it is worse than you describe.

    Many of the devices had telnet and SSH available without the ability to change the password for those protocols, or to disable them.

Related Posts

Recent Posts

Tags


All Tags