Slash Boxes

SoylentNews is people

posted by on Friday June 02 2017, @08:58PM   Printer-friendly
from the looming-global-IoT-shitstorm dept.

TechDirt reports

In the wake of the Wannacry ransomware, University of Pennsylvania researcher Sandy Clark has proposed something along these lines: firmware expiration dates. Clark argues that we've already figured out how to standardize our relationships with automobiles, with mandated regular inspection, maintenance and repairs governed by manufacturer recalls, DOT highway maintenance, and annual owner-obligated inspections. As such, she suggests similar requirements be imposed on internet-connected devices:

A requirement that all IoT software be upgradeable throughout the expected lifetime of the product. Many IoT devices on the market right now contain software (firmware) that cannot be patched even against known vulnerabilities.

A minimum time limit by which manufacturers must issue patches or software upgrades to fix known vulnerabilities.

A minimum time limit for users to install patches or upgrades, perhaps this could be facilitated by insurance providers (perhaps discounts for automated patching, and different price points for different levels of risk)."

Of course, none of this would be easy, especially when you consider this is a global problem that needs coordinated, cross-government solutions in an era where agreement on much of anything is cumbersome. And like previous suggestions, there's no guarantee that whoever crafted these requirements would do a particularly good job; that overseas companies would be consistently willing to comply; or that these mandated software upgrades would actually improve device security. And imagine being responsible for determining all of this for the 50 billion looming internet connected devices worldwide?

