INFOSEC23 – London – A security vulnerability in the Schneider Electric ION and PowerLogic power meters has been disclosed: They transmit a user ID and password in plaintext with every message.
Given a CVSS vulnerability-severity rating of 8.8 out of 10, the bug would allow an attacker with passive interception capabilities to obtain these credentials, authenticate to the ION/TCP engineering interface (as well as SSH and HTTP interfaces), and change configuration settings or potentially modify firmware.
“It’s obviously not acceptable anymore for an operational technology (OT) product to transmit credentials in in cleartext because anybody that has access to the network and can sniff the traffic will be able to get them, and then do almost whatever they want with the device,” says Daniel dos Santos, head of security research at Forescout. This could include controlling smart meter switches to cause load oscillations that could trigger shutdowns, with the demand (or load) then being passed on to other parts of the grid network. In a worst-case scenario, a domino effect could theoretically lead to a blackout.
Disclosed as part of the Forescout’s Icefall OT research, this vulnerability is one of three announced today at Infosecurity Europe, the other two being denial-of-service (DoS) vulnerabilities in WAGO 740 controllers. Both of the DoS issues are given a severity rating of 4.9.
Schneider said in its advisory that the ION Protocol was created over 30 years ago to bring sophisticated data exchange to digital power meters, and as cybersecurity became a concern, the protocol was enhanced with support for authentication.
But that doesn’t mean there aren’t still security holes, as there often are with legacy code. In fact, dos Santos says the Schneider vulnerability was originally due to be released as part of a bundle of 56 OT flaws in June 2022 but was held up due to patching processes.
“It’s one of those examples of things that were designed at an earlier time, and Schneider definitely recognizes that [this is a vulnerability] and we worked with them to bring it up to the present, by finding the issue and fixing it,” he says.
He adds, “Now this is a secure version of this protocol that has encryption where the credentials are not transmitted in plaintext anymore. So it’s definitely a relevant enough issue that made them reevaluate the need for a secure version of the protocol for a product line that is older but still used a lot.”
Cybersecurity by Design is Still Missing for OT
The Forescout research noted that this showcases that there’s still a lack of fundamental understanding of security-by-design by OT vendors, with recurring design issues that demonstrate a lack of understanding of basic security control design, such as plaintext and/or hardcoded credentials, client-side authentication, stateful control on stateless protocols, missing critical steps in authentication, broken algorithms, and faulty implementations.
As dos Santos says: “Everybody knows that OT has almost no security built by design, right? That’s a fact, but what we always wanted to stress around the fact was the fact that you need to measure how insecure it is. You cannot just say ‘your whole OT is insecure’; you need to say there is insecure engineering, protocols, insecure firmware updates, and so on.”
Forescout used the release of these new vulnerabilities to call on vendors to improve their security testing procedures, and it said products and protocols must remain backward compatible with legacy designs.
Dos Santos says some vendors still have issues with backward compatibility, as legacy products have hardcoded credentials with insecure methods of delivery. “The main reason why things were designed insecurely at the time is because security wasn’t a big concern, but now it’s the need for for backward compatibility and the need for maintaining some product lines that are still used: but there are people still using those because the lifespan is 20 to 30 years.”