Can malware destroy stuff IRL?

Pi1otguy

En-Route
Joined
Oct 24, 2007
Messages
2,519
Location
Fontana, CA
Display Name
Fox McCloud
Home Airfield
KRAL
http://news.yahoo.com/s/csm/20100921/ts_csm/327178
article said:
Cyber security experts say they have identified the world's first known cyber super weapon designed specifically to destroy a real-world target – a factory, a refinery, or just maybe a nuclear power plant.
By August, researchers had found something more disturbing: Stuxnet appeared to be able to take control of the automated factory control systems it had infected – and do whatever it was programmed to do with them.
Assuming the malware "owns" the targeted computer and commands the attached equipment to exceed design limits wouldn't an isolated fail safe be triggered anyway? If not, wouldn't the staff just begin a shutdown the old fashion way with valves and switches? Surly nobody designs a factory or power plant without redundant fail-safes.
 
Last edited:
Surly nobody designs a factory or power plant without redundant fail-safes.

Surely nobody would design a military reconnisance aircraft that would broadcast it's video feed completely unencrypted, right?

Oh, wait. :frown2:

I'm no longer surprised at this kind of non-robust design. Lowest bidder, ya know.
 
Surely nobody would design a military reconnisance aircraft that would broadcast it's video feed completely unencrypted, right?

Oh, wait. :frown2:

I'm no longer surprised at this kind of non-robust design. Lowest bidder, ya know.

Yes, and the other side of that coin is if the UAV gets shot down, you don't want its encryption technology ending up in the wrong hands.
 
http://news.yahoo.com/s/csm/20100921/ts_csm/327178

Assuming the malware "owns" the targeted computer and commands the attached equipment to exceed design limits wouldn't an isolated fail safe be triggered anyway? If not, wouldn't the staff just begin a shutdown the old fashion way with valves and switches? Surly nobody designs a factory or power plant without redundant fail-safes.

I suppose it can happen so fast, the operators might not have time to do anything.

Software bugs have certainly caused real-world damage:

http://www.wired.com/software/coolapps/news/2005/11/69355
 
Yes, and the other side of that coin is if the UAV gets shot down, you don't want its encryption technology ending up in the wrong hands.

The chances of them being able to hack the encryption (which can easily be changed) are much less than the chances of them getting the video feed - Well, 'cuz that's already happened. Mostly because the chips are fairly likely to get fried if the ship is shot down or crashes.
 
http://news.yahoo.com/s/csm/20100921/ts_csm/327178

Assuming the malware "owns" the targeted computer and commands the attached equipment to exceed design limits wouldn't an isolated fail safe be triggered anyway? If not, wouldn't the staff just begin a shutdown the old fashion way with valves and switches? Surly nobody designs a factory or power plant without redundant fail-safes.

That would depend significantly on the design requirements specified at the time the product was created. Most control systems are designed with certain assumptions of the potential failure modes and the "fail safes" (there is no such thing as total failure safe) would be implemented to cover those specific threats. Most often the anticipated failure modes involve malfunctions of internal and external hardware along with some obvious design/implementation gotchas. Covering deliberate attempts to cause damage is neither easy nor common. I suspect that the best one could hope for is that a physically secure portion of the control system can detect improper behavior of the rest and override before something serious happens but if the unsecure (subject to hacking through remote access) parts of the system have nearly total control, chances are someone with enough knowledge of the system could work around any safeguards beyond the hacker's direct control.

That said, I suspect the article linked in this thread contains a fair amount of hyperbolic extrapolation WRT the malware's abilities. As to the potential to infect "without the user taking any action or clicking any button", that aspect of malware has been around for a long time (at least since the days of floppy disks) but it's generally not terribly difficult to prevent such an infection route with a combination of software practices and human security measures.
 
Last edited:
Yes, and the other side of that coin is if the UAV gets shot down, you don't want its encryption technology ending up in the wrong hands.
Maybe. Some of the encryption algorithms are extremely difficult to crack even if you know how the code works.
 
The Navy UAV that headed north into the ADIZ solo should tell you the answer. If it isn't wholly mechanical, it can be compromised.
 
Sure, malware could do this. If a system uses a computerized device to control a physical process, then the malware could attack this controller and cause it to do something or ignore something that causes destructive results.

An example might be a pressure control loop in a cooling system. There could be a computerized controller that manages the coolant fluid pump on/off based on temperature of the system. Malware could infect the microcontroller in this system, and cause it to ignore temperature inputs, or falsely state that the temperature is too cool, thereby shutting off the pump. The system then overheats causing real physical damage.

IRL, the risk of this is fairly low... Yes, there are an insane number of microcontrollers and computers managing physical things, but their connections to the outside world, programming models, and operating systems tend to be proprietary or closed enough that they are hard to determine from the outside looking in (unlike Windows and the standard PC architecture). So, they can be quite difficult to hack. But, if someone spent enough time and had enough insight into the components and architecture of a system, it many cases, it can be done.
 
Sure, malware could do this. If a system uses a computerized device to control a physical process, then the malware could attack this controller and cause it to do something or ignore something that causes destructive results.

An example might be a pressure control loop in a cooling system. There could be a computerized controller that manages the coolant fluid pump on/off based on temperature of the system. Malware could infect the microcontroller in this system, and cause it to ignore temperature inputs, or falsely state that the temperature is too cool, thereby shutting off the pump. The system then overheats causing real physical damage.