That's why many networking engineers aren't looking so much at the devices as they are at the networks they run on. Network operators say they can design more intelligent networks that can quickly spot, de-prioritize, or quarantine infected devices before they contribute to the next Wannacry or historically-massive DDoS attack. But again, none of this is going to be easy, and it's going to require multi-pronged, multi-country, ultra-flexible solutions. And while we take the time to hash out whatever solution we ultimately adopt, keep in mind that the 50 million IoT device count projected by 2020--is expected to balloon to 82 billion by 2025.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by jmorris on Friday June 02 2017, @09:12PM (7 children)

    by jmorris (4844) on Friday June 02 2017, @09:12PM (#519577)

    IoT crap comes in two flavors, Google / Amazon stuff to bind you to an ecosystem, generally produced by IT savvy companies. Regular updates for them are an option. The rest comes from fly by night Chinese companies selling you crap, and once it is sold any maintenance is an expense they won't bear one second beyond when a product does out of production and the shelves empy.

    The only answer for that second sort is to standardize on a couple of basic platforms, ship the devices with OpenWRT or similar open tech and once the vendor ceases support release the means for the owner to point it at a standard repo for updates. Or better yet, just point it there from day one for the OS and the vendor for the webapp running atop it. But the requirement must be there from day one because even the minimal effort to get a Chinese vendor to publish a 'abandon it and throw it open' patch is too much to ask.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Interesting) by bob_super on Friday June 02 2017, @10:01PM (4 children)

    by bob_super (1357) on Friday June 02 2017, @10:01PM (#519593)

    The only way to stop the idiocy (besides "not buying webcam-microwaves") is to upgrade consumers to firewalls treating any new device as a threat.
    "This device will be isolated from the rest of the network, until you explicitly enable it (via a grandma-friendly GUI) to connect to that other one, on that particular port, or that web server, and absolutely nothing else, ever, and you can only add permissions with the code that the firewall keeps changing on its front panel."

    Plug-and-play is the problem. Convenience sells devices, but it sells them to clueless people who endanger everyone else.

    If manufacturers want to connect a device to their servers, it should always be to a "trusted" single entry point, so you can firewall everything else.

    • (Score: 2) by jmorris on Friday June 02 2017, @10:09PM

      by jmorris (4844) on Friday June 02 2017, @10:09PM (#519596)

      I like it. How about revise to when a new device appears ask you (if it can't auto id it) if it is a) a general purpose computing device that will receive regular OS/Browser updates and connects to a wide variety of web resources or b) an IoT device. If IoT, assume it is secure when first unboxed and thus observe traffic to/from it and build a whitelist from that over a week or two. After that provide a button for 'reconfiguring device' for cases like a Roku where you might subscribe to a new service via it and need to permit it to connect to the servers for it.

    • (Score: 4, Interesting) by zocalo on Friday June 02 2017, @10:40PM (2 children)

      by zocalo (302) on Friday June 02 2017, @10:40PM (#519605)
      I've been thinking along similar lines, since it's obvious that IoT is here to stay and so we'd better figure out how to fix it. If you take as given that any item of hardware and software will, at some point, have an exploitable weakness discovered on it and that not all users will know even the first principles of security, then defence in depth is the best mitigation. For most home IoT devices there are three tiers in the model; the device itself, their home router, and their ISP - with the brunt of the work falling on the router, since it's the closest we've got to an edge firewall and central management device. Protecting the router (also susceptible to "any given item of hardware...") is largely going to be down to better management of the admin interfaces, and the ISP.

      What seems to needed is a way for the router to autoconfigure firewalling based on the requirements of IoT device in question, which is going going mean some kind of lookup, either via querying the device itself (a standard URL to return basic device info, perhaps?) or an unconfigured device broadcasting the information in a similar manner to an ARP or DHCP request until it gets an ACK from the router that it has been configured. For security, all this should obviously be local subnet only unless manually configured otherwise, which shouldn't be beyond the capabilities of anyone running multiple subnets in the first place, and there's going to need to be at least some manual intervention to prevent spoofing ("Hi, I'm a newly compromised PC, but I'm pretending to be a new IoT device - now, if you can just open ports..."

      Problem is, as with that form for solutions to the spam problem, this approach advocates a technical and market-based approach (and maybe legislative too)... There are too many big players that are going to want to push their own take on the necessary "standard", and even if/when they all get behind a small enough subset for vendors of CPE to have a shot, there are too many cheap-ass vendors of IoT devices that won't bother supporting it anyway.
      UNIX? They're not even circumcised! Savages!
      • (Score: 2) by c0lo on Saturday June 03 2017, @12:51AM (1 child)

        by c0lo (156) on Saturday June 03 2017, @12:51AM (#519657) Journal

        I've been thinking along similar lines, since it's obvious that IoT is here to stay and so we'd better figure out how to fix it.

        (malevolent trollish grin - if the provider of this IoT thingies make such a crap, how about spoofing a malfunctioning device and feed - plausible deniable - crap to their server?
        While doing it, good chances I might discover weaknesses on their serverside in the process, but why bother exploit it when "poisoning attack" is good enough for the lulz?
        They can try to disable the "defective device", but... you see? ... it's defective, won't answer to "firmware upgrade" commands.
        I'd even publish the source code for the spoofer - a non-compiled version of course - for any other willing to share the fun. Source code is speech)

        • (Score: 2) by zocalo on Saturday June 03 2017, @09:46AM

          by zocalo (302) on Saturday June 03 2017, @09:46AM (#519786)
          Now that you mention it, taking over a vendor's vulnerable IoT devices then using them to launch a DDoS against the vendor's infrastructure would also make for a pleasantly cathartic payload for a BrickerBot / Hajime style IoT worm. The author would need to figure out some means of determining what the target should be using the available data (what port and password was used for the compromise, etc.), plus any additional info that can be learnt from the device itself, but that shouldn't be too hard a challenge. I guess some kind of fallback mode if the vendor has already gone bust too - probably quite common given the fly-by-night nature of vendors at the sewer level of the market - and since a patch obviously won't be forthcoming, bricking the device for the greater good seems like a reasonable choice there.
          UNIX? They're not even circumcised! Savages!
  • (Score: 3, Interesting) by frojack on Saturday June 03 2017, @01:39AM (1 child)

    by frojack (1554) Subscriber Badge on Saturday June 03 2017, @01:39AM (#519674) Journal

    IoT crap comes in two flavors, Google / Amazon stuff to bind you to an ecosystem, generally produced by IT savvy companies.

    Actually, that's completely wrong.

    Products from Google and Amazon themselves have, by and large, NOT been responsible for any the botnets or malware storms. Amazon and Google actually have something of a clue about their own products.

    The crapware that is responsible are the IOT devices deployed by Cities and Governments to watch every intersection and street corner, most of it on publicly route-able IPs, easily found by a simple scan, most of it deployed with default passwords.

    Joe User has his webcam and his ip-addressable light bulbs behind a firewall and are generally not exploitable.

    No, you are mistaken. I've always had this sig.
    • (Score: 2) by jmorris on Saturday June 03 2017, @02:38AM

      by jmorris (4844) on Saturday June 03 2017, @02:38AM (#519691)

      Products from Google and Amazon themselves have, by and large, NOT been responsible for any the botnets...

      Reread, that is what I said. They aren't selling you crap they are getting you to buy into their ecosystem and the device is the door through which they hold you in a long term business relationship. They have every reason to invest in maintaining it. Random IoT lightswitch or webcam maker has no such motive. They sell it and are done with you and they will not issue a single update beyond production ending. And the option of renting a light switch forever to provide an incentive to update its firmware will find few takers, even if they provide a cloud service and an app to control it over the Internet. People will want Alexa to control their stuff if they went into Amazon's ecosystem, otherwise Google, Apple or Microsoft, etc. But not ChingChiongChinaman's skeevy cloud or not even Leviton's Internet Light Switch Hub or Whirlpool's Internet Air Conditioner App / Website. They don't want to be oppressed by just any megacorp, it must have the right hip image.