Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.
Silver badge

Risk Management

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.

0
0
Bronze badge

Re: Risk Management

Yes, and back in the day I'm sure people were saying similar things about open SMTP relays.

Just because nothing bad happened doesn't make it good practice.

6
0
Bronze badge
Holmes

Re: Risk Management

No evidence of loss doesn't mean there is no risk (- and no evidence of loss may also mean that intrusions have occurred but you just weren't monitoring).

Very difficult concept to get into the heads of PHBs as well when they don't want to spend effort to improve security...

2
0
Silver badge

Re: Risk Management

And still are about DNS servers open to recursive or "host -l" queries.

0
0
Bronze badge
FAIL

RE: Re: Risk Management

Very difficult concept to get into the heads of PHBs as well when they don't want to spend effort executive bonus money to improve security...

FTFY

0
0
Gold badge
Unhappy

Still not a problem as long as no one connects it to the internet via ethernet

Right?

Because you'd have to be very stupid (or perhaps very cheap) to do that.

0
0
Silver badge
Trollface

Re: Still not a problem as long as no one connects it to the internet via ethernet

Our big five consultancy specialises in stupid and cheap, sorry, value for money for the taxpayer. Sign on the dotted line minister.

1
0
Bronze badge

Re: Still not a problem as long as no one connects it to the internet via ethernet

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.

2
0
Gold badge
Unhappy

Re: Still not a problem as long as no one connects it to the internet via ethernet

"so the vulnerability of the building management system was the combination of all those corporate LANs."

Yes.

That's the problem.

<sigh>

0
0
Bronze badge
FAIL

Re: That's the problem.

Which our poster does not comprehend.

If any one of those networks get compromised, then all of you are fucked.

End of story.

There is a reason why you internally firewall off critical systems.

0
0
Meh

This wonderful 'connected' age we live in

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.

5
0
Anonymous Coward

Stuxnet Mk2

Great - now what are Israel supposed to use to disrupt nuclear weapons manufacturing in Iran?

1
0
Anonymous Coward

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.

1
0
Bronze badge
Boffin

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.

0
0
Bronze badge

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.

1
0
Anonymous Coward

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?

0
0
Bronze badge

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.

0
0
This topic is closed for new posts.