The Triton malware is murderous and spreading
technologyreview.com
technologyreview.com
>The targeting of critical infrastructure to disrupt, degrade, or destroy systems is consistent with numerous attack and reconnaissance activities carried out globally by Russian, Iranian, North Korean, U.S., and Israeli nation state actors. Intrusions of this nature do not necessarily indicate an immediate intent to disrupt targeted systems, and may be preparation for a contingency.
This reeks of Stuxnet 2.0
Is that the planned situation here?
One wonders if the governments of the world wouldn't be well advised to go ahead and hack their a couple bits of their own critical infrastructure a couple of times and horribly break it, just to make the point, before a bad actor hacks all the infrastructure. That visibly has huge costs, but it's not clear that the hidden costs of just blithely letting people keep hooking up critical stuff to the Internet isn't orders of magnitude higher.
And by no means could such a result be called a "Black Swan", because that it's going to occur is perfectly predictable. It's only a question of when.
It is odd that the attacker tried to modify the program in the PLC configured this way. They should have known it would cause a noticeable disturbance.
The Schneider Quantum PLC literally runs a pentium 166 or 200 and there is a steady string of firmware and operating system (VxWorks) updates. We had one from 2006 that would simply stop communicating if it was plugged in to a cisco switch from 2016.
A zero day in VxWorks which is the operating system for a large swath of controllers would be pretty bad.
You have a computer there; something that isn't continuously integrating results via hardware but is rather emulating that in software.
The future probably has more of those systems than what I think of when I hear PLC, and maybe that industry has loosened the terms since I was in college, but it's important to call tools what they are so that their shortcomings are obvious.
'A programmable logic controller (PLC) or programmable controller is an industrial digital computer' [0]
PLCs that are computers with digital processors have been around since about 1984. It is exceedingly rare for any digital equipment to still be in service that is more than 30 years old. The equipment may still be working fine but nobody is around who knows how it works, how to program it, or what to do if it stops working. A real con for digital and pro for mechanical systems!
Of course all of the analog systems that preceded the digital ones have been ripped out too. Nobody could be bothered to learn how they worked, parts became scarce, and digital is so much cheaper and faster to develop and own!
[0]: https://en.wikipedia.org/wiki/Programmable_logic_controller
However, it's also not hard to incorporate hardware watchdogs into industrial systems that check for proper running software (& vice versa). I've done them.
It might be time (if it doesn't already exist) for the industrial networks to upgrade to newer security practices though... (eg code signing, encrypted networks, changes to fs, ...)
It is crazy that a Quantum or M340 PLC on an ethernet network basically has unauthenticated DMA. any device on the network can read or write to any addressed memory using the dead simple modbus protocol, and there is some more complicated protocol for reading and writing unaddressed memory.
I don't think Allen Bradley is any better as I don't recall ever having to specify any credentials or any other means of restricting which clients could connect and write to the PLC.
Misconfiguration by developer teams happened all the time. Usually somebody just forgot to build with debug disabled, but sometimes we'd see an engineer leave it on intentionally to make debugging in the field easier for him :facepalm:
>I don't I've quite articulated why I'm so critical of the tech industry. Tech isn't just software anymore. They're coming for ag, food, & manufacturing- & they're bringing a negligent attitudes towards risk & safety that they learned in the cushy world of apps.
And this malware is affecting industries with a strong incentive for safety, think about what that might imply about every other industry.
Heavy industry cares a lot for safety. An exploding refinery is not in any company's best interest. But the systems they rely on have absolutely no notion of security. They have no way to distinguishing between true and spoofed input values that are fed into a control system.
There is some, but not a lot of awareness in the industry that the implicit trust between components in these systems is insecure and ultimately jeopardizes their safety. It is too easy to spoof process values that are sane, but do not reflect the true state of the system. The systems fundamentally miss any mutual authentication between their components.
Process measurement devices typically even offer a simulation mode in their firmware to do just that. At worst, all you have to do is to crack a simple password to gain access to this feature remotely.
She is picking the wrong target. Tech would do security if directed to do security. Business management doesn't care about security.
Until someone has to pay big money or do jail time for lack of security, this will not change.
> That address was registered to the Central Scientific Research Institute of Chemistry and Mechanics in Moscow, a government-owned organization with divisions that focus on critical infrastructure and industrial safety.
Ironic, sounds like they also have the job of subverting critical infrastructure and industrial safety.
https://www.zdnet.com/article/us-software-blew-up-russian-ga...
The actual sabotage involved adding an integer overflow to valve control software, and making sure it took months to hit (so testing would miss it).
What mitigates this (if anything does) is signed code on media you have to work harder to program. Rather than a USB device, this should be some form of media which doesn't present as a bootable device to a BIOS/UEFI. The field unit should have signature checks over images based on PKI. This is what a lot of things do, but somehow it seems not the ones which matter here?
Field upgrade by kermit or xymodem would be better than this, in that narrow regard. -The risk of an unexpected packet hitting the code path is lower if the code upgrade is reading a byte stream for a hash/sig check, compared to mounting a USB device, loading drivers, enabling HID mode ...
I deliberately avoided working in engineering contexts where the risk was above my comfort factor. It ruled out industrial process control, health, civil engineering and a host of fascinating fields, but I was just too worried about the liability side and my own competency to work in these areas.
I did not foresee (inter)net technology becoming so critical it exposed all of these risks, in my core competency. I still feel inadequate to these risks, 37 years later.
'Every' penetration tester I talk to says that this is what they find all the time: actual 'reality' within networks does not align with assumed network policies or topology.
But, I don't talk to that many. Is this really the case? We put great care to have network architectures and policies that define network segmentation, isolation, and other strategies to harden and protect the network. But those policies are not implemented properly, or over time their technical enforcement isn't guaranteed?
About half the time no discernable effort was ever put into airgapping and it was only ever a paper goal. Most of the rest of the time it started out configured reasonably but either drifted out as business needs changed ("Chloe get me a port!" is a pretty common joke) or someone just didn't realize it was special and configured it badly.
The rest of the time you just stack up edge cases: bad management credentials, forgotten management interfaces, canned router or switch exploits, broken q-in-q implementations, etc. The list is endless. And all that's without getting someone authorized to carry you onto the airgapped network, which happens facepalmingly often.
The best solution would be to be air-gapped 24/7, but in cases where that is not possible, there are other viable and more secure approaches than being online 24/7.
I'm wondering why MS has not come out with a similar kind of Windows, wherein every app is effectively sandboxed.
Mobile phones (android) are full of malware, most only get patched for a couple of years at best and these are often late and infrequent. Stricter != safer.
> I'm wondering why MS has not come out with a similar kind of Windows, wherein every app is effectively sandboxed.
That would be windows 10 and the app store included, but it looks like it's limitations led to failure.
Security measures on Win10 are superficial in the sense that any app compiled to the platform can essentially do whatever.
It would I think something quite more fundamental than the app store or signatures, effectively a totally new OS architecture.
https://en.wikipedia.org/wiki/Trustworthy_computing#Microsof...
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
Now, 17 years later, you're wondering if Microsoft shouldn't do better? Exactly how much time are you willing to give those clowns to clean up their act?
This is no regular malware. This is war.
Mike Hayden, 2012 [2]:
> We have entered into a new phase of conflict in which we use a cyberweapon to create physical destruction, and in this case, physical destruction in someone else's critical infrastructure.
Still, an alarming development.
[1] https://en.wikipedia.org/wiki/Stuxnet
[2] https://www.cbsnews.com/news/stuxnet-computer-worm-opens-new...
About a year ago there was a major transformer that blew in downtown SF, knocking most of the fidi offline. I didn't think much of it -- stuff breaks, and this was pre-PG&E fiasco -- but then I heard the same thing happened in NYC and another major city (maybe Seattle?) that same morning. Things break regularly, and there's always some 3-city combined probability function, but it still made me glance over my metaphorical shoulder.
Ideally we'll still be too scared to use nukes in the next hot war. Everything else that makes modern life bearable is fair game, though.
[edit]: LA was the third city, and all failures were traced to physical faults/aging infrastructure: https://www.snopes.com/fact-check/power-outages-la-sf-nyc Like I said, there always is a combined probability function, but point is we're gonna be doing a lot more glancing over our metaphorical shoulders the more we see stories like this.
Targeting civilian infrastructure? With potential mass civilian casualties? That's not in the same league.
If it's from a state it's probably intended to shut down industrial processing. That might require doing something that causes harm, but that's not certain and it's probably not the goal.
Other malware like Stux', and all the various intrusions into power infrastructure etc. that are always being talked about in the media, all share that same purpose - shutting down the logistical or productive capacity of a country, either in a very specific area like Israel v Iran re Nuclear or in a wider sense, like turning off the electricity.