Slashdot Mirror


Security for the 'Internet of Things' (Video)

What happens when your oven is on the Internet? A malicious hacker might be able to set it to broil while you're on vacation, and get it so hot that it could start a fire. Or a prankster might set your alarm to wake you up at 3 a.m. - and what if someone gets access to the wireless security camera over your front door and uses it to gain access to the rest of your home network, and from there to your bank account? Not good. With the 'Internet of Things' you will have many devices to secure, not just a couple of computers and handheld devices. Timothy Lord met Mark Stanislav of Duo Security at BSides Austin 2014, which is where this interview took place.(Here's an alternate link to the video.)

16 of 106 comments (clear)

  1. Here's how to secure your "Internet of things" by ArcadeMan · · Score: 5, Informative

    Don't buy things that connect to the Internet.

    1. Re:Here's how to secure your "Internet of things" by zarthrag · · Score: 2

      Additionally, they should be on an isolated internal network, wired whenever possible. A server or appliance in your house can manage said "things". Every single vendor who supplies you with 'things" shouldn't force you to use their (likely vulnerable) web portal or service, just supply some drivers/documentation, and part ways.

      --
      Why can't all fpga/microcontroller manufacturers just release free optimizing compilers???
    2. Re:Here's how to secure your "Internet of things" by mlts · · Score: 4, Insightful

      Why should they be on a network at all? My refrigerator does just fine with a basic thermostat, electrical fusing, a device to pour water into a mold, dump it in a bin when frozen, then stop dumping it when the bin fills up, a switch to turn on the light when the door opens and a fan so it runs without the need to be defrosted. The additional gewgaws don't help with core operation.

      Same with a stove or a microwave. For safety's sake, it should only be able to be turned on by someone who is physically present.

      Sometimes, there is just no real point in adding a device to the IoT, and the fewer devices that have networks, the fewer attack vectors an attacker will have to operate with.

      This doesn't mean that isolated networks are bad... for example a vehicle needs the CANBus. However, if one doesn't need to have that functionality in a toaster, why built it in?

      If we have to have a network or bus for statuses, why not a read-only bus, essentially like a serial port with the return line cut so the device can send status messages out, but not have them go back. The basic concept of a data diode. This way, one can tell if their fridge is over temperature, but a blackhat can't log on and turn the fridge off and spoil someone's steak stash.

    3. Re:Here's how to secure your "Internet of things" by epyT-R · · Score: 2

      But it will give bureaucrats the opportunity to set the thermostat to politically correct levels, and give the refrigerator and food vendors the opportunity to overcharge you for value added services, like 'pay us or it stops working'. Don't you want that?

  2. don't connect it by fluffy-the-dest-6649 · · Score: 4, Insightful

    why the hell would you connect your house to the internet or any appliance on the Internet anyway. Getting your appliance to work on your computer or a computer so you can control it via 1 pc for various aspect is fine but connect it to the Internet and no matter how secure it is, someone will find a way in. Best security is to NOT connect it on your Internet. Hell pretty simple concept to understand

    1. Re:don't connect it by kwiecmmm · · Score: 2

      Then you get a programmable thermostat that does not connect to the internet and you set it to go cooler at certain hours of the day and you setup a bunch of different modes (normal weekday, weekend, vacation, ...).

      Turn on your dishwasher and laundry as you go to work or go to bed.

      Tell your kids lock the door.

      All of this stuff can be done without an internet connection and should be done without an internet connection. But as soon as someone can hack all of a specific oven, heater, dryer or other appliance people are going to realize they don't want these things connected to the internet. Especially because huge sections of commercial companies don't worry about securing internet devices at the moment, and I doubt they are going to change that anytime soon. It may be naive to ask why someone would want this ability, but when you look at the most popular passwords used and other security indicators like that, it may be more important to ask should people have this ability?

    2. Re:don't connect it by Miamicanes · · Score: 2

      > why the hell would you connect your house to the internet or any appliance on the Internet anyway.

      So you can check up on your cats during the day while you're at work, and reassure yourself that the house hasn't gotten broken into in a way that somehow managed to avoid setting off the alarm. And dispense treats for them from the Magic Invisible Food God if you start to feel guilty about leaving them home alone all day. And drive the Roomba-platform-mounted webcam around to their favorite hiding spot (still working on *that* one).

      There's also the fact that more traditional means of remote home control (via phone) rarely work well with VoIP and voicemail. My alarm, for example, DOES have a telephone interface module... but it depends upon having an answering machine pick up the call so it can eavesdrop and listen for the triggering code. If the call rings until it goes to voicemail, the alarm never gets a chance to listen in and grab the call away from the answering machine. If the alarm answers the phone, and it was somebody calling, all it can do is play back a ~5-second .wav file apologizing and hang up on them. Did I mention yet that the way Android phones implement keyboard DMTF (playing a short pre-generated sample, as opposed to generating the tones on the fly in realtime), coupled with the way most VoIP codecs and mobile phone networks mangle DMTF, causes roughly 1 or 2 digits per dozen or so to fail to get recognized?

      As a practical matter, thanks to VoIP, voicemail, and mobile phones, you almost *have* to implement your controls via IP rather than dial-in unless you want to pay AT&T $35/month for a landline phone that you almost never actually use.

      That said, most internet-interfaced home automation controls are HORRIFICALLY insecure. If their interface consists of a Wiznet serial-to-IP module, and actually depends upon Wiznet's own password-based security, you should probably just assume it's been pwn3d several times over. ESPECIALLY if whatever's connected to the serial port end of the Wiznet module was designed to be physically connected to a real RS-232 serial port inside a locked cabinet, and all they did was strap the Wiznet module onto it. A security-free serial port isn't a great idea, but if it's inside a locked cabinet inside your house, it's pretty low on the list of concerns unless you have servants spending time unsupervised inside your home. That same security-free serial port strapped onto a Wiznet module with 8-character password (and with no rate-limit or lockout policy) can literally be bruteforced via UDP in a matter of days if the password is purely alphanumeric.

      ARM-based modules aren't a whole lot better, because manufacturers try to shave 17c from the manufacturing costs and cram everything into a few megs of flash. Of course, the first thing that gets cut when the compiled code is a little too big is the security. To manufacturers, security isn't a quantifiable selling point compared to features, and strong security raises tech support costs anyway by making the device more likely to NOT work for some non-obvious reason.

      IMHO, the only secure way to connect embedded hardware with minimal security to the internet is through a gateway appliance that shields them from direct contact with the internet, and acts as a proxy server/firewall/application level gateway. Preferably, running over a different physical network, and at the very least (if wire-sharing is inevitable), segregating the insecure devices into a different IP range that can communicate ONLY with that gateway.

      Note that if 100mbit ethernet is fast enough, you can actually wire two electrically-independent 10/100 ethernet jacks with a single cat5e cable (use green & orange for one, blue & brown for the other). If you pull two cat5e cables from every room to the wiring closet, you can use one for gigabit ethernet (possibly using a pair of layer VLAN-capable switches that support layer 2 IGMP snooping to isolate the "TV multicast network" from the "hom

    3. Re:don't connect it by epyT-R · · Score: 2

      The internet of things is not there to serve you. It is there to serve you to the customer: marketers and nosy government officials.

  3. iOS vs Android in the car by noh8rz10 · · Score: 4, Interesting

    I thought a lot about this when there were dueling announcements with iOS and Android in the car. The two approaches are completely different. The android approach is to be a central hub that all components can plug into, as well as you can download apps. iOS is the exact opposite, a gated system that only has access to the screen and input buttons. Android wants to be the car's brain, and iOS wants to be the car's entertainment console.

    The concern, what happens when a hacker exploits one of android's (many) security weaknesses? they have the keys to the kingdom. Can they kill the engine while you're on the freeway? in contrast, what if a hacker pwns your iOS? maybe they change the apple maps to drive you into a lake?

    The stakes just seem a lot higher when you start letting others into your car's electronics system. These also apply to other things, like the oven in the summary.

    1. Re:iOS vs Android in the car by Sloppy · · Score: 3, Funny

      If someone changing a map can "drive you into a lake" then YOU have already been hacked, and it doesn't matter how [in]secure your car is. You (not one of your computers) have been owned. You don't exist anymore, because your body (which had previously been a person) has become an unconscious fully-trusting map-executing machine.

      That's cause for concern, but I wouldn't worry about their computers' security problems.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  4. No Problem by Capt.Albatross · · Score: 2

    We can just secure our things the same way that the things currently on the internet - power plants, dams, oil refineries - are secured.

  5. Also, avoid shitty appliances by jandrese · · Score: 2

    If your oven catches fire because it was turned on too long, you have a defective oven.

    --

    I read the internet for the articles.
    1. Re:Also, avoid shitty appliances by CanHasDIY · · Score: 2

      >I think the general idea, at least in terms of this discussion, is that someone who can remotely access your stove via exploits can also probably bypass any safety mechanism that would prevent the stove from overheating.

      That weird assumption would seem to make the discussion pointless. There would be no reason to connect the safety functionality to the remote start functionality. If you build an over that poorly, you'd be sued out of existence the first time the shoddy design was exploited.

      And yet, we've seen evidence that automotive manufacturers have done just that - connected critical systema to non-critical ones, in a way so that compromise of one system equates to compromise of both - accessing the seat heaters through a CANbus tap also gives access to the brake and steering systems. I'd link to the recent demonstration of this particular hack, but A) pretty sure we all know about it by now, and B) inserting html is a bitch-and-a-half on this damn tablet.

      Anyway, while I may agree with the concept of total product liability, it unfortunately does not reflect reality.

      --
      An enigma, wrapped in a riddle, shrouded in bacon and cheese
  6. Re:Why would my oven need to be online? by Russ1642 · · Score: 3, Funny

    Your toaster needs to be online so it knows the time. It needs to know when its warranty expires so it can break down right on schedule.

  7. Much ado about nothing by Zero__Kelvin · · Score: 2

    There is absolutely no reason not to have your oven networked, so long as it is properly designed. Hardware can't do what it can't do. You simply do what toaster and oven manufacturer's already do, which is to make sure that it passes UL Standards, and that no matter what the software tells the hardware to do, the hardware simply is incapable of complying with dangerous requests.

    The hacker might burn your dinner, but he isn't going to "start a fire and burn your house down". Period.

    I'm actually pretty surprised at the lack of vision being exibited right now in this thread. Why would I want my oven to be online? Seriously? If you can't think of advantages to having appliances capable of communicating over the internet, and being controlled by same, then you aren't thinking. As far as people "hacking in", it's called a VPN. Yes, they aren't inpenetrable, but that is besides the point. Nobody is going to try to hack your VPN so that they can burn your chicken or turn your lights down too low. If they have that capability, there are far more juicy targets.

    In other words: I don't have to run faster than the Tiger; I just have to runn faster than you!

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    1. Re:Much ado about nothing by BitZtream · · Score: 2

      There is absolutely no reason not to have your oven networked,

      Please show me your unexplainable software. Go ahead, the world will wait while you present this solution that evidently you and you alone were able to figure out that solves all software exploits and engineering flaws.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager