I opened Siemens TIA Portal and PLCSIM for the first time and thought “wow, I didn’t think the Windows 95 GUI library was still supported.” None of the PLC contractors we had hired knew how to enable TLS on the thing (user/pass eg admin/admin was their usual). Anecdote: I once spent hours reading the docs and clicking around trying to get it to accept an SSL certificate signed by a real CA and it wouldn’t go, but it accepted one I self-signed in openssl.
In all fairness, the people who are experts in the field of Siemens PLC programming are usually mechanical-ish engineers and security is not in their skill set or on their mind.
The PLC engineers I had contact with usually had an electrical engineering background. That's why they like PLCs in the first place with the ladder logic programming languages, grafcet and if they feel fancy a bit of structured text (assembly like) or structured control language (pascal like). They indeed did not know much about software security but a great deal about machine safety.
A real security nightmare are older OPC servers (OPC-DA) which is super reliant on DCOM. OPC is quite important to connect the PLCs to SCADA systems or 3rd party devices.
Then someone plugs in a cable because boss wants something "over there" and there's already a network that runs "over there". Or optimizes to a smart switch with vlans, and then someone else optimizes to a single vlan. It's not hard to not give a shit, or not understand, network security.
On my project the service I wrote was doing bidirectional communication with the PLC over OPCUA. The server running this pod was connected to the internet, so it was critical to have proper TLS for the OPCUA client/server. Rotating LetsEncrypt certs on the system every 45 days is a lot of toil, but using a self-signed cert that expires in 2040 from some dev laptop doesn’t pass muster in most organizations either.
That’s just the OPCUA path.. In these projects You also typically see WinCC HMIs that can talk to the PLC from anywhere on the network without TLS. And also SIMATIC Web Server pages - minimally secured by default, and the amount of info you can grok about the system in Chrome Dev Tools is troubling.
Not really dissimilar from the human upbringing: leave a baby with "bad" guardians, and it will grow up corrupted. That's a feature, not a bug: if you knew what behaviour exactly you wanted (other than "whatever Simon says"), you would just bake it in in the first place, right?
Because a half dozen a day sounds plausible as standard maintenance issues, as the author acknowledges. If it were a hack, I'd expect something like 50% of them to have problems. But not knowing how many there are, I don't know how significant these incidents really are.
The problem is the author should have put a few concise bullet points at the top. (14 freezers failed at the same time. They are all internet-controlled, and failed at the same time as a disclosure about a vulnerability. They all failed by turning on the defrost cycle and heating food.)
I really recommend skimming the article to the end.
(Unfortunately, the article really is so verbose it's a borderline rant.)
Not just any failure, specifically heating the food (defrost) so it goes bad. Happening overnight, so it wouldn't be caught before it's too late.
All that could still be a coincidence, but the more coincidences start to pile up the more we have to consider other possibilities too. I do agree it would be unusual to 'waste' a vuln like that, but perhaps the implant/CVE was about to be exposed anyway.
Interesting times...
according to the article, the denominator is ~235.
An attack like the author hypothesized would require a LOTL modus operandi, and doing so on 14 locations wouldn't justify completely blowing up an entire LOTL operation, because it exposes indicators, registers, and tradecraft that is then shared amongst all security vendors.
The way it's framed is clickbait at its worst with the added issue of limited security experience, but the same can be said of HN in general.
I've seen batch failures in radio equipment where I could predict 100% accurately which devices would fail based on the range of serial numbers.
Could be a hack or a design flaw. I await the root cause analysis.
It's also possible that, because the US is busy bombing Iran, Iran may be busy attacking the US infrastructure in any way possible? The US is also in a tepid war with russia, last I checked.
Some "cyber" crew getting a shell on an outsourced service provider and running a "defrost" command is also a totally explanation for this situation. It's also totally possible that some crew has mapped out a list of PLC entry points for various orgs and has them in a spreadsheet of "if we find a vulnerability, we should X this Y with this prestaged script that our intern / LMM cooked up last year to defrost these freezers"
Regardless if this was a hack or a bug, the bigger lesson is that overcomplicated systems fail in catastrophic ways. Why do military commissaries need remote-controlled freezers? It seems like a very fragile, and needless, way to run a freezer.
---
But, there are some options that the author didn't consider:
1: This could be a quickly applied patch that failed.
2: This could be a "script kiddie" hack from someone who isn't a government actor.
I'm less onboard with a state actor. Generally, when a state actor has hacked something, they don't want the victim to know. In this case, if it was a state actor, I would anticipate that they would make a single freezer fail in a way that they could verify using something like a hacked video camera or otherwise by watching public social media feeds. IMO: A state actor would only "make sense" if they knew the hole was closing soon and they don't care if they're discovered, perhaps because their operation is winding down.
Could be the Iranians, or someone aligned, conducting anti-morale operations. Could be the start of a series of small but annoying failures.
Unfortunately, I would wager that all BAS software is full of flaws and holes, allowing access to it for the public internet seems like a bad idea. I need to be on my company VPN to access our locally hosted BAS front end (which I have authorized access for) which seems like the bare minimum security.
Should be much closer to the top of the article. Otherwise this is just weird and potentially dangerously wrong research.
> "I'm sorry I'm familiar with that function. Let me research enabling defrost for you."
Not exactly strong evidence presented here, but it wouldn't be a surprise either
A. This technology is inherently crap, that's our fault
B. A bored teenager broke it. Bored teenagers are a thing, it literally doesn't matter which country they are in, stop building things bored teenagers will blow up, this is also inherently our fault
C. Foreign Adversaries
It suits both mass media audience figures and a narrative of wily enemies rather than incompetence to pin everything on C and it seems eminently possible that a country with as many enemies as the US would attract this sometimes, but the reality is that both A and B are much more likely despite being embarrassing.
We know there's been a severe rot of operational capabilities in the military thanks for Hegseths purges and general stupidity. It's entirely possible and quite likely that over the course of his various drunken binges he decided to get rid of people who were in charge of operational control for stuff like freezers across military bases.
“If sovereign and subject are in accord, put division between them.” —Sun Tzu, The Art of War
Unlikely to be a hack, more likely to be a misconfiguration or update sent incorrectly.
That said, the timing of the disclosure and the issue are rather concerning.
Regarding the highest value targets to hit with an attack like this, you would want to target Guam, Hawai'i, and other isolated overseas locations where this would have ripple effects in the local economy. Guam specifically would cause catastrophic supply shortages, since DeCA probably supplies around 50% of the groceries on that island (that's a WAG based on my time there).
Hawaii I'm not sure why that would be an issue unless the whole island was attacked or shut down. Even if the on-base shops were hacked you could just go shop at Wal-Mart or Costco or any number of other locations on the islands. If there was an extended issue then the commander could authorize meal stipends as they do for some units today and then you would just go buy food off-base. Ideal? No. Manageable? Very much.