Over 120 PLC models contain a serious vulnerability—and no fix is on the way:
In 2009, the computer worm Stuxnet crippled hundreds of centrifuges inside Iran's Natanz uranium enrichment plant by targeting the software running on the facility's industrial computers, known as programmable logic controllers. The exploited PLCs were made by the automation giant Siemens and were all models from the company's ubiquitous, long-running SIMATIC S7 product series. Now, more than a decade later, Siemens disclosed today that a vulnerability in its S7-1500 series could be exploited by an attacker to silently install malicious firmware on the devices and take full control of them.
The vulnerability was discovered by researchers at the embedded device security firm Red Balloon Security after they spent more than a year developing a methodology to evaluate the S7-1500's firmware, which Siemens has encrypted for added protection since 2013. Firmware is the low-level code that coordinates hardware and software on a computer. The vulnerability stems from a basic error in how the cryptography is implemented, but Siemens can't fix it through a software patch because the scheme is physically burned onto a dedicated ATECC CryptoAuthentication chip. As a result, Siemens says it has no fix planned for any of the 122 S7-1500 PLC models that the company lists as being vulnerable.
Siemens says that because the vulnerability requires physical access to exploit on its own, customers should mitigate the threat by assessing "the risk of physical access to the device in the target deployment" and implementing "measures to make sure that only trusted personnel have access to the physical hardware." The researchers point out, though, that the vulnerability could potentially be chained with other remote access vulnerabilities on the same network as the vulnerable S7-1500 PLCs to deliver the malicious firmware without in-person contact. [...]
[...] "This separate crypto core is a very rudimentary chip. It's not like a big processor, so it doesn't really know who it's talking to or what's going on in the broader context," Red Balloon's Skipper says. "So if you can tell it the right things that you observed the processor telling it, it will talk to you as if you are the processor. So we can get in between the processor and the crypto core and then we basically tell it, 'Hey, we are the processor and we are going to give you some data and we want you to encrypt it.' And the little crypto core isn't going to question that. It just does it."
Siemens notes that the vulnerabilities are not related to the company's own firmware update process and do not give attackers the ability to hijack that distribution channel. But the fact that any S7-1500 can become a firmware-blessing oracle is significant and bestows a power that individual devices should not have, undermining the whole purpose of encrypting the firmware in the first place.
[...] Though Siemens says it is addressing the S7-1500 vulnerability in new models, the population of vulnerable 1500s in industrial control and critical infrastructure systems around the world is extensive, and these units will remain in use for decades.
"Siemens is saying that this will not be fixed, so it's not just a zero-day—this will remain a forever day until all the vulnerable 1500s go out of service," Cui says. "It could be dangerous to leave this unaddressed."
(Score: 4, Interesting) by Mojibake Tengu on Tuesday January 17 2023, @05:51PM (1 child)
The junk actually used in this contraption was https://www.microchip.com/en-us/product/ATECC108A [microchip.com]
That's one pretty backdoor intentionally designed.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 3, Interesting) by driverless on Wednesday January 18 2023, @10:21AM
It's not intentionally designed, it's probably inadvertent. The ATECC devices are weird, incredibly complex and mistake-prone architecture and functionality with no clue as to what application domain they were actually designed for, there's absolutely nothing out there for which you'd look at one of these things and say "ah, that's perfect for what I need to do". One theory I've heard, which is the least implausible one, is as DRM mechanisms for toner cartridges.
(Score: 3, Interesting) by Rich on Tuesday January 17 2023, @06:46PM (5 children)
I wouldn't be disturbed by such a vulnerability on my devices. You've got to disassemble the device down to PCB level and then hook up to I2C or even unsolder the crypto chip. I'd see such a "flaw" more as a guarantee that I actually own it and could find a way to install my own fixed or improved firmware, rather than helplessly being at the whims of some vendor. With the access required, it would be a lot easier to just pull the unit to be compromised and replace it with a nefarious one.
It's not appropriate to invoke the "Stuxnet spectre", which was a networked remote exploit. These S7 thingies might still have some of those, but that's an entirely different issue.
(Score: 2) by crafoo on Tuesday January 17 2023, @06:51PM (4 children)
I must have misread the article. I thought it said that other, remote-access exploits could be used in combination with this?
(Score: 2) by Rich on Wednesday January 18 2023, @03:32AM (1 child)
The only mention of something remote is right at the end of the article "By flashing this malicious firmware on a target device, either physically or by exploiting an existing remote code execution vulnerability, attackers could persistently gain arbitrary code execution and potentially circumvent any official security and firmware updates, without the user’s knowledge."
The wording is extremely bloated and unprecise. It somehow implies "if we could execute arbitrary code on the main SoC, we could ask the Security Chip to calculate the needed header information." However, if that was entirely so, they could simply use one device to compute the headers for a given firmware, and it would no longer require hardware access. I'd say the hack is a much lesser one than e.g. the XBox hack and simply demonstrates that a physically present machine can be observed and manipulated. Even if they couldn't tap into the I2C, because the security was integrated, what would stop really nefarious actors from decapping it and probing the die?
Anyway, it's got nothing to do with Stuxnet, which abused Microsoft's (probably intentionally) flawed Autorun logic to gain control of the supervisor machine and then simply spun the centriguges faster than they could survive (bonus points for faking the display numbers down). The SCADA subunits worked exactly as advertised.
(Score: 2, Informative) by Anonymous Coward on Wednesday January 18 2023, @03:53AM
> spun the centrifuges faster than they could survive
Minor quibble, I thought the hack was to spin the centrifuges up and down to find a critical speed or resonance. Then any tiny imbalance would cause damage in short order. From (poor) memory, the resonance speed was slower than the max speed and in normal operation the device would speed up and pass through the critical/resonance rpm quickly before damage was done.
In the spin cycle, top loading washing machines also operate above resonance. Just as they start spinning, often there are one or two bangs of the tub against the cabinet, this is the resonance rpm. You can work out the frequency by shaking the tub back and forth by hand...varies with the loading.
Once, I fixed a washer that was banging around all the time, turned out that the pivot for the drum assembly (near the floor) was rusty and had some stiction. Lubricating the bearing surfaces fixed the problem.
Hmmm, maybe Stuxnet needs to be re-written in Rust?(grin)
(Score: 2) by driverless on Wednesday January 18 2023, @10:58AM
Both the article and the Red Balloon writeup are extremely vague:
We'll have to wait until the HOST'23 paper is published to find out what they really did. Given the unnecessary complexity of the ATECC devices my guess would be they exploited one of the number of bugs that are bound to be in there.
(Score: 2) by Fnord666 on Thursday January 19 2023, @02:47PM
That is correct. The point is that the firmware is encrypted, but an attacker can take any S7-1500 and use it to encrypt a malicious version of the firmware that the target s7-1500 would accept as legitimate. A remote access exploit could then be used to update the firmware on the target device with the malicious code.
(Score: 2) by DannyB on Wednesday January 18 2023, @07:38PM
Obvious solution: Just don't connect the PLC computers to the internet.
Obvious retort: Ah, but Stuxnet was an attack on an air-gapped PLC computer.
The lower I set my standards the more accomplishments I have.