New Windows Virus Targeted at Industrial Controls

Siemens is saying that they know of 14 control systems that are affected. Other sources are saying 45,000 computers are affected. Although this virus seems to be looking for a very specific target, it is quite capable when it comes to actually getting on computers.

It is possible to imagine someone creating a variant of this that went after a popular brand of gas turbine control. Someone could get the viruses in position and then sell short electricity prices on the spot market for a specific block of time. They could then trip several power plants and watch the money roll in as the price of electricity rises. If they were careful enough not to trip too many plants at once, the plant operators would probably just write it off as an unexplained trip and not investigate it further.

There are probably other ways to manipulate spot prices for oil, natural gas, and other commodities. There is a *lot* of money to be made doing things like that then there is operating spam bot-nets. I will be surprised if someone doesn't take advantage of it.

Rahul P Sharma

Does the virus remain confined to the PC running windows or it can also install itself in the PLC Program and affect the sequence logics....??
Now all we need is a very smart highly trained individual to carry out the scheme below. Oops, you would also have to be hungry and immoral.

But if you are the first you are not hungry, and probably much too busy making money to consider immoral methods.

I know I am, hope you are too.

The virus installs itself on the PC using security holes in MS Windows to get in. I believe it actually exploits 4 different known MS Windows security holes so it has alternate means of spreading if some methods are blocked.

Once the virus is present on the PC, it looks for the PLC and then downloads new program logic into it (in OB35). We don't know what that new logic does to the production process, but this is the reason why people are saying that it is targeted at a specific plant (because it is modifying some specific logic).

If you follow this link you will see what the actual PLC program changes are:

It's quite easy to imagine new viruses following the same pattern in future. If all someone wanted to do was to fault the processor, there are many ways to do that without needing to know anything about the equipment being controlled. Debugging a situation like that would be extremely difficult for a plant operator. They would reload the PLC program, replace hardware, replace IO, and do practically everything else before suspecting the PC was injecting code into the PLC.
In reply to Honders: There are plenty of people around who do this sort of thing already; they just haven't been doing it to PLCs. Up until now people were saying "it can't be done". Well, it's <i>been</i> done, so that excuse is now gone. There's a thriving market in MS Windows viruses right now. Just bring a few of those guys together with people who know something about PLCs and creating this would be easy.

Modern viruses are written to make money. They're used for fraud, extortion, spam, and no doubt many other things as well. As soon as someone can figure how to make money by temporarily knocking out a power plant, pipeline, or anything else, it will be as common as spam e-mail (it is estimated that more than 85% of all e-mail is spam, most of which is sent by computers that have been taken over by viruses).
There's more news on the MS Windows virus which is attacking Siemens control systems. The BBC is quoting Iranian news sources as saying that they have detected the virus at 30,000 IP addresses. Since more than one computer can be at one IP address (due to network address translation), there may be many more affected computers than this.

The virus is also affecting India, Pakistan, and Indonesia, and has also been found at a number of other places around the world.

AFP is quoting American sources as saying the virus has been found affecting water treatment plants and chemical plants which also use similar Siemens controls.

The virus is apparently still quite active. Microsoft has patched 2 of the 4 vulnerabilities which it can use, but there is no word yet on when the remaining vulnerabilities will be fixed.

Iranian sources have said they have seen 5 different versions of the virus so far.
I'm trying to get a handle on the software technology that would be used to communicate with a PLC behind a firewall. I know zilch about Siemens PLCs, so I'll muse about what would be needed to access a Modbus/TCP speaking PLC (Schnieder, Control Microsystems, Sixnet, e.g.)

I know three ways to do this:

1) allow access to a Modbus/TCP PLC intentionally by opening a port on the router and directing Modbus/TCP traffic (default port 502) to that one PLC or one Modbus gateway.

2) use a VPN.

3) install Hamachi (or the like) on one of the computers inside the plant network.

If anyone has a 4,5,6, etc., let me know. Since I don't, I'll bet the Siemens attacks are based on a Hamachi-like technology, where all TCP connections are outbound. Firewalls filter URLs but don't generally stop outbound TCP connections. There is usually nothing that prevents a pair processes, over the Internet, from making a network based on outbound TCP connections only.

I'm not complaining about Hamachi. I like it. It is an open source program, so the cat's out the bag. Logmein is managing Hamachi, primarily for Windows platforms. Ready-to-run Linux versions of Hamachi are also available.

Someone builds a fence, someone else figures out how to climb over it.

David Ferguson

How about a giant wooden horse as a gift, Engineer takes laptop home, it gets infected with auto-running code. Goes back to work connects behind the firewall to the PLC, virus loads and code finds PLC and modifies an OB code (OB35 ?) program and machine crashes. Bets on that market (as has been said) and makes money from stock changes or his companies code............

In other words, who says it needs to be connected to the internet ? We are very protective of the whole firewall internet ting, but in reality I have played that cat and mouse with Interns who know more than we can keep up with each summer. As has been written over and over, there are many ways to attack Troy.

