Researchers warn of unpatched remote code execution flaws in Schneider Electric industrial gear Armis security researchers have warned of severe and unpatched remote code execution vulnerabilities in Schneider Electric's programmable logic controllers (PLCs), allowing attackers to take control of a variety of industrial systems. Schneider Electric's Modicon controller family, some of the first PLCs on the market and …
Any industrial control network should NEVER be connected to the internet unless it is unavoidable no matter what any idiotic senior managers want.
Most industrial control systems were designed in the days when their security depended on there being no access outside the plant being controlled. This resulted in the majority of the controllers having virtually no internal security measures - the assumed air gap was their security.
(If there is a need for control over the internet (eg for an unmanned pumping station) then the communication link should be via a firewall at the remote unit that only allows a few (preferably one) PC to exercise the control.)
Icon for the people who blindly connect industrial control systems to the internet ==========>
This is the problem. It is cheaper to have some technician (probably in a call center somewhere) connect to the machine remotely rather than drive to the machine, and fix it.
The trouble is, they like to keep costs low. They can look at the balance sheet and see that an engineer costs a lot more per hour to come out, than they do to log on remotely. The costs of the potential security vulnerabilities opened up by allowing remote access cannot easily be quantified. Even if they can, they may well be dismissed as unlikely to happen, or guess work by the beancounters. In short, while a breach can potentially cause problems, the costs of those problems can be dismissed as guess work, while the costs of the Engineer visit are fact.
I don't agree with that assessment. The consequences for a breach can be disastrous for a company, it's employees and customers, and I'd rather see them pay out for the odd Engineer visit than risk, say, half their customers losing power.
"This resulted in the majority of the controllers having virtually no internal security measures - the assumed air gap was their security."
Not really. The PLC space is still evolving pretty well and is well beyond the 1980's levels you've described. There is plenty of security on most devices these days. However, similar to what we've seen in the SoHo router space, some device manufacturers are just better at it than others. Schneider is apparently really bad at it.
Relying on the PLC itself for security is a bit pointless. If you can get access to the same network at all then there is all sorts of mischief you can get up to without even bothering with talking to the PLC itself.
If you need remote access to equipment (e.g. a pipeline or tank farm) then the realistic solution is as you said to put some IT grade kit on the front end to limit access.
The issue in the case presented here isn't with Modbus itself, it's with Modicon's (part of Schnieder now) proprietary extensions to Modbus. These extensions are used to configure, manage, and debug the PLC and user programs while the public standard version of Modbus just exchanges user application data.
The key vulnerability in this case is that one of the proprietary extensions allows the programming software (the IDE for creating user programs) to upload the password from the PLC so that it can validate the user password without having to query the PLC on each log-in attempt. An analogy would be if the web page to log into this comments page uploaded the password from El Reg's servers so that it could do authentication in the browser instead of doing it n the server. The problems inherent in that should be obvious, but it's common practice in the industry, not just something Schneider did.
They can then combine this with the proprietary extensions to Modbus to then reset the password which then allows access to still more proprietary features.
Part of the problem is that Modicon shoehorned the management a control protocol into the user data application protocol, a legacy of the RS-232 / RS-485 days. This forces them to jump through a lot of hoops which aren't really necessary once you are using TCP/IP as the latter allows the use of multiple protocols on multiple IP ports. They could strip their proprietary extensions out of Modbus altogether and use a different protocol for the programming software, one which was more suited to the task.
Is just the usual sorts of hacker stuff like p0wning systems, stealing data, encrypting it for ransomware, wiping all the data so the business comes to a halt.
What you can do with a PLC potentially goes way above that, as you can control physical objects/processes. Like when Israel destroyed many millions of dollars worth of Iran's centrifuges. To the extent it was possible to change the ratio of chemical inputs in an industrial process, or purge toxic stuff into the air/water, and so forth you could do much worse with access to a PLC than you could if you had full control of everything else on the network.
So yes, you must rely on the PLC for security unless it is on an air gapped network segment (and even then you shouldn't trust air gapped networks to remain air gapped; just because it is air gapped when you configure the PLC's security doesn't mean that won't possibly change years later due to orders from above or mistake/mischief) Plus an air gapped network or even an air gapped PC controlling the PLC doesn't rule out social engineering, getting someone to do something they shouldn't like plug in a random USB stick.
Many used today were designed before Websites existed, though embryonic Internet did exist.
1) Best solution: Don't network at all.
2) Next best: Hardened secure Linux host with secure VPN access to that via dedicated port.
I was warning people about this 20 years ago.
1) Rephrase that to "no externally accessible network".
2) Not Linux. BSD.
More than 20 years ago ... Many decades ago, actually. Try connecting to the gear that monitors The Beam at SLAC, for example. Or the controls for the Stanford Dish. Or San Francisco's Hetch Hetchy water supply. Or rather, don't bother. You can't. Grad students wanted to hook 'em up to the 'net back in the late '70s or early '80s; the sane among us put the kibosh on their plans.
Commercial interests of today, however, are truly insane. We tugged on their capes, and were shrugged off. We tapped 'em on the shoulder & were elbowed away. We pulled on their shirts, and were thrust aside. Some even kissed their boots, and were trodden upon. Our message was always the same: "Please, PLEASE, **PLEASE!!** don't connect SCADA to publicly available networking systems!"
But did they listen? No. They did not. The idiots.
On the bright side, those of us with a clue are making a pretty penny in our retirement, cleaning up the resulting mess :-)
Yes, I know, I've posted this or similar before. It's still accurate.
Air gap is not enough, any connection to the internet means it is open to attack, even a dialup for remote access is susceptable as telecom companies are not required to guaranty secure connections.
I would suggest that what is needed in control is a return to centralisation that is not accessible other than by standing in front of system and even then staff can be subverted.
I would be interested to know what OS the compromised system is running, whilst it is possible that it is a "bespoke" build chances are it is either based upon windows or linux system code for networking with their known security fails that were likely already patched but PLC vendor wanted more money$ to maintain.
Fact is that if you want security then having the same software running on more than one system means that it is availible for attackers to find holes. Something that bespoke used to offer when it used to be one person designing hardware and software, now it is well known OS, hardware and software making for less of a learning curve for attacking multiple systems at once.
I agree, but it seems that airgaping is IRL not possible, because suppliers must access their equipments to get logs, to update or fix them. Of course these equipments should be behind a firewall, but it is not a 100% guarantee
OT has to change its paradigm. Air gap should not be considered as a 'by default' situation, so we don't care about cybersecurity.
"because suppliers must access their equipments to get logs, to update or fix them."
Dial-back modems work a treat for this. I've been using pre-CXR Anderson-Jacobson dial-back modems since 1983ish. I didn't connect my (admittedly meager) SCADA shit to the Internet back then for the same reason I refuse to connect the somewhat larger collection to the Internet today: Because the Internet is inherently not secure.
It is not just the usually poor by design aspect, once commissioned no one really wants to update stuff in case it breaks something critical. No one (or very few) have a whole off-line duplicate to test, so it comes down to "are you feeling lucky punk?"
So as above, start by assuming your control system is vulnerable and lubed ready for every curios and/or kinky internet punk to probe, then design your network access from that point onwards.
"No one (or very few) have a whole off-line duplicate to test, so it comes down to "are you feeling lucky punk?"
No, most plant engineers have plenty of spares to test firmware updates against. Not to mention that most PLC updates give very detailed information about what has changed and how that changes (or doesn't change) the operation of the device. These things are intended to be used by engineers, not paper-MCSEs.
It is very foolish to reprogram some bit of kit that is working fine if the update does not address anything that matters to you. The absolute best outcome if everything goes perfectly is that the device will continue working just as before. If you are unlucky it won't.
As they say "if it ain't broke, don't fix it."
The concept of security is slowly creeping into industrial control but it should be no surprise that PLCs are insecure.
Industrial automation equipment expects to be on an isolated network, or at least one shielded from the outside world. PLCs are chattering away to each other over mostly insecure protocols (e.g. modbus) and implicitly trust one another to not be malicious or sending false data. If such an environment were hooked up to the internet (or even the corporate LAN) then it would only be a matter of time before it could be taken down. Regardless of who makes the PLC or the other equipment in the factory.
Pick up any book on Internetworking 101 For Management[0] from the 1980s. In diagrams, "The Internet" is often represented by a cloud shape, with no explanation as to what it was, or how it worked. It was just a magic thing that you dumped bits into at one end, and they came out the other end, untouched and unscathed.
Management STILL thinks that's what the Internet is.
[0]Real titles available upon request. Send an SASE to SAIL, c/o Stanford Uni ... Oh, wait.
Gee, I wonder where they got today's "cloud" meme from ...
'Schneider Electric's Modicon controller family, some of the first PLCs on the market and described by the company as "still top of their class,"'
Designed and built when security wasn't at the forefront of engineers thinking. And now nobody wants to scrap millions of dollars invested in hardware and software to upgrade to 'the latest thing'. So in the rare instances in which one has to be changed out (and they can last decades), odds are that the newest plug in replacements have to emulate the older security protocols. That is to say, none.
The factory LAN on which these PLCs reside has to be made as secure as possible. Ethernet switches and routers that can be configured (and locked down) to reject any unknown MAC addresses. And a very restricted list of well cleaned workstations allowed on to do maintenance. I may be that once connected to the PLC network, 'anybody' can execute certain commands. And that may not be fixable. The task is then to limit the list of 'anybodys' with such access to a trusted group.
A lot of establishments do this. I know someone who worked for a rather large organisation dealing with classified data. They had several computers in the office, but only one had any internet access, and that was never used for classified data. The computers with access to the classified data were connected to a network that had no connection to the internet.
This post has been deleted by its author
I think the problem is that they are a hardware company, and don't really get software.
There are a lot of hardware companies like that. Their idea of after-sales maintenance is that some parts will wear out faster than others and will have to be replaced at scheduled maintenance, and after-sales modifications to the product should be the exception rather than the rule.
It's not so that they "hate" customers as traditionally they expect you use their software on a closed network where machinery, PLCs, switches, sensors etc. implicitly trust one another. And there physical barriers, locked cabinets etc to keep it safe from attack.
<p>
Industry 4.0 is a buzzword some manufacturers are now embracing where they'll have to take security far more seriously. In that model, devices will be able to publish information up to the cloud so there will have to be secure communications and some kind of proxy router to facilitate that without putting the factory at risk.
Most users of PLCs are also not used to updating their firmware. They take the view that if it's working fine, then just to let it be. Why risk production etc especially after it may have taken months to get the software commissioned to work just right.
And I am also sure that some don't even know how many PLCs they have as if they don't have an HMI then it is invisible.
And yes PLCs need to be networked together and mostly will tie up to SCADA and often telemetry systems.
It's a classic case of feature creep, in this case more specifically network attachment creep.
These devices were always designated for use in trusted environments and the vague stab at security was largely there to prevent tinkering by users that weren't privileged enough - almost to protect more from accidental changes than intentional or malicious ones.
A trusted environment in this case is where everything networked together is trusted and no non-trusted systems are connected. This works fine and has worked fine for many years, however then some numpty decides that for convenience they need to connect the trusted network or trusted systems to some other network. This isn't, like the initial comments here, directly connecting to the Internet (although some car manufacturers have genuinely been this incompetent), it's connecting to other networks, such as a more general office network. After all, the management systems, which are inevitably PCs of some flavour, are all usually networked together and the devices that they monitor and manage (through a dedicated communication protocol specifically for it such as ModBus or CANBus) are networked together therefore why not connect everything together? Well, the why not is obvious to anyone with any form of security clue however that often doesn't apply to the typical developer who when confronted with security their default response is to assign or require Administrator access to everything just in case.
Another commenter's remark about just having access to the control network is enough to disrupt things - network packets can be easily spoofed, amended or just flooded any of which are easily capable of disrupting operations and, frankly, without the detailed plans of any specific control network's design and operation the most effective way to damage things would be to flood the network and prevent monitoring messages from being processed. For example, a pressure sensor that sends values directly to a valve controller if the valve controller no longer receives the pressure readings it won't close off if the pressure gets too high - a simplistic example but that's the kind of thing that's commonly implemented.
I had some regular work it at various semiconductor manufacturers in Japan, Taiwan, and Korea, and without exception the machinery would be connected only in isolated networks - e.g., only machines of the the same supplier. Supplier personnel going in the factory gates had to have laptops and discs scanned for viruses, and the disc usage in Mb was recorded, and then checked again on the way out to make sure it was nearly the same. While the limited connectivity was useful, the gate checks were more of a formal show.
I wonder if Japan's Renesas chip plant was isolated as it should have been?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
