It reads like Sci-Fi. More about Stuxnet.

[CADsortaGUY]

The worm compromised Siemens WinCC software. Once said software was compromised, modified function blocks were written to the PLCs. Then these modified function blocks were obfuscated from the WinCC software.

This seems to be the case as it is what provided the platform jump.


***********

What I as a controls programmer find intriguing is the cross platform movement of the worm. Very specific pieces would have to be in place and an in depth understanding of the process and the specific hardwares being used to pull something like this off.

 

[Londo_Jowo]

You're misinterpreting here. The infection caused modifications to the control system in place. Depending on how that control system is coded, the added program blocks may not even be accessed thereby you can have an infected system without "an adverse impact to the automation system."

It's also said if the blocks were already used in the program they weren't modified by the worm.

 

[Londo_Jowo]

You don't have to take over the equipment. Iran was using centrifuges to purify uranium. They need to turn at a specific RPM .Malware targets a specific variable in the software that controls RPM so that when executed it subtracts 300 from the desired speed before it is sent to the hardware . Next they add back the 300 to the speed variable before the RPM speed is read by displays or user programs.

To the user the readouts look normal and they think the centrifuge is spinning at the speed they set. They don't know it is spinning at 300 less because the software tells them the wrong speed.

If someone takes apart the control logic it would look perfectly normal. They didn't compromise the hardware, just the commands sent to it from the windows pc.

All the HMI systems I've worked around the setpoints are password protected. I seriously doubt the worm could get around a password protected input.

 

[ProfJohn]

None of this would have happened if Iran had used Macs...

 

[NaughtyGeek]

This seems to be the case as it is what provided the platform jump.


***********

What I as a controls programmer find intriguing is the cross platform movement of the worm. Very specific pieces would have to be in place and an in depth understanding of the process and the specific hardwares being used to pull something like this off.

This is one of the biggest pieces that are causing industry experts to suspect state actors. As a controls programmer you know that just randomly inserting code into a PLC isn't going to necessarily cause any reaction from the system. To specifically target the rotational speed of a centrifuge would require having that centrifuge's program to work with. It's not likely that a hacker or even a group of hackers is going to have the resources to obtain the PLC code of a nuclear centrifuge. The zero days pale in comparison to this little nugget IMO.

 

[CADsortaGUY]

This is one of the biggest pieces that are causing industry experts to suspect state actors. As a controls programmer you know that just randomly inserting code into a PLC isn't going to necessarily cause any reaction from the system. To specifically target the rotational speed of a centrifuge would require having that centrifuge's program to work with. It's not likely that a hacker or even a group of hackers is going to have the resources to obtain the PLC code of a nuclear centrifuge. The zero days pale in comparison to this little nugget IMO.

Exactly why it intrigues me. It sounds like the embedded code of the freq converter(drive or otherwise) was compromised/masked/???. You'd think that a couple CTs/power monitors/ or <gasp> unlinking the speed feedback from the drive? would have been able to capture the problem if their attempts at a software trap(log if you will) didn't show any issue. But I guess I'm not sure I'd think of that either if the code is right and the drive feedback was correct. However, if I saw a speed issue and nothing was reporting it - I'd sure as hell start unlinking things until it stopped.
I've not looked into this whole thing much as I don't deal much with siemens(mainly an A-B guy) but I suppose I should read up on it just because it's kinda cool.

 

[Londo_Jowo]

The Siemens PLC's I worked with 2 years ago used Function Block programming. It would be difficult to change the program as the blocks need to be linked to each other to create the logic. So inserting blocks without specific links to other blocks will have no effect on the running program..

 

[pcgeek11]

I can't believe that Siemens was using a Windows OS to control the centrifuges. Siemens normally uses their own Program Logic Controllers (PLC) with embedded "C" code based logic to control steam and gas turbine functions.

Most Siemens HMI Controllers are Windows based PCs and are connected to a PLC ( via ethernet or CAN Bus or whatever ) that actually runs the machine and handles the I/O. The Siemens control program runs on top of Windows.

It would be simpler to have a program running on the Windows system to alter the parameter for the speed and send it to the PLC and on to the drive inverter to change the speed and then compensate the reading that is displayed on the HMI. Most Drive inverters have a small display that can display the actual freq, speed if they had chosen to look at it vice accepting what the HMI was showing them.

 

[Londo_Jowo]