Dave Ferguson
Control Systems Engineer
The problem with giving generic advice on this sort of question is that there isn't a simple answer to give. Network security varies from place to place, and what works in one application won't work in another. The other thing about it is that security that isn't monitored and kept up to date isn't much use.

You said the Modbus/TCP network is "behind a firewall". Is that a firewall for the entire site (including the business offices) and you want to connect to the PLC from any place on the Internet? Or is that an internal firewall, and you just want to isolate the control network from the business operations? Or are you trying to do both?

For accessing a site from somewhere else, you really need to talk to and work with the people responsible for the IT network. They are (hopefully) the professionals who know how things are already set up and can advise you on how to work with their system. It won't do you any good to find a solution and then have them make a change which negates it a week later.

For an internal firewall (separating the plant from the business network), someone has already mentioned Tofino. I haven't bought their product, but the overall design sounds good. You would need to talk to them however to see if it does what you need for your application.

From what I understand about it, Tofino runs Linux and uses the packet filtering which is built into the OS (iptables). Most professional grade security appliances (firewall boxes) work the same way, so this part of it sounds pretty standard. They then add some software to make configuration easier (you can configure iptables with just a text editor, but it's not easy). They also add some industrial network specific packet filtering to make sure that for example the Modbus/TCP messages are really valid Modbus/TCP messages and not garbage that is meant to trigger bugs in your PLC's firmware.

If you want a do-it-yourself solution, you can set up more or less the same thing using Modbus/TCP netfilter extensions (you can download these from Sourceforge). Be prepared to do a fair bit of work if you plan to set all this up yourself however.

As for the Siemens attacks, the virus gets onto the network via USB sticks or by being transported via someone's laptop. At some point you need to program or configure your equipment, so there really isn't a good way to avoid this risk. Once the virus has access to the network it spreads through the network itself. It is using multiple holes in MS Windows, not all of which are patched yet. Once it is on the same network as the PLC it can re-program the PLC by using the normal PLC programming commands.

When this virus first started spreading Siemens was taking a lot of flack for their use of hard coded passwords to access the database they were using MS SQL Server. However that flack was coming from the traditional MS Windows security industry, which tends to think in terms of databases being the target. Instead, the main target of the virus was the PLC. The virus can do that by simply using normal programming commands. I don't think there is much that Siemens can really do to improve security so long as they are using an OS that is so notorious for having security holes.
So what? Did you realy mean all that virus/pc-stuff will never affect the plc side? It was IMHO just a question of time. We all wanted the overall network stuff, the everything connected to everyone stuff. Go and face it that this (...) will be the future. Wake up! Learn both sides (pc & plc) to be ahead. Kick the pc-network-admin and dont take every gadget on the plc-side for good. Less could be more in the future :)
It seems to me that a lot of this could have been avoided if people left the cpu keyswitch in a position where program changes are disabled.

To me that is an inexcusable, and has absolutely nothing to do with any "gaping" holes in MS products.

It's like blaming the burglar because you are too lazy to lock your front door. Yea, he is still responsible for his actions, but so are you.

I would not be getting too much pleasure out of this for the MS haters. If the "free' OS's ever start to replace the ones you have to pay for, it is almost a certainty that the hackers will start to attack them, and they will have every bit as much success with them. It's just about volume. There is just no reason for the hackers to go after the other OS's.

David Ferguson

While I agree with you about the keyswitch, that will not solve anything, for as soon as you move the keyswitch to program.............the virus which has been laying in wait, incubating, sees the switch change when you actually need to make a ligitimate change and infection happens.

Avoiding the illness is the issue, not getting infected when everyone around you is sick is another.

Also the OS in this case is just the delivery system, the virus is actually changing the program of the PLC, this is a little different for it is a targeted virus, it is not attacking a vulnerability of the OS itself (directly) but using it as a trojan horse.

And oh by the way, not all plc's have a "keyswitch".

Dave Ferguson
Control Systems Engineer

David Ferguson

I also am not going to talk about this on here anymore, for the very writers of this virus are probably monitoring our answers to make the next one better.....

Dave Ferguson
Hi Bob

I don't think anyone is getting any pleasure out of this. I'm with you on the keyswitch thing, but people do want to be able to edit remotely and they probably will leave the PLC set up for that, regardless of whether they should. As I said before, I, the US Army, the NSA, and many others would be interested if there were the slightest shred of evidence that Linux is as permeable as Windows. For the time being, I think I'll go with their risk assessment. And a better analogy might be blaming the burglar because the safe wasn't locked and the front door lock has been broken for years.

In reply to bob peterson: If you look at the rest of the paragraph in context you will see that the point I was trying to make was the story as originally reported in the press was focused on the wrong aspect. In the original news reports Siemens was taking a lot of flack over using hard coded database passwords. While that may be a problem, the database wasn't in fact the primary target for the virus. It was only much later that the press starting reporting the PLC re-programming angle.

