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 …


This topic is closed for new posts.
  1. Don Jefe

    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.

    1. Anonymous Coward
      Anonymous Coward

      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.

      1. Alan Brown Silver badge

        Re: Risk Management

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

    2. Anonymous Dutch Coward

      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...

      1. Fatman

        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...


  2. John Smith 19 Gold badge

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


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

    1. Dan 55 Silver badge

      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.

    2. Anonymous Coward
      Anonymous Coward

      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.

      1. John Smith 19 Gold badge

        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."


        That's the problem.


        1. Fatman

          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.

  3. Scott Broukell

    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.

  4. Anonymous Coward
    Anonymous Coward

    Stuxnet Mk2

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

  5. Anonymous Coward
    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. Anonymous Coward

      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.

      1. Down not across Silver 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.

      2. Anonymous Coward
        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?

        1. Anonymous Coward
          Anonymous Coward

          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.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022