Schneider moves on ancient SCADA vuln Schneider Electric has begun patching a hard-coded Ethernet credential vulnerability in its kit, a mere 18 months after it was discovered and published. The original vulnerability, discovered by Rubén Santamarta and published in December 2011, provided access over Ethernet to the telnet, FTP and Windriver debug ports of …
Have their been any negative repercussions of this unpatched vulnerability? Has it been acted on? Seems to me that even with shouting a detailed description of the problem from the rooftops for all the 'bad guys' to hear had absolutely zero impact. The fact they are just getting around to fixing it seems like they have a good operations guy who understands risk management.
The building management system at my last company was connected to our LAN, as well as to the LAN in each of the other organisations sharing the building with us. Our LAN in turn was connected to the Internet, the same as the other organisations, so the vulnerability of the building management system was the combination of all those corporate LANs.
We had such a lovely email last week from a gentleman in Lagos who pointed out such vulnerabilities to us. (So kind and thoughtful in this day and age). We took his advice accordingly and clicked on the link he so kindly supplied to enable him to 'patch' the building systems for us. We must have done something wrong, however, or misunderstood his instructions, none of us being exactly 'technically' minded, as now the lift call buttons would appear to control the ventilation, the third floor coffee machine, (the wonky one by the loo, behind the green door), controls the lighting on the first, second and fourth floors and all the networked printers now send instructions to the heating system, which constantly demands A4 paper feed into the boiler room furnace by the ton!
Ah well, if it doesn't sort itself out, as sometimes these things do on their own, I think we will have to call and engineer out or something.
In the embedded device world, updates can be hard to support. Everything is project oriented. The project gets built. The programmers, the hardware designers, and the manual writers get paid; and then almost all of them go on to other things. There is little if any software maintenance.
Not to excuse Schneider, but this is the reality of the embedded world. When was the last time you got a software update for your 3 year old oven, your washing machine, or your refrigerator?
The end users assume all the risk here. It sucks, but that's how it is. Those of you who glibly rant about this as if it were just another app, please get a clue. This device is not meant to be exposed to the internet in any way. Yet many make the mistake of doing just that. It happens because people demand real time data for all sorts of projects that, if they really understood the risks, would not have happened. The engineers either didn't know enough to object or, if they did object, were overruled.
If you want to do something productive, stop making snide remarks amongst yourselves and try educating the world as to why this is a bad thing. You will rapidly see why stories like this are not unusual, and why it is amazing that anything good came of this in the first place (note the age of the product). This is primarily a social, not technical, problem. The solutions are not nearly as easy as they seem.
Perhaps good reason to use best practice in the first place then if you know you won't easily be able to go back and fix a problem.
For what it's worth, Schneider's problems are not limited to their embedded firmware. ION Enterprise 6 hard-codes a 'sa' password (14 characters based on dictionary words!) for the instance of Microsoft SQL Server 2005 it runs on.
Not to mention no application should require or use 'sa' user anyway. There should be separate user with just required permissions granted.
It is all too common for vendors to have software that 'requires' sa (or equivalent) password to run. I've seen that way too many times. Needless to say if I have any say in the matter, that vendor and/or product is out the door immediately.
What were the "best practices" nearly 20 years ago? Yes, this product is nearly that old. Yes, this is an OLD embedded product.
As for what the PC software looks like, yes, that behavior is all too common in this business. However, PC software is comparatively easy to patch and update. The embedded products from 20 years ago, not so much.
Anyone got an EEPROM programmer so that I can burn a chip that is not made any more?
Hmmm, what year was it 20 years ago? 1993. Pretty sure the "best practice" of the day was not "leave gaping holes in your product for all and sundry to find".
The Internet thing was a new concept, yet to catch on outside of academia, granted. I'm pretty sure the network engineering policy of the day wasn't to leave the door wide open.
Need an EEPROM programmer did you say? I think that just proves my point about using best practice to begin with. Problems are orders of magnitude more expensive to fix the longer you leave them.
My biggest point was that, more than 12 years on, they still hadn't reformed their practices … it's good to see they're finally coming to their senses at last.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