Most Siemens HMI Controllers are Windows based PCs and are connected to a PLC ( via ethernet or CAN Bus or whatever ) that actually runs the machine and handles the I/O.

As do Allen-Bradley (RSView) and GE Fanuc (Proficy) HMI's. Wonderware is a third party HMI that can access most PLC's. Just because they can talk to the PLC doesn't mean they can do this without specific instructions and addresses.

 

[pcgeek11]

As do Allen-Bradley (RSView) and GE Fanuc (Proficy) HMI's. Wonderware is a third party HMI that can access most PLC's. Just because they can talk to the PLC doesn't mean they can do this without specific instructions and addresses.

I didn't say that they could. Some inside knowledge would be a must, such as what parameter etc... This would certainly have to have some inside assistance.

 

[Londo_Jowo]

I didn't say that they could. Some inside knowledge would be a must, such as what parameter etc... This would certainly have to have some inside assistance.

Unless the people that wrote Stuxnet had intimate knowledge of the HMI configuration and PLC logic for the centrifuges this story is bullshit.

 

[SamurAchzar]

Nothing advanced about it. There are far more complex coded malware out there.

Someone is an idiot, either all the security analysts who checked it and claimed what they did, or you.

 

[NaughtyGeek]

Unless the people that wrote Stuxnet had intimate knowledge of the HMI configuration and PLC logic for the centrifuges this story is bullshit.

The story isn't bullshit. The whole point, though maybe not portrayed in this article, is that whoever wrote the virus had the knowledge required which points to a state sponsored organization.

 

[SamurAchzar]

The story isn't bullshit. The whole point, though maybe not portrayed in this article, is that whoever wrote the virus had the knowledge required which points to a state sponsored organization.

Yep, that's the thing. This undertaking is exemplary in any way you look at it - intelligence, logistics or technical capability. This is nearly uncomprehendingly complicated.

 

[Londo_Jowo]

The only way this could happen is due to poorly written logic/HMI configuration. If the PLC logic is correctly written you can shut down the HMI and the PLC will continue to execute it's logic as if nothing happened.

 

[Darwin333]

Can't speak to the accuracy of the article, but if the part mentioned above is true, it 100% verifies something already suspected: Microsoft cooperates with spy agencies (U.S., maybe Israel) to provide back doors such as these. It's simply not knowledge anyone but insiders can provide.

Most folk who find "zero day" exploits don't announce them to the public, a few do but most are looking for them for "other" reasons.

It isn't that much of a stretch that various .gov agencies have a team of hackers looking for exploits in the most popular OSes.

 

[SamurAchzar]

The only way this could happen is due to poorly written logic/HMI configuration. If the PLC logic is correctly written you can shut down the HMI and the PLC will continue to execute it's logic as if nothing happened.

What I read in the security analysis is that thing patched the PLC in a way undetected to the Siemens PC software. It didn't sound as if the PC was permanently connected to the PLC.

 

[Londo_Jowo]

From the Siemens site I posted earlier

How is it possible to say whether an automation system corresponds to the specific program pattern and what counter-measures recommended are?

• The malware carries its own blocks (for example, DB890, FC1865,1874) and tries to load them into the CPU and integrate them into the program sequence. If the above-mentioned blocks are already present, the malware does not infiltrate the user program.
• If the above-mentioned blocks were not present in the original program and are now detected, the virus has infected the system. In this case Siemens urgently recommends restoring the plant control system to its original state.

Knowing what I do about Siemens PLC's you have to know the register addresses (setpoint, process variable, and output) that are tied to a PID controller and link them together in the logic. Installing new blocks will not do this on their own.

For Stuxnet to work as described the person that wrote the worm/virus would have had to know all the exact particulars (process registers listed above and ranges of the analog inputs/outputs) to alter the control of the PLC.

 

[SamurAchzar]

Well, of course; it was written that this piece verified the presence of 30-something different PLC components before deciding that it has found the specific machine. From this I assume whoever wrote it knew exactly what kind of target he's infecting.

 

[Londo_Jowo]

Well, of course; it was written that this piece verified the presence of 30-something different PLC components before deciding that it has found the specific machine. From this I assume whoever wrote it knew exactly what kind of target he's infecting.

The person would have to know the exact machine/logic and the logic not be modified during commissioning. The later I've never witnessed in 16 years of working with PLC controls.

 

[shira]

Nothing advanced about it. There are far more complex coded malware out there.

