Daisy-chained research spells malware worm hell for power plants and other utilities A world-first proof-of-concept worm - if unleashed - could spell disaster for the world’s critical infrastructure, including power utilities by making attacks exponentially more difficult to detect and stop. It is a stand-alone attack but The Register has confirmed a realistic stealthy end-to-end attack scenario can be …
So this exploit relies on two things.
a) someone getting physical access to a PLC unit and 'infecting' it.
b) the engineers that get the unit do no checking on it.
The first is almost impossible to prevent. The second is down to dud working standards and can be prevented with some reorganisation.
c) PLCs networked together without any firewall rules to enforce communications only with a few designated monitor computers. Or fancier intrusion detection.
Of course, one would hope that the monitoring computers were not unpatched Windows boxes due to the PLC suppliers being unable to support open standards and/or be sure that system updates are not going to break poorly written software...
Reading the PDF I would think that blocking Port 102 would stop infection. Therefore if daisy-chaining PLC's together put some kind of traffic-filtering device in between them. Monitoring Port 102 traffic will detect infection.
OK next time the baddies will use a different port, but how many need to be open on a PLC?
This post has been deleted by its author
A couple of fairly lightweight PLCs nailed to a sheet of OSB doesn't look like any power plant control system I have ever seen, and I have seen a few.
And again, the gear is the Siemens S7 series, so what does that tell you ? There are a whole host of other manufacturers out there peddling gear which is better or worse depending upon your requirement and willingness to fully investigate and assess.
Some of this coverage and spin reminds me of the Millennium Bug palaver and how did that turn out.
News Flash - National power generation has moved to a far more distributed model due to the proliferation of Renewable's and CCGT's. Loss of a large monolithic generation plant resulting in a crippled Grid and national infrastructure has become a vanishingly small likelihood due to this new model.
The point is that one can craft a worm that hops from PLC to PLC without needing to go through a PC. It's called proof of concept. Now how vulnerable specific installations and PLCs are is another question. Thus the actual risk varies from complete disaster to almost invulnerable for a specific installation.
Yes, I am questioning the risk assessment.
“Imagine a PLC is intercepted on the way to your plant, or by the vendor; there is little you could do to detect this and it would quickly spread throughout your plant”.
“We can create a denial of service killing infected PLCs … imagine this happening to a major plant.”
I can imagine a lot of things, however with specific knowledge to make an informed risk assessment I can discount a large proportion of what my imagination can come up with.
They are bigging up the proof of concept to create FUD amongst the uninformed.
Y2K bug again anyone?
I think that quote is assuming power-plant owners and the like are not stupid enough to expose their PLCs on an internet routable IP (and hey, stupider things have happened). Also assumes the employees at the power-plant aren't dumb enough to pick up a USB key they find lying on the ground and plug it in to a work computer. And assumes someone at the plant doesn't get spear-phished etc. etc.
I'm sure there are a bunch of plausible attack-vectors that don't involve internet routable IPs. I think the dude being quoted was just picking a random one (not the only one).
This assumes the same type and version of PLC, many mission critical systems will run multiple redundant HW/SW from different manufacturers.
If it was capable of infecting a multitude of systems, then there would be significant risk.
But, there are also other mitigation strategies.
"The access protection can protect the PLC against the worm attack. The write protection prevents anybody from modifying the code on the PLC. The used challenge response authentication is probably secure. If the used password is not known to the worm the worm may not infect the PLC. By default the access protection ist turned off."
So, if you connect a number of PLC devices together with access protection switched off and no password set, they can be reprogrammed. PDF
'Protecting against such attacks, however, is costly', elREG
How about storing the executable bits in ROM that can't be altered without the presence of an authentication device and the programmer entering a password?
That would require a rather long downtime...
And some/many facilities can't be down for more than 10-15 minutes for the entire plant.
This would be for those plants that have to deal with temperature sensitive materials... cool too long and you might have to replace the entire line of machines. FAR too expensive.
There was a time, when I used to work in this field, when "downtime is unacceptable" meant you had two of everything, because downtime was unacceptable and yet things always break. So have two (or three in some cases) boxes configured such that if one breaks, the remaining one(s) can continue.
One of the other benefits of such a setup was that you could do maintenance of the automation system without necessarily incurring downtime.
I guess people whose jobs consist of spreadsheet-jockeying have overruled that kind of expenditure though. After all, all that money spent on mitigating potential Y2K effects was wasted wasn't it, nothing much went wrong.
It's as if (e.g.) Buncefield never happened either:
http://www.hse.gov.uk/comah/buncefield/buncefield-report.pdf
Still, what could possibly go wrong. Ask Charles Haddon Cave QC. The public inquiries he has led mean that he's seen what can go wrong, and more importantly how and why. Those whose families were affected by the various incidents he's investigated (Piper Alpha, Nimrod, and others) also know what can go wrong. There are others similar elsewhere.
Wtf.
"There was a time, when I used to work in this field, when "downtime is unacceptable" meant you had two of everything, because downtime was unacceptable and yet things always break."
But then Murphy's Law hits. Either a common mode failure hits all the redundant systems at once (a tail engine jet rotor uncontained failure hits all FOUR hydraulic lines on BOTH sides), a cascade causes failures to roll over to the redundant systems (El Al 187 lost one engine that crashes into another, they knock out the hydraulics making it impossible to control even with two engines remaining; then there were the North American blackouts), or a failure hits only when one unit is down for necessary maintenance, hitting the redundant one at its moment of weakness (I believe Piper Alpha was this last case).
"How about storing the executable bits in ROM that can't be altered without the presence of an authentication device and the programmer entering a password?"
A processor needs RAM to operate. At some point, the ROM code has to be copied into the internal working memory of the processor, at which point it's vulnerable. Remember, you're dealing with systems that may be targeted by a STATE: meaning few things are off the table.
"the ROM code has to be copied into the internal working memory of the processor, at which point it's vulnerable. "
Says who? Which processor handbook is that in? Not in the Texas 9900, AMD/Zilog Z8000 family, Motorola 68000 family, various MIPS-alikes, all of which have been used in full authority digital engine controls for use on aircraft engines, where code executes direct from ROM because RAM is neither necessary nor appropriate for code.
The rest of your contribution is equally valuable, with the exception of the last sentence.
How, pray tell, does the PROCESSOR know what state it is in if it has no kind of memory of alterable state INSIDE ITSELF to alter? IOW, how does it know how to branch and so on without an array of registers and the like, which (along with the ROM chips) could be swapped out by a state-level adversary, which would probably also be able to steal authentication keys or otherwise defeat authentication systems?
@oldcoder: "That would require a rather long downtime
Yea, lets remotely update the software on this PLC, what could possibly go wrong. And if you need to shutdown an entire plant to update a PLC maybe it's not designed very well. And nobody, I say again, NOBODY updates a live system, especially one controlling critical systems.
So what happens when your critical live system has an in-the-wild exploit and therefore MUST be updated (due to say legal compliance) yet you're told that you CAN'T update it because it cannot be shut down under any circumstances? Now you're caught between Scylla and Charybdis because you're going to be in trouble either way: either you lose compliant because your system's unsafe and prone to sabotage or you break your uptime requirement.
@Charles 9: "So what happens when your critical live system has an in-the-wild exploit and therefore MUST be updated"
Such exploits can't be exploited as they can't overwrite the executable bits. Better to live with such inconvenience. A system that can be remotely updated can be remotely hacked.
An effective preventative measure - I would have thought - is to either reduce the Cycle Time of the PLC to the size of process needed to run or, if the processes being controlled cannot work at that pace then pad out the program with No Op loops so there is very little slack at the end where a rogue process can be inserted.
from the article: repeat those waves with high-frequency components added to cloak a destructive intrusion.
ummm... any electronics person should know that high frequency stuffs can be filtered out by running the signal through a coil... low frequency is filtered via capacitors... the combinations make bandpass filters... those attacks should be easy enough to see or block by filtering out that high-frequency gak...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