IRL, the risk of this is fairly low... Yes, there are an insane number of microcontrollers and computers managing physical things, but their connections to the outside world, programming models, and operating systems tend to be proprietary or closed enough that they are hard to determine from the outside looking in (unlike Windows and the standard PC architecture). So, they can be quite difficult to hack. But, if someone spent enough time and had enough insight into the components and architecture of a system, it many cases, it can be done.

The article discusses taking over the intended function of PLCs, something I believe to be extremely far fetched. I've done a fair amount of work setting up PLCs to control machines and processes. Most of the time there's no comm path in place to the PLC that would allow any modification of the PLC's application or OS, typically just parameter passing. And unlike PC apps there's zero potential for overflowing data areas and overwriting code since the platform provided by the PLC's OS is essentially a Harvard Architecture (code segregated from data) so even if the malware had direct control of all comm to/from the PLC (which in itself while feasible is rather unlikely), the worst that could happen is that the PLC would be given false data, and that's far short of what the article portrays as a viable outcome.

A decent analogy would be punching buttons on the climate controls of a luxury car. You could definitely cause the system to raise or lower the vehicle's cabin temp beyond comfortable limits but you won't be able to cause a meltdown of the engine driven compressor unless the designers of the system felt a need to include that capability.
 
Interesting how this thing spreads. If you put a USB stick in your Windows PC and display the contents of the folder/stick in Windows Explorer, just SHOWING THE ICONS will infect your machine--you don't even have to open any of the files:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2568

It leveraged a vulnerability in how Windows Explorer parses the icons on shortcut files to generate the display icon for the screen. Wow. Put the stick in, it shows the icons for the files on the USB flash drive, and runs code looking for a Siemens SCADA system to infect on the network.
 
The article discusses taking over the intended function of PLCs, something I believe to be extremely far fetched. I've done a fair amount of work setting up PLCs to control machines and processes. Most of the time there's no comm path in place to the PLC that would allow any modification of the PLC's application or OS, typically just parameter passing. And unlike PC apps there's zero potential for overflowing data areas and overwriting code since the platform provided by the PLC's OS is essentially a Harvard Architecture (code segregated from data) so even if the malware had direct control of all comm to/from the PLC (which in itself while feasible is rather unlikely), the worst that could happen is that the PLC would be given false data, and that's far short of what the article portrays as a viable outcome.

A decent analogy would be punching buttons on the climate controls of a luxury car. You could definitely cause the system to raise or lower the vehicle's cabin temp beyond comfortable limits but you won't be able to cause a meltdown of the engine driven compressor unless the designers of the system felt a need to include that capability.

The US-CERT report above seems to concur with your opinion:

On Sept 7th, Siemens also updated their support site to indicate that they were aware of 15 infections worldwide. According to Siemens, in none of the cases did the infection cause an adverse impact to the automation system.
 
http://www.us-cert.gov/control_systems/pdf/ICSA-10-238-01B - Stuxnet Mitigation.pdf

The US Computer Emergency Readiness Team (US-CERT) is most definitely engaged. Writeup at the link above.

But it's been 4 months and they are still analyzing it. In theory, a decently funded gov agency or group of individuals could hamper productivity by forcing companies to rebuild or restore systems.

It leveraged a vulnerability in how Windows Explorer parses the icons on shortcut files to generate the display icon for the screen. Wow. Put the stick in, it shows the icons for the files on the USB flash drive, and runs code looking for a Siemens SCADA system to infect on the network.

If I was a conspiracy nut I'd wager that MS put these subtle 0-days in at the request of the US gov. Just as with the *.wmf issue sometime ago I don't see a good reason for a picture file to be able to overflow at this point in time.

A decent analogy would be punching buttons on the climate controls of a luxury car. You could definitely cause the system to raise or lower the vehicle's cabin temp beyond comfortable limits but you won't be able to cause a meltdown of the engine driven compressor unless the designers of the system felt a need to include that capability.

But in theory such actions could sour the end product. Perhaps equipment destruction was merely a secondary objective. I suppose one could shorten the life of the equipment by running a generator or something at the higher end of it's capacity? Forcing your foe to budget extra cash ahead of schedule?
 
But in theory such actions could sour the end product. Perhaps equipment destruction was merely a secondary objective. I suppose one could shorten the life of the equipment by running a generator or something at the higher end of it's capacity? Forcing your foe to budget extra cash ahead of schedule?
Again, the article focused on direct attacks against applications and "operating systems" (very loosely related to something like Linux or Windows) in PLCs specifically PLCs made by Siemens (some of which I've been intimately familiar with) and my point is there is no real vulnerability there, at least not in anything Siemens supplies. The only potential vulnerabilities I can see would be in a system that incorporated something like Windows based computers that communicated with and controlled the PLCs. This is a fairly common approach, at least WRT some of the SCADA systems I've seen, however it's also standard practice to design the PLC programs which control things at the "nuts and bolts" level such that improper commands from above cannot cause physical damage to the controlled machines and those PLC programs would not be subject to what we think of as a computer virus without some level of human intervention at the local level.

I guess what I'm really trying to say is that as near as I can tell the article was written by someone who didn't really have a clue what they were writing about and likely was intended to sensationalize a non-issue.
 
[snip]
I guess what I'm really trying to say is that as near as I can tell the article was written by someone who didn't really have a clue what they were writing about and likely was intended to sensationalize a non-issue.

Really!?! I'm shocked...:wink2:
 
I realize PLC's are part of this system discussion, but wasn't the issue that this worm ended up on PC based SCADA systems running Siemens WinCC?

It sounds like what you are saying is that since a SCADA is essentially sending operator commands to the PLC and since the PLC should have proper limits around various settings, then this would not be an issue.
 
Back
Top