4 ms·

Redundant Safety PLCs run the same program in parallel in lockstep and if they get different results then this triggers an error. I think Triconex in particular

Redundant Safety PLCs run the same program in parallel in lockstep and if they get different results then this triggers an error. I think Triconex in particular requires 2 out of 3 controllers to agree. 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.

mjevans 8y ago
I don't want to call anything without dedicated gates and hard traces a 'PLC'. 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.
- snowwindwaves 8y ago
  sounds like the definition has changed since you were in college: '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 https://en.wikipedia.org/wiki/Programmable_logic_controller
  - mjevans 8y ago
    Maybe I'm mis-remembering plD where D was device, but at the same time a single letter of differentiation, and one that is pronounced similarly, is asking for this kind of error in communication/memory.
- cmroanirgo 8y ago
  As you know PLC is just s programmable logic controller. All computers are, by definition, that. Perhaps you're referring to the 'gated logic' programs that exist? To me they're just like the old punch cards, but with the purpose of controlling a contactor -- they're very simple systems indeed. 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, ...)
  - snowwindwaves 8y ago
    I haven't worked with it yet but Schneider's M580 PLC I believe even supports authentication! 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.
    - gmueckl 8y ago
      All de facto modbus implementations that I am familiar with use virtualized register banks that map to higher level parameter accesses including input validation. So the shenanigans you should be able to do with then are somewhat limited. But there is no authentication at all. This was designed at a time when notion of having a bad actor mess with an control system was not even invented yet.
  - gmueckl 8y ago
    Upgrading control systems in a plant is both costly and risky. You incur significant downtime to replace expensive equipment that has a really long life time. And then shaking down the new systems is going to cause additional costs and likely also a temporary decrease in the quality of the plant's output. This is why the industry is basically stuck in a state where the most widespread standards originated in ancient, sometimes even analog times and have had tons of extensions tacked on in ways that preserved compatibility. So all of these devices operate based on pure trust. Bad input is rather attributed to failures than deliberate malicious actors inside the system. Nothing is authenticated. None of the field bus systems I am familiar with could be upgraded to incorporate that kind of distrust between components.
freedomben 8y ago
Agreed, but it wouldn't even necessarily take a VxWorks zero day. Having worked in the industry as a security professional, you'd be amazed at how many embedded devices ship with VxWorks debug ports open and listening, with default (or easy) passwords. The debugger is basically a C interpreter, so an attacker has totally pwned the box if they know what they are doing and get to that port. 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:
jnwatson 8y ago
Speaking as a former embedded and now in the infosec space, I think a zero day in VxWorks is trivial. It was used because it is easily hackable (originally in the fun sense now the bad sense).

mjevans 8y ago

I don't want to call anything without dedicated gates and hard traces a 'PLC'. 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.

snowwindwaves 8y ago
sounds like the definition has changed since you were in college: '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 https://en.wikipedia.org/wiki/Programmable_logic_controller
- mjevans 8y ago
  Maybe I'm mis-remembering plD where D was device, but at the same time a single letter of differentiation, and one that is pronounced similarly, is asking for this kind of error in communication/memory.
cmroanirgo 8y ago
As you know PLC is just s programmable logic controller. All computers are, by definition, that. Perhaps you're referring to the 'gated logic' programs that exist? To me they're just like the old punch cards, but with the purpose of controlling a contactor -- they're very simple systems indeed. 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, ...)
- snowwindwaves 8y ago
  I haven't worked with it yet but Schneider's M580 PLC I believe even supports authentication! 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.
  - gmueckl 8y ago
    All de facto modbus implementations that I am familiar with use virtualized register banks that map to higher level parameter accesses including input validation. So the shenanigans you should be able to do with then are somewhat limited. But there is no authentication at all. This was designed at a time when notion of having a bad actor mess with an control system was not even invented yet.
- gmueckl 8y ago
  Upgrading control systems in a plant is both costly and risky. You incur significant downtime to replace expensive equipment that has a really long life time. And then shaking down the new systems is going to cause additional costs and likely also a temporary decrease in the quality of the plant's output. This is why the industry is basically stuck in a state where the most widespread standards originated in ancient, sometimes even analog times and have had tons of extensions tacked on in ways that preserved compatibility. So all of these devices operate based on pure trust. Bad input is rather attributed to failures than deliberate malicious actors inside the system. Nothing is authenticated. None of the field bus systems I am familiar with could be upgraded to incorporate that kind of distrust between components.

freedomben 8y ago

Agreed, but it wouldn't even necessarily take a VxWorks zero day. Having worked in the industry as a security professional, you'd be amazed at how many embedded devices ship with VxWorks debug ports open and listening, with default (or easy) passwords. The debugger is basically a C interpreter, so an attacker has totally pwned the box if they know what they are doing and get to that port. 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:

jnwatson 8y ago

Speaking as a former embedded and now in the infosec space, I think a zero day in VxWorks is trivial. It was used because it is easily hackable (originally in the fun sense now the bad sense).