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

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.

Comments

expect more of these stories

[Anonymous Coward]

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.

Re:expect more of these stories

[olsmeister]

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 popcorn and sit back and enjoy the spectacle and hope it happens to someone that isn't your company or someone your company depends on.

Re:expect more of these stories

[DontBeAMoran]

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.

Re:expect more of these stories

[drinkypoo]

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.

Re:expect more of these stories

[dunnomattic]

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.

Re:expect more of these stories

[Spy Handler]

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 only dial out, and only to the phone number at the corporate HQ.

This way China hackers can't access the remote site (at least not easily), and corporate HQ still gets their hourly update on their fancy dashboards.

Is this ...

[PPH]

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