Most industrial control systems are based on the premise that all the elements that make up the control can "trust" each other. That is, they assume that the PLCs, servo drives, I/O modules, SCADA and HMI systems, etc. won't deliberately do anything malicious. That assumption applies to all the normal vendors, not just Siemens. I can't in fact think of a vendor which does *not* assume this. So, an important point to make here is that while Siemens may have been the target in this case, users of systems from every other vendor face exactly the same problem. This is why I haven't emphasised the "Siemens" aspect of this story. It's an industry wide problem.

The problem is that in such a situation, once a PC has been taken over by a virus, the virus author can do virtually anything that a "legitimate" user can do. There are *many* things other than reprogramming the PLC that such a virus could do to cause a serious problem.

Give those circumstance, then as I said there is really not much that Siemens (or any other vendor) can do to prevent this so long as they are relying on a third party OS (MS Windows) to provide a degree of security which historically it has never been able to. The point here is not to bash Microsoft (however much they may deserve it in this case). The point is that given that industrial control systems are based on trust, the security of the system as a whole depends on MS Windows PCs not getting viruses.

Up until now people have been ignoring this problem by saying that virus writers would never do this because PLCs are just too obscure for them to notice. Well, now they *have* done it, so that excuse no longer holds. It's something that we all have to think about.
There's more developments in this story, and this looks like the worst news yet. According to Symantec (an anti-virus vendor) the virus will directly infect Step7 project files (backups of the PLC program).

What happens is the virus scans your disks for copies of Step7 projects (PLC programs). When it finds them it puts a copy of the virus inside. When you attempt to open the project file again later, your computer gets re-infected with the virus. There is no fix for this at this time.

This means you can't trust any Step7 backups you may have. You can't trust any Step7 PLC programs that you get from anyone else (e.g. equipment builders, third party integrators, etc.). Opening any of them can spread the virus.

I think this explains why the virus has spread so widely and so quickly. I don't think we've seen the last of this.
Hello All,

If you want to see what the future holds for control system security take a look at...

The Department of Defense has already done extensive security studies on everything from basic workstations, networking, servers and put out Security Technical Implementation Guides (STIGs). These guides show you where to plug potential security threats and are extensive. Following is the STIG for the Windows Operating System...

For example, in the Network STIG, it is a requirement to disable unused ports on all Ethernet switches, hubs, routers. So these STIGs are more than just software based but also implement physical security policies.

Having done a control system project with a government agency these STIGs are required to be implemented and took quite a bit of time to review and see how they would impact the functionally of the control system.

Based on last weeks news about a control system being infected, this is going to force us control engineers to start looking hard at security when developing these systems. The security standards that will be mandated are most likely coming from the STIGs put out by the DoD.
In reply to ChiefGeek63: Those are probably useful guidelines for anyone who has the US military as a customer, and many companies will have similar policies on how they want their computers set up. However, those are simply basic security guidelines intended to make sure that normal users don't have more access authorisation than they should. The MS Windows permissions system is very convoluted and inconsistent, so this can be difficult to get right if you have a large and complex network.

However useful those documents might be to someone setting up a new computer (and I'm not saying they're not useful for some people), that is orthogonal to the virus problem. A virus simply goes around all the security and in through any one of multiple holes in the security fence. In other words, you can set whatever security settings you want, but that has no effect on the virus.

The latest news where a virus can use a Step7 PLC program to spread itself is particularly serious. A Step7 project apparently isn't just a simple data file. What makes is so serious is that PLC programs are very valuable (they run your plant), and you need to keep them for the life of the equipment. They also by their nature tend to be something that gets passed between different parties from different companies. What's more, integrators deal with a *lot* of customers, so the risk of virus infection for them is very high. Once a virus gets established it will keep coming back from old PLC programs from various sources.

What is more, even if you can run a virus "cleaner" program on the PLC program, how do you check if the PLC program was corrupted (unintentionally) by either the virus or the virus cleaner program? The only way to be sure would be to actually check each and every program against what is known to work in the machine (and hope there are no logic time bombs already present). That sounds like a lot of work for a large plant.

There are a lot of difficult questions being raised by this situation, and I will be interested to see if anyone comes up with any real answers for them.
That is quite interesting reading. The Linux section implies that it's pretty secure out of the box with most actions: "Ensure that xxx is xxx". I think that it is extremely important that the defaults be set for maximum security as real world installation tends towards, run the CD and go. I know they tried this with Vista and people hated it, but shipping wide open, then blaming the user is unrealistic and inexcusable. If you ship secure and people have to open all the security holes to get their favorite features (like auto executing files on a USB drive), then you can blame the user. It would also require application vendors to state which relaxations are needed to run their blob and provide some incentive to minimize these. I don't know if Microsoft could be persuaded to do this after Vista, but it would be no problem for an "Automationix" distribution of Linux to be very secure (full SELinux) out of the box. The vast majority of security breaches could be avoided with just this simple and logical measure. Even this breach seems to exploit old and well known weaknesses that could be closed by default.