Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security IT Technology

A Critical Security Flaw in Popular Industrial Software Put Power Plants At Risk (zdnet.com) 41

A severe vulnerability in a widely used industrial control software could have been used to disrupt and shut down power plants and other critical infrastructure. From a report: Researchers at security firm Tenable found the flaw in the popular Schneider Electric software, used across the manufacturing and power industries, which if exploited could have allowed a skilled attacker to attack systems on the network. It's the latest vulnerability that risks an attack to the core of any major plant's operations at a time when these systems have become a greater target in recent years. The report follows a recent warning, issued by the FBI and Homeland Security, from Russian hackers. The affected Schneider software, InduSoft Web Studio and InTouch Machine Edition, acts as middleware between industrial devices and their human operators. It's used to automate the various moving parts of a power plant or manufacturing unit, by keeping tabs on data collection sensors and control systems. But Tenable found that a bug in that central software could leave an entire plant exposed.
This discussion has been archived. No new comments can be posted.

A Critical Security Flaw in Popular Industrial Software Put Power Plants At Risk

Comments Filter:
  • by Anonymous Coward on Wednesday May 02, 2018 @11:11AM (#56541640)

    as the manufacturing world connects more and more things to the Internet. This is driven by MBA managers who want to be able to access fancy dashboards from their head offices miles away from the plants. The major marketing push currently going on in the manufacturing world is the IIOT (Industrial Internet of things) and is driven by greedy companies who are taking advantage of middle to upper management's lack of knowledge to sell them on fancy gizmos and gadgets with out actually explaining the potential consequences. When combined with the race to the bottom for cost of I.T in manufacturing, this is a catastrophe just waiting to happen.

    We have already seen examples recently of ski lifts but this was already a problem with remote desktops and all you have to do is search for defcon talks to see hundreds of examples. The only difference is that now the access is baked right into the control software and black hats dont need to worry about looking for vulnerable remote desktops.

    • Sometimes you have to break a few eggs to make an omelet. The bottom line is that you're never going to talk management out of buying this type of stuff because the promised results are too attractive to them, and you're never going to stop the claims from the people selling this stuff about a management utopia where all is observable and controllable from your laptop or mobile phone, so until we have some spectacular failures and attacks nothing is going to derail this train. Might as well grab some popc
    • by DontBeAMoran ( 4843879 ) on Wednesday May 02, 2018 @11:32AM (#56541722)

      Systems should be able to tell the outside world about their current state, but they should not be able to be controlled from the outside.

      In short, make those types of systems read-only.

      • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday May 02, 2018 @11:57AM (#56541850) Homepage Journal

        More to the point, attach them to one way communications links. A high speed serial interface with only the RX pin connected on the receiving end can simply not be used to communicate back to the reporting device/gateway. Not every damned thing needs to be on Ethernet.

      • by dunnomattic ( 2590531 ) on Wednesday May 02, 2018 @12:15PM (#56541948)
        I'm no Schneider expert, but I've worked with guys who are. While I agree with you on the explicit principle that externally-accessible systems should be read-only (or even better, receive data via internal system pushes instead of pulling data through whitelisted IP:port), I think there are two nuances here:
        1. -The middleware itself can't be read-only since it is used to monitor/automate tens of thousands of individual sensors/valves/breakers per site, each of which has multiple registers involved in the monitoring/adjusting communication. If they were read-only, technicians would have to go through hundreds or thousands of steps just to test if one class of device is nominal.
        2. -These critical systems should never be accessed by the outside world. I doubt that anyone who wanted to keep their job would knowingly expose these system interfaces publicly. However, with so many layers of software separating the outside attacker from the critical system, one of them will get the needle threaded at some point to hit the critical system. So now you've got an attacker facing a read/write industrial control system with the vulnerability to bypass authentication. The comm protocol specifications I've seen for these type of systems are well-documented, but they are extensive just due to the variety of devices they need to control. This won't be the last vulnerability in these industrial control systems. They should never be exposed by design.

        ...and yes, DeleteFacebook.

        • by Mashiki ( 184564 )

          There's two types of things in industrial control. There's the one you mentioned, but even then you can "soft" block it from the outside requiring access via a private LAN, problem lot of companies don't want to create a side-by-side corp net and IC net, they see it as too expensive. That'll change as soon as some nut figures out that they can cause serious damage to infrastructure or hold company for ransom. The second, is the type that uses PLC's for adjustment and control of plant controls. The latte

      • by HiThere ( 15173 )

        Well, for the inner layer...usually. But that means someone's got to be able to get to the machine to throw a switch or turn a dial. So it's not always going to be possible.

        Additionally, you generally want to protect the inner layer from even being read by someone unauthorized. So you need multiple layers of security with different restrictions.

        OTOH, that's just how it should be done this year. As interfaces and machines get smaller, it will be less practical to have human sized switches on the machines

    • This is driven by MBA managers who want to be able to access fancy dashboards from their head offices miles away from the plants.

      We used to have a technology that solved this problem with little or no increase in security risk. How it worked was, you have a remote site with its own airgapped internal LAN. A dedicated PC would fetch data from the internal server and use a dial-up modem to connect to a machine at corporate HQ. It would then transmit data to corporate HQ via advanced protocols such as Kermit or XMODEM.

      The modem at the remote site would be configured to ignore (not answer) incoming calls for security reasons. It would on

  • That's it, there is no other news. Exploit found, manufacturer fixed in a timely manner. I would say that whatever ad-hoc system that is in place for identifying software vulnerabilities, whether it's a reward or just the coolness factor of having one's name in an article, seems to be working. I did like the picture of the Nuke plant in the article though. I am making a wild guess that any software running internally in a nuclear plant is not accessible from outside, not even through a firewall. But I could

  • by Anonymous Coward

    1. Don't put any control hardware on the internet. Air-gap everything. This is already best practice. For monitoring, do an RS-232 link to an internet-connected machine, from an embedded machine with no network stack.

    2. Lock down the machines running the control software. Physically isolate the machines. Make the web-based client machines thin clients running a locked-down browser.

    3. Lock down the control network. Use MAC filtering and IP authentication, which I believe is part of the industrial IP standard

  • It's ok we have a no homers rule at our plant

  • by PPH ( 736903 ) on Wednesday May 02, 2018 @12:00PM (#56541860)

    ... vulnerability present in the Linux version? Or only Windows?

    • by Anonymous Coward

      "InduSoft Web Studio (or IWS, for short) is a powerful, integrated tool that exploits key features of Microsoft operating systems and enables you to build full-featured SCADA (Supervisory Control and Data Acquisition) or HMI (Human-Machine Interface) programs for your industrial automation business."

      "InTouch Machine Edition is a natural extension of the current Wonderware HMI portfolio and the perfect complement for customers who already own Wonderware System Platform... Wonderware System Platform runs on m

  • I figured that I would chime in here, since I've worked on these types of systems, and in this type of environment for nearly 30 years.

    It is common to see these types of alerts for all kinds of HMI software, PLC's, and DCS's. They all have security vulnerabilities discovered, just like any software-based systems do. In the electric utility environment in the US, these systems fall under NERC CIP regulations. There will be someone at the utility tasked with keeping track of these alerts and making sure that

    • by Anonymous Coward

      InTouvh machine edition is for remote HMIs for field operators. Likely a OPC connection.

      OPC is the biggest shit show that exists on industrial systems, and im sure you have run into this issue over you're years...

      to transfer data between computers, both computers use DCOM and must have the same local account WITH THE SAME PASSWORD.

      its a joke. its DCOM.

  • Have they ever considered not connecting their industrial plant directly to the Internet.

What is research but a blind date with knowledge? -- Will Harvey

Working...