Researchers warn of unpatched remote code execution flaws in Schneider Electric industrial gear
- Reference: 1626173107
- News link: https://www.theregister.co.uk/2021/07/13/armis_schneider_electric_flaw/
- Source link:
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," are designed to connect industrial equipment – from oil and gas pipelines to manufacturing systems and water purification facilities – to a network. Sadly, they appear to have something of an undocumented feature: letting anyone take control of said equipment using hidden commands and an authentication bypass.
"Armis researchers found that these commands can be used to take over the PLC and gain native code execution on the device which can be used to alter the operation of the PLC, while hiding the alterations from the engineering workstation that manages the PLC. This attack is an unauthenticated attack that only requires network access to the targeted PLCs." the [1]infosec analyst said .
[2]
The vulnerability itself, dubbed "ModiPwn," chains on two previously disclosed issues, discovered by security firm Talos in 2018 and 2019 respectively, which Schneider Electric claimed to have patched. The Armis researchers discovered the patches were effective only when an application password was set – and then found a number of ways to bypass said password, opening the holes back up for all even on the latest software release.
[3]
[4]
Worse, the flaws which had originally been classified as leading to denial-of-service (DoS) attacks were found to allow remote code execution – meaning an unauthenticated attacker could take full control of the PLC and, by extension, whatever industrial equipment it was controlling.
Schneider Electric confirmed the vulnerabilities and promised a patch would be released by the end of this year, but a purported security advisory
[5]PDF
was made available for download a little prematurely: rather than the promised technical details and mitigation advice which would keep customers safe pending the release of a proper patch, the document available at the time of writing was wholly blank save for the single word "Internal" at the bottom.[6]If you miss the happier times of the 2000s, just look up today's SCADA gear which still has Stuxnet-style holes
[7]Vlad that's over: Remote code flaws in Schneider Electric apps whacked
[8]UK engineering software firm swallowed in £3bn merger with France's Schneider Electric
[9]Schneider Electric still shipping passwords in firmware
Unfortunately for Schneider Electric customers, the devices can't be considered fully secure even once the patch is out and applied. "Other bypass techniques remain unpatched due to design limitations," the Armis researchers warned, adding that while the company had promised to adopt 2018's Modbus Security standard [10]by 2020 it had failed to do so.
As for what Modicon users can do to protect themselves, the researchers offered some tips: "Armis strongly recommends the use of Schneider Electric guidelines for secure configuration of Modicon PLCs such as the use of application passwords in project files, properly using network segmentation, and implementing access control lists to shield industrial controllers from unwanted communications and attacks."
[11]
"Compromised passwords are at the heart of frustration for any information security team, but when coupled up with sophisticated new attempts to bypass a second layer of authentication, the heat is really turned on," ESET UK cybersecurity expert Jake Moore told The Register .
This is far from the first time Schneider Electric's industrial control products have been targeted by ne'er-do-wells. In 2017 a group using what became known as the Triton malware breached Schneider Electric devices installed at a Saudi oil and gas facility in an attack later traced to a [12]Kremlin-backed facility in Moscow .
"Schneider Electric is committed to collaborating openly and transparently. In this case, we have collaborated with these researchers to validate the research and to assess its true impact," the company wrote in an official statement. "Our mutual findings demonstrate that while the discovered vulnerabilities affect Schneider Electric offers, it is possible to mitigate the potential impacts by following standard guidance, specific instructions; and in some cases, the fixes provided by Schneider Electric to remove the vulnerability.
[13]
"As always, we appreciate and applaud independent cybersecurity research because, as in this case, it helps the global manufacturing industry strengthen our collective ability to prevent and respond to cyber-attacks. Together, we continue to encourage the ecosystem of automation suppliers, cybersecurity solution providers, and end-users to collaborate to reduce cybersecurity risks; and support our customers to ensure they have implemented cybersecurity best practices across their operations and supply chains."
Schneider Electric did not respond to follow-up questions on its Modbus Security progress or lack thereof, the location of the correct vulnerability notice and mitigation advice, nor on a firm timescale for fixing what are, contrary to the above statement, still-unpatched security vulnerabilities.
The problem extends beyond Schneider Electric, though. "It is clear the underlying design flaws in UMAS [Schneider's extensions to Modbus] and Modbus remain unfixed for the time being," the Armis researchers warned. "While attempts to harden access to certain commands are being introduced, these design flaws create significant challenges for the developers - which will likely lead to additional vulnerabilities in the future."
Full technical details of the vulnerability have been published [14]here .
Updated at 15.52BST on 13 July 2021 to add:
Following publication of this article, Schneider Electric has fixed the blank security advisory, publishing a document [15]detailing the precise models and software versions affected by the vulnerabilities along with mitigation advice for preventing their exploitation. ®
Get our [16]Tech Resources
[1] https://www.armis.com/research/modipwn/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YO24pPF075NTX27lKzs0FAAAAEc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YO24pPF075NTX27lKzs0FAAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YO24pPF075NTX27lKzs0FAAAAEc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] http://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-194-01
[6] https://www.theregister.com/2020/05/08/schneider_electric_plc_vulnerability/
[7] https://www.theregister.com/2018/05/02/security_firm_uncovers_zeroday_exploit_in_critical_infrastructure_software/
[8] https://www.theregister.com/2017/09/05/uk_engineering_software_firm_dies_for_550_million/
[9] https://www.theregister.com/2017/04/05/schneider_istilli_shipping_passwords_in_firmware/
[10] https://blog.se.com/machine-and-process-management/2018/08/30/modbus-security-new-protocol-to-improve-control-system-security/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YO24pPF075NTX27lKzs0FAAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://www.theregister.com/2018/10/24/triton_malware_attack/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YO24pPF075NTX27lKzs0FAAAAEc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://www.armis.com/research/modipwn/
[15] https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-194-01
[16] https://whitepapers.theregister.com/
Re: air gap - Air Gap - AIR GAP
Yes, from a bean-counter/PHB point of view, it's cheaper to have your critical infrastructure manageable hackable remotely rather than pay some poor techie overtime for a change,,,
Re: air gap - Air Gap - AIR GAP
Fully agree, some of my early IT roles were in industrial systems & security of the PLCs and other hardware was minimal, but nobody cared as it was expected to be an internal only system (no external exposure)
Re: air gap - Air Gap - AIR GAP
"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.
Re: air gap - Air Gap - AIR GAP
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.
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.
This is unsurprising
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.
air gap - Air Gap - AIR GAP
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 ==========>