If you miss the happier times of the 2000s, just look up today's SCADA gear which still has Stuxnet-style holes Two Schneider Electric SCADA products had vulnerabilities similar to the ones exploited in the Iran-bothering Stuxnet worm, an infosec outfit has claimed. The vulns, uncovered by Trustwave and since patched, could be abused by a malicious person to interact with the SoMachine Basic v1.6 engineering software and the M221 …
One big reason why our equipment uses a firewalled VPN to communicate from customer sites, and it sits all happy self contained.
It phones us, they just supply the IPoAC link to the internet.
But there's always a customer that wants access to the innards to "gather metrics" or requests a hole through the equipment edge router to "integrate with XPQ Corps widget from the white van sale".
In general, if someone has systems like this connected raw to the internet, there are issues beyond the manufacturer of the kit used in the system.
How can you possibly design a program to accept commands if the user is not authenticated first ?
I just cannot fathom how it is possible for a developer to not design the code to stay in the authentication ring until that is validated. You can't program defensively against everything, but you sure as hell can refuse any input before validating a user's right to send commands.
SoMachine is the IDE software used to write, download, and debug programs for Schneider PLCs. SCADA systems are something else altogether.
To get to the substance of the article though, it doesn't look like a big deal for several reasons. One is that they essentially had to comprise the Windows PC being used to run the SoMachine programming software. Once you do that, all bets are off and you can probably just grab the passwords anyway. All of the industrial control security problems that I can think of off the top of my head are really Windows security problems at their root.
The other reason is that use of passwords in PLCs is very rare anyway. They're generally left blank, as using them defeats the purpose of using a PLC in the first place, which is to allow your maintenance crew to modify the program at need.
The few places where a password does see occassional use are when an OEM uses a PLC as part of a "black box" system which contains some supposedly secret process knowledge, or very occasionally for certified safety systems. The latter generally run on specialised hardware however, not bog standard PLCs.
In most PLCs that have passwords, the password is typically stored as plain text in the PLC. The programming software then says "may I have the password please" and the PLC hands it over. The programming software then compares that to whatever the user typed in and if they match it says "OK, go ahead and use me". If you write your own software and know the protocol, then you can of course just bypass that charade.
Oh, and if you're on the Modbus/TCP network, you can talk to anything, including controlling the I/O directly. There is no authentication.
In my opinion, trying to bake security into industrial controls is pointless. Doing it right is hard enough for the IT industry, so expecting automation system designers to get it right is hopeless. I think it's better to adapt IT industry technology to industrial applications as a security layer(s) than expecting the industrial sector to implement and maintain their own security systems correctly.
"It doesn't look like a big deal for several reason"
Who said it was? We're saying the security stuff from the 2000s is still a thing now.
"One is that they essentially had to comprise the Windows PC being used"
Yeah, as the article says at the top. The point Trustwave's trying to make, and I guess we are, too, is that, no, this isn't acceptable. The industry should do better. I know all the excuses why not.
Or let me put it another way: you obviously know a lot about how SCADA works, which is cool. But next time a plant gets hacked, and people say, 'how could this happen?' they can be referred to this article and research. This is how it happens.
I totally appreciate that once you get into the Windows PC connected to the controller, it's virtually game over.
But sometimes the obvious has to be pointed out.
C.
I don't have any arguments with the general thrust of the article itself. Bad security is probably worse than no security, as it gives the illusion of security and may lead to people assume they don't need to take further measures. We need more articles of this sort to raise awareness. I am just saying that this will be far from the worst problem present, and I gave an example of how poor to non-existent password security really is in many cases.
Security in the industrial automation field tends to range from the bad to the farcical. The main thing which probably prevents more problems from being reported is the relative obscurity of the field and the high cost of the proprietary technology which discourages researchers who don't have the niche background or the budget to probe into it. For example the Schneider M221 is at the extreme budget end of their product line, but things don't get any better from the security perspective with the larger and more expensive kit.
I originally came from the industrial automation field and started reading The Register years ago in order to get a better understanding of what was going on in the IT sector, as I realised that what the industrial automation field needs is a greater injection of IT knowledge and technology.
If I communicated my point poorly, then I apologise. What I am trying to say is that in the scale of IA security problems this is at the lower end and there are far worse things to be found and proven. By all means, keep up publishing stories such as this, as the steady drip, drip, drip, of bad news is the only thing that will spur people and companies into action. The only problem is that I think not enough people in the IA field are reading publications like The Register in order for the message to get through to the people it needs to. An easier way of finding past stories which were connected with industrial automation might be handy, as at present they are simply lumped in with all the other security stories. I don't think your site is set up for stories to have multiple tags however.
In my opinion, the field needs an injection of security technology from the IT industry. The problem is that the major vendors are so focused on vendor lock-in that they continually re-invent the wheel badly, particularly when it comes to security. From their perspective inviting "the wrong type" of IT industry tech risks watering down vendor lock-in such that they can't extract the maximum amount of money possible from customers.
SCADA systems are a subset of industrial automation, much like web servers area subset of the wider IT industry. They tend to get more attention in security news lately because of their use in critical infrastructure such as electric power, petroleum, water, and the like. However most people working in the industrial automation field can go through an entire career without ever laying eyes on a SCADA system.
SCADA systems also tend to get more attention because they use (badly, usually) more IT industry technology such as MS Windows, databases, and the like. In most cases they got an injection of IT tech in the 1990s to replace their previous proprietary platforms but haven't moved on much since then other than to maintain compatibility, and more recent ideas have largely passed them by.
PLCs such as the Schneider M221 may be used in a complete system in conjunction with a SCADA system (e.g. to control a pump the SCADA system is monitoring), but in most general manufacturing they're stand alone. In some ways this is a blessing because they never get networked, but just work quietly running stand alone machines in a factory somewhere. It also means though that they are probably a rich field for finding security vulnerabilities because not as many people have been looking for them, and they are starting to get networked more now for a variety of reasons.
So to sum up, I'm sorry if my earlier post came across differently than I intended. My real point is that in the grand scheme of things though things this example is just barely cracking open the lid on a very large can of worms.
The big deal as you say is connecting to the internet. I can understand not using passwords and encryption if you have your own ISOLATED network not connected to anything else. If they are close enough to plug in then you have many other problems. The problem comes when the boss wants to connect so he can check on the factory, or the chief engineer want's to be able to reprogram from home without have to get dressed and come in when the off shift calls. Once you hit that point you are trusting every other user on the internet to respect your system. Simply put, that is not going to happen. You need the VPN, strong passwords and encryption. If the software is designed with good security built in then you have defense in depth.
I do hardware and software design for niche industrial systems. When I first started working with Modbus I was pretty shocked that such an insecure and outdated comms protocol was still de rigeur for industrial use and most likely used in a majority of critical infrastructure plants. As much as I hate building anything non standard I ended up developing my own protocol for internal comms.
For anyone who's not aware Modbus was originally developed 30+ years ago as a way for industrial equipment to talk with each other over RS485. At some point it was hastily bolted onto IP network as Modbus TCP/IP. There is zero authentication in standard Modbus and there are some pretty big limitations in the protocol such as only 16 bits used for data (a 64 bit float would need to be sent as 4 messages and converted at the other end).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
