Forgot your password?
typodupeerror
Security IT

The Coming IT Nightmare of Unpatchable Systems 240

Posted by samzenpus
from the down-in-flames dept.
snydeq (1272828) writes "Insecure by design and trusted by default, embedded systems present security concerns that could prove crippling if not addressed by fabricators, vendors, and customers alike, InfoWorld reports. Routers, smart refrigerators, in-pavement traffic-monitoring systems, or crop-monitoring drones — 'the trend toward systems and devices that, once deployed, stubbornly "keep on ticking" regardless of the wishes of those who deploy them is fast becoming an IT security nightmare made real, affecting everything from mom-and-pop shops to power stations. This unpatchable hell is a problem with many fathers, from recalcitrant vendors to customers wary of — or hostile to — change. But with the number and diversity of connected endpoints expected to skyrocket in the next decade, radical measures are fast becoming necessary to ensure that today's "smart" devices and embedded systems don't haunt us for years down the line.'"
This discussion has been archived. No new comments can be posted.

The Coming IT Nightmare of Unpatchable Systems

Comments Filter:
  • by Murdoch5 (1563847) on Monday June 02, 2014 @04:52PM (#47149539)
    Well as an Embedded System Designer I have to speak up here, systems are usually not insecure because of lazy development, systems are insecure because clients, managers and stakeholders don't provide proper funding, deadlines or requirements. The number of times I've had to go to a manager or project manager and ask them to clarify a customers request is almost sad. The amount of times I've had to go to the same group and ask for twice or three times the amount of time to develop a solution is almost sad and the amount of times I've had to ask for much more funding to do a proper job is sad. For some unknown reason embedded designers aren't treated like normal software developers and the truth is we aren't. We don't rely on some insecure patched to hell OS to keep us safe and we don't trust laughable memory managers and kernels to keep us crash free and running smooth. We do the real work in the development world and generally it's the GUI designer who takes the credit.

    We generally don't work in the world of garbage collected and managed languages, we don't work in the world where everything is already setup and ready to be called through some piss poor abstracted class implementation of system.IO and we don't get safety nets under us to catch what falls through in some kind of completely illogical and messed up exception error system ( C# ). To say embedded systems are insecure is really another way to say one of several things:

    1. You didn't allocate enough time, money or proper requirements.
    2. You didn't hire someone who is qualified to the job, such as putting a desktop developer onto an embedded project.
    3. You didn't consider security when you dreamed up you're fragmented and broken project idea.

    This is of course mitigated by a great developer who will go back to the table of executives and tell them they need what they need and won't start until it's delivered. You can't treat an embedded project like a normal software project, when you do you'll end up with systems that make Microsoft proud ( aka 0 security and patch opportunities to fly to the moon ), you need to treat an embedded project like an embedded project and give the embedded developer what he / she needs. Doing other wise will always end up you shit creek and generally the manager or stakeholder is left with the paddle looking like a fool.
  • by plover (150551) on Monday June 02, 2014 @05:07PM (#47149673) Homepage Journal

    I don't mind smart appliances - but again, I don't see why they need internet access. The exceptions to this (smart TV's, for example) should be viewed with suspicion specifically because they are likely to be connected to the internet in some way, but my smart refrigerator probably shouldn't be - and ATM's, slot machines, SCADA systems, etc. almost certainly should never be.

    Just because you haven't encountered a specific example for yourself doesn't mean they don't exist in the real world.


    • The TV? Netflix, of course.

    • The BluRay player? New keys for new disks, and to unlock "extra special downloadable content" (whatever that may be.)

    • The thermostat? You're coming home from summer vacation and want to turn on the A/C a few hours before you arrive.

    • The laundry machines? You're upstairs, out of earshot of the dryer, and want to know when the load is done so you can hang up your clothes to prevent wrinkles.

    • The smart refrigerator? Maybe you're having a problem, and need the technician to connect to it to remotely diagnose it and give you an estimate without making an expensive house call.

    • The freeze alarms? You're out of town during the winter, and want to be alerted if your house temperature drops to the point where it's threatening to freeze your water pipes, so you can call a neighbor for help or a repairman to fix the furnace.

    • The door camera, locks, and security alarms? You're still out of town and want to let the repairman in, so you look at the ID he holds up to the camera and remotely unlock the door for him.

    • The window shades? They're located high up in the skylights where you installed a motorized system to operate them, so it was a small additional expense to add a remote control. And as today may be very sunny, you want to close them while at work to keep the house cooler.

    • The dishwasher? It might need to know the scheduled price of electricity in order to avoid running during peak rates, and save you money.

    These are not made up examples - they happen every day. If someone already has the connectivity, and pays for the equipment to have the capabilities, there's no reason they shouldn't also enjoy the convenience.

    Note that this is true whether or not you personally think it's a good idea to connect your washing machine to the internet: the reality is Sally Soccermom and Charlie Cuttingedge already have houses full of this tech. You can buy all this stuff at Best Buy and Home Depot and Verizon today.

    Of all of these systems, most are designed and built with a remote update mechanism. Some that aren't (door locks, freeze alarms) are generally run through a home automation controller that is itself updatable; so even if you can't remotely patch your freeze alarm, you can at least patch the controller that interfaces with the network. Also of note, most are aware of the typical home firewall configuration, and are designed to "phone home" to check for updates. They generally don't sit on the raw internet and listen for incoming connections, so the attacker generally has to get inside the firewall to abuse them (which is not that big of a problem for many models of firewalls, that's for sure.)

  • by radish (98371) on Monday June 02, 2014 @05:55PM (#47150087) Homepage

    Door opening: See above re: neighbor or friend, or hide a key somewhere.

    A truly special reply suggesting mitigating a theoretical, limited, network security vulnerability by quite literally leaving the physical keys to the castle out in public. Please hand in your risk assessment credentials at the door.

  • by mythosaz (572040) on Monday June 02, 2014 @06:31PM (#47150361)

    Slots? Impossible :)

    http://www.wired.com/images_bl... [wired.com]

    The "hack" was to get the operator of the video poker machine to enable the "double or nothing" bonus, which had a unique bug.

    Most newer video poker and slot machines allow (or can allow) you to play at various coin values. Each credit can be $0.01, $0.05, $0.25, $1, $5, etc.

    This particular machine would allow you to wager at $0.01, reach the Double or Nothing screen, use a combination of keys to get to the credit value change screen, and return to the Double or Nothing wager with your bet still pending.

    In short, you would put in a $100 bill. You would wager 100 of your 10,000 credits at $0.01/credit ($1) until you won, and when reaching the Double or Nothing screen, you would navigate out to the change credit screen. You'd change your credit value to $5 per credit (dropping you down to ~20 credits in the bank), return to the DoN screen with your bet IN CREDITS, NOT DOLLARS still pending and then you'd stand a chance to win 400 credits (twice your original CREDIT win) on your DoN bet. you could win $400 on $1, on what should have been a simple 2-1 (doubled) 4-1 payout.

    The spread likely wasn't $0.01/$5.00, probably was $0.25/$2.00 at the most, but by picking and choosing good payouts to DoN on, they were essentially playing machines with a winning paytable. [Since DoN's didn't pay double or zero, they paid 16x or zero.]

  • by RightwingNutjob (1302813) on Monday June 02, 2014 @06:35PM (#47150405)
    It's a two cultures problem in IT. The vast majority of Microsoft's, or Apples, or Oracles, or whoever's customers use their OS on laptops, workstations, or servers, where the consequences of bugs are fairly well approximated by "nuisance". The other culture of computer software customers are folks who use computers handle large amounts of money and control moving machinery (power plants, drones, etc), where the consequences of bugs and unintended features start at "oh shit, we've lost millions of dollars" to "oh shit, the crane dropped its load 200ft" up through "oh God, the power plant has exploded!" People in the second camp have a healthy suspicion of getting the latest and greatest upgrade from companies run by and for people in the first camp. And that dichotomy is why most embedded OS's come with source code that you get to debug yourself if it doesn't quite work for your application (VxWorks, QNX, Windows Embedded, RTLinux, etc).

There's got to be more to life than compile-and-go.

Working...