The Coming IT Nightmare of Unpatchable Systems 240
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.'"
Embedded System Designer's Opinon (Score:5, Informative)
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.
Re:The poster is showing his prejudice. (Score:5, Informative)
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.)
Re:The poster is showing his prejudice. (Score:3, Informative)
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.
Re:The poster is showing his prejudice. (Score:4, Informative)
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.]
Re:Repetitive (broken) OS abandonment (Score:5, Informative)