Years to construct. doubt it unless the person who wrote it had to learn programming to. The code uses bits of Siemens own code, so I suspect one of their developers leaked the information.


Grow ? It runs off an internal script, no ai here. Adapt ? Using a stolen signed driver isn't adapting to security, it just installs like a driver would.




It is known without a doubt to be a flash drive because the version of stuxnet used had no method for installing any other way.



Considering it used code from the actual application and you use the same software to control the equipment, nothing remarkable about sending the equipment one value and telling the user it is another. It patched the software changing some values so that every time it ran it used the wrong formula. Once the program is patched no need to keep malware running.

The addresses used are easy to get, they are in the code and nothing became inoperative because the minute it was found Siemens told its customers.


All traces were not eliminated, copies of it are everywhere and using proxies is about as old as the internet.



Revoking the security cert for that driver or disabling access to rundll32.exe which the malware relies on to begin running never occurred ? How about requiring all applications to be signed which when patched the Siemens software signature was broken.

I guess precautions were , don't click on it till we have a chance to get some coffee.

Article is way over the top. I have malware that is far more invasive and clever than stuxnet. stuxnet got attention because of the target.

Well, gee, if far more invasive and clever worms are available, how come western governments aren't flooding Iran with them?

 

[CADsortaGUY]

The only way this could happen is due to poorly written logic/HMI configuration. If the PLC logic is correctly written you can shut down the HMI and the PLC will continue to execute it's logic as if nothing happened.

Not necessarily bad code as it sounds like it only took a connection to it once.

From the Siemens site I posted earlier

Knowing what I do about Siemens PLC's you have to know the register addresses (setpoint, process variable, and output) that are tied to a PID controller and link them together in the logic. Installing new blocks will not do this on their own.

For Stuxnet to work as described the person that wrote the worm/virus would have had to know all the exact particulars (process registers listed above and ranges of the analog inputs/outputs) to alter the control of the PLC.

I doubt the drives were wired with actual analog i/o. It would likely be a direct canbus/??? connection which is probably what the inserted blocks/code monitors/changes by knowing the particular registers of the drive.

 

[Londo_Jowo]

Not necessarily bad code as it sounds like it only took a connection to it once.

I don't know of many HMI's that can directly program a PLC. Now you can perform pass through programming via the programming software. Though if properly protected this will require a password.

I doubt the drives were wired with actual analog i/o. It would likely be a direct canbus/??? connection which is probably what the inserted blocks/code monitors/changes by knowing the particular registers of the drive.

These centrifuges more than likely have VFD (variable frequency drive) motors so they can set the speed required. Based on my field experience these are controlled by analog inputs and provide analog outputs for speed feedback to the PLC. Now they may use something similar to A-B's Flex I/O if the distance is an issue. Here again you will need to know the particulars (ie addressing) of the component.

 

[Darwin333]

The only way this could happen is due to poorly written logic/HMI configuration. If the PLC logic is correctly written you can shut down the HMI and the PLC will continue to execute it's logic as if nothing happened.

I don't know what the hell you guys are talking about so you would you mind answering a dumb question for me?

Wouldn't they have to think something is wrong with that specific piece of machinery to shut down the HMI (WTF is that btw?)? Sounds like the worm was designed to make them think everything was just fine until it wasn't.

 

[CADsortaGUY]

I don't know of many HMI's that can directly program a PLC. Now you can perform pass through programming via the programming software. Though if properly protected this will require a password.

Didn't say it could or should. However, it will have direct comms to the PLC and with the right bits of code access the processor. Just because the HMI doesn't normally do that doesn't mean one couldn't find/build some code to access the program and make changes.

These centrifuges more than likely have VFD (variable frequency drive) motors so they can set the speed required. Based on my field experience these are controlled by analog inputs and provide analog outputs for speed feedback to the PLC. Now they may use something similar to A-B's Flex I/O if the distance is an issue. Here again you will need to know the particulars (ie addressing) of the component.

Yes, that is the standard old way of doing things. Most drives now are intelligent and have comms built into them so it only takes 1 comm cable connection to control the drive. It also allows access to all the parameters within the drive. I highly doubt they used actual analog inputs and outputs as the comm cards on drives usually are cost competitive when you factor in the costs of both analog input cards and output cards. Most every drive we put in whether it's CT, AB, Tele, etc is controlled via comms now unless it's just a very simple system that doesn't need feedback or constant speed control.