New Windows Virus Targeted at Industrial Controls

To do exactly what Stuxnet did took quite a bit of effort. However, to do something equally effective against most typical targets would not be any more difficult than what many virus authors already do today. Yes it was a targeted attack, but that isn't new. Google was subjected to a targeted attack not long ago that was successful at getting confidential business information. The attackers in that case new that Google used MS Windows XP with IE 6 in their Chinese ad sales office, and they simply took one of the many commercially (black market) available off the shelf MS Windows and IE6 viruses that are out there and added their own custom payload to scoop up Google's sales data. This type of targeted attack happens all the time. There is nothing unusual about that and there is nothing to stop any interested party from repeating this with an industrial target.

There is an entire industry dedicated to creating and selling MS Windows viruses to people who want them. If you want a zero-day MS Windows exploit (one that has never been used before), you can buy those too, they just cost more money (I think the going rate is around $10,000). Some virus authors offer support contracts to their customers. Getting an MS Window virus is not a problem.

As for creating the virus payload (the part that would affect the control system), that doesn't look to be that difficult either. You could use the vendor's own programming software to create your PLC changes, record a download to the PLC, and then figure out how to "re-play" that back again later. If you target an MS Windows SCADA or HMI system instead of a PLC, the job would be even easier as the virus could do the job directly via the OPC server. Since a lot of the more lucrative potential targets have SCADA systems, that's a good target to look for.

There's really only two things which have prevented this problem from occurring so far. One is that the automation control industry is so technologically backwards that it has been difficult to apply current common virus techniques to it. For example, modern viruses normally depend on a network to spread, and networks have only recently become common on the plant floor. Indeed, some of the techniques used by Stuxnet should be quite familiar to anyone who recalls the days before PC networks became common and viruses were usually spread by infected floppy disks.

The other thing which had prevented this from happening is that the people who make money from viruses simply weren't aware of the potential market. Now that Stuxnet has happened, their thoughts will be turning to the automation market and what can be done there. Now someone just has to use their imagination to figure out how to make money by knowing that a generating plant, pipeline, or mine will be knocked out during a certain time window. I'm sure that a commodities speculator could handle that end of things.

If you want a good example of a scenario, consider the following. There are many, many gas turbine generating plants in the world that all have very similar control systems. Find out who the engineering or maintenance staff are at one or more of these plants, and send them an e-mail with a virus labeled "click here for deals on re-built Moog servo valves". Now, if any of those people have their PC come in contact with the GTG control system (perhaps they're already networked directly to the HMI so they can keep track of it?) you have your "in". If your virus can cause difficult to troubleshoot trips, you can create a shortage of electric power in that area. If that plant supplies a de-regulated electricity market, a speculator who knew this was going to happen could have bet on the price of electric power going up. Somebody could make a *lot* of money this way. The same concept can be applied to oil or gas pipelines, large refineries, certain metals mines, etc.

What I find surprising is that this isn't happening all the time right now. Focusing on what was special about Stuxnet is a red herring. What people should be focusing on is how easily much less sophisticated efforts could cause disruption done for profit.
 
C
The thing that scares me is that even though stuxnet shows a fairly sophisticated and focused effort, it's really way overkill if you just want to take down a competitor or cause mayhem. Many times a day we see someone with a comms issue and the universal answer is "Just use OPC", or some other Windows based method to make things talk. So you don't have to even know anything about the PLCs or process, they've just made their system vulnerable to the simplest of techniques. Just look at the registry and down the box. You can easily get a day or two by simply deleting the registry or if you are feeling nasty, you can edit it and see how many people can figure that out. Or scramble the BIOS. Or corrupt packets, which would be really ugly to figure out, or.......... The system is only as strong as the weakest link and many are dependent on a link known to be weak. With a crafty OPC killer, you could create a generic plant bomb. If it didn't do anything else, it could get wide distribution before it was detected. None of this would require anything new or particularly clever. And you need no knowledge of PLCs or their programming software.

Regards
cww
 
K
There is a sense that this is the beginning of a technological war that attacks physical assets via computer software, which is rather a first. I think that this is a legitimate threat and it also shows the power of industrial controls to the world, who has hitherto taken it all for granted. It is rather astonishing to the general public that physical things (processes, actions, etc.) can be, not only affected, but rendered useless by the same technology that enables them to use Friend Face (insert social site here)
 
In reply to Kevin Cooper: Whether Stuxnet actually had any effect on its intended target is unproven at this time. However, people shouldn't get too fixated on the details of Stuxnet in particular. Much less sophisticated viruses could have much greater effects on industrial systems with much less effort than what went into Stuxnet.

It is much more reasonable to expect to see virus attacks which are intended to make money for someone. Chronic simple virus attacks are more likely than elaborate ones and are much more likely to achieve results as long as the originator is willing to be flexible in his choice of targets. This is simply an extension of virus attacks from sales and financial systems to other areas of a company, so it shouldn't come as a surprise to anyone.
 
In reply to Nathan Boeger: Anyone who remembers the early days of MS-DOS in business will remember the numerous viruses that were transmitted via floppy disks. Networks were rare and expensive so everyone passed information back and forth on floppy disks. Anti-virus software would scan floppy disks whenever you inserted them in a drive, but that didn't prevent viruses from spreading rapidly everywhere. So, anyone who remembers those days shouldn't be too surprised at seeing Stuxnet spreading without networks. It's a throwback to the early days of viruses rather than something new. Viruses only started using networks when networks became common.

On an unrelated note, those were also the days when Apple used MacOS in the MacIntosh (this was an OS that they had designed themselves). Mac viruses mostly disappeared since Apple switched to using unix (OS/X), but in MacOS days they got lots of them. I'm not entirely sure what lesson to draw from that, but it's interesting to think about.

While isolating the network is not by itself protection against a virus, if the I/O network is separated from the supervisory network it does prevent a direct attack on the I/O by a straightforward MS Windows virus located on a SCADA or HMI PC. It also prevents a DDOS (overloading the network with messages) of the I/O.

A few years ago a nuclear power plant in the USA had it's control network knocked out by the SQL Slammer worm which attacked the MS SQL Server database. The actual *controllers* weren't infected by the virus. They just couldn't communicate with anything because the single MS Windows PC on the network hogged all the bandwidth. It took hours to get things under control, and the plant was very fortunate that the reactor had already been shut down for other reasons.
 
Please let me interrupt this fascinating debate by offering a sincere thank you to all who have contributed.

As someone about to spend several USD millions on new automation next month, how we deal with the threat of malware invasion is very high on my agenda.

Solving this whole malware issue in a secure way, is surely our industry's top challenge for 2011.
 
K
Qarsaan, it will be interesting to see what you do to mitigate things like this. Please post if you have suggestions throughout your project.
 
I would also be interested in hearing about your project as it progresses. It would at least be interesting to hear what problems you had to take into consideration and the areas where you think the industry in general needs to improve the most.
 
C

Chris Jennings

When you look at the information provided in this thread is almost enough to put together a white paper on best practice. It is something that the industry needs, and we aren't getting much guidance from the automation vendors (perhaps with the exception of Emerson).

Is it something we should continue to collaborate on this mail list or perhaps move to a Wiki/Google Wave or similar device?

Chris Jennings
 
C
Actually, that was a bit short, I apologize. I just find it fascinating the extreme lengths the world + dog will go through to avoid a sound and relatively simple solution to the problem. Yes there is the legacy issue, but it's like Deming's definition of insanity. People keep doing things the same way and expect the results to be different.

It's kinda like the lower Mississippi problem. A hypothetical discussion :^)

Well, we got wiped out again, time to start rebuilding. We'll get the earthmoving equipment out and start making levees.

Hey wait a minute, the earth levees are why we got wiped out.

What are you getting at? I don't understand. Levees are made of dirt.

Yes, but you keep making them and they keep failing.

What do you mean? Earth levees are easy to understand, they look good, they're easy to build and everybody believes they will hold next time, we're _using new dirt_. And we can tear them all out again and put gravel under them, and, and, we'll grow grass on top! It'll cost millions, but we've got dirt.

I've got an alternative, lots of soggy people have joined together and they'll contribute all the concrete and tools you'll need to make stronger levees. You can start out new and put concrete in the places where the dirt doesn't hold.

Get the h*ll outa here with that crazy talk, you don't know nothin about building levees. And we hire half the town pushing wheelbarrows full of dirt. They don't know nothing about pushing wheelbarrows full of concrete. And there's all the contractors and the excavators, and what are we going to do with all that dirt?

I think they could learn to work with concrete, and you could put the dirt behind it.

You got a hearing problem, old son? There ain't anything wrong with dirt levees, we've been building and rebuilding them for years. And the only time we _ever_ have a problem with them is when there's a flood. And even then it's not the levees that are at fault, it's the d*mn water, if we didn't have high water, we'd never have problem with the levees. Jimbob, Buadreux, get the dogs and show this guy the highway....... Hello, Bud?, we're gonna need a whole bunch of that dirt 7.0, yeah, the waterproof stuff... Oh, it's 7.1 now and it's self patching?

Sigh.......
cww
 
In reply to Chris Jennings: If you want to discuss security practices, the best place to do that is right here on Control.com. If you go off with a small group of people you lose visibility. Pick a topic with some focus and start a new thread. Give us your opinion, and if anyone has a different one they can join in. Once that topic has been beaten to death, start another one on a new thread.

There isn't going to be a single answer to all applications. So, pick something like "security for PC based HMIs", or whatever takes your fancy. We can flog that question to death and then you can come up with a new one. When there seems to be some general conclusion, perhaps you could summarize it and put it in the Control Wiki.
http://www.controlwiki.com/index.php/Main_Page
 
In reply to curt wuollet: I don't think your answer was a bit short. I think however that most people would want to ask you "how"? When someone has a problem, the best answer to give them is "here is the solution to *your* problem". If there is an open source answer to give them, then that's the time to bring it up.

I don't think the answer is to say "persuade the existing big vendors to change". If they want to change, they'll change; if they don't, then they won't. All the successful open source projects that I can think of started as just someone or some group of people who just went ahead and did it, and the big established companies either came in *after* it was already a success or they went out of business. If you take the attitude that nothing can change until the big vendors decide that change is in their interest, then nothing will ever happen. You just have to make things happen on your own.

There's a project that needs doing, and I happen think that you're just the guy to do it. There's a package on Sourceforge called Modbus Firewall, or something like that and it's Linux netfilter extension for Modbus/TCP. Unfortunately, the guy who wrote it is a networking expert from Cisco, so using it as is probably beyond the average automation programmer (I suppose the same could be said about most advanced networking systems).

What it needs is for some sufficiently motivated individual who knows something about Linux and something about C to work with one of the existing popular Linux firewall distros (IPCop, Untangle, ClearOS, etc.) and get it integrated as a standard feature. Once that is done, then when someone asks about security or another Stuxnet happens you can point to "X" as the completely off the shelf, packaged, and ready to use solution which can be used by anyone who can stick a CD into a disk drive and click on a menu.

There you go. It's Linux in automation, people need it, and all it's waiting for is for someone (you?) to go ahead and do it. And it's all about security, so it's right on topic here.
 
As far as something like stuxnet is concerned, using linux would not have helped. There are zero-day exploits in linux as well, and with the resources behind stuxnet I doubt any platform is secure enough to be safe.

On the other hand, generic malware is a problem that could be solved by moving away from windows. However, in my industry (power generation DCS/HMI) we are not seeing infections in the vast majority of our customers, as they are following good procedures and best practices. We have to balance the pros of a non-Windows platform with the cons (development costs, lack of vendor support, customer familiarity, etc).

I expect to see lots of new cybersecurity product offerings in the near future, starting with catching up control networks to at least the level of corporate networks (managed switches rejecting unauthorized devices, firewalls, more restrictive policies on HMI boxes, disabling unneeded services on embedded devices, etc).

At the very minimum, a competent expert in cybersecurity should review any control network design.
 
In reply to Demigrog: As far as Stuxnet itself goes, it would be a mistake to get fixated on that in particular. If some of the popular theories are correct, the originator of Stuxnet also had the option of dropping a bomb on the building. You're not going to fix that with a firewall.

However, what was interesting to me about Stuxnet was not the virus itself, but what was done with it - creating the appearance of difficult to find transient bugs in the actual control system. The virus was just a way of delivering the payload. You could do the same thing with any of the many off the shelf MS Windows viruses, and there is an active black market selling those to anyone who wants one. A virus like would be cheap and easy to create by an individual, and there are plenty of commercial reasons for disrupting power plants, pipelines, water systems, and other infrastructure, as well as manufacturing plants.

What I think part of the answer is for SCADA and HMI vendors to offer a managed platform service where they take responsibility for the entire system, including OS and database as well as the SCADA or HMI software itself. To make that practical, then yes I think that they would need to use and OS like Linux or BSD, and a database like Postgres or something similar. That's due to the need for managing the business relationships however, not just whatever technical arguments can be made. A look at the security appliance vendors is instructive; not a single one that I am aware of uses MS Windows.

As for the cons you state, the only one that is really relevant in this situation is that the vendor's existing product lines are closely tied to MS Windows. There are some smaller vendors who don't have that problem, and it doesn't stop anyone from coming out with a new product designed around this idea.
 
C

Chris Jennings

In reply to M Griffin,

I didn't know about the Control.com wiki. However spammers obviously do, is anyone using it aside from spammers at the moment? The recent changes list reads like a who's who of spam.

I would be happy to help moderate the wiki if that helps.

Chris
 
C
Hi Michael

Yes, I agree that would be a useful thing to do. Unfortunately, I haven't been
coding much or advancing my automation projects or anything non-essential lately. I've been living near third world conditions and the Minnesota climate has been keeping me sufficiently busy wrangling firewood to make the necessary concentration unlikely. And, I agree the "how?" is at this point the most crucial question. But, I willingly admit that I am no longer sufficiently engaged to write world class secure networking code. It's well beyond the Bonehead C tm. class of endeavor. But, I appreciate your vote of confidence:^)

It is beyond our power to convince all the majors to switch, but Stuxnet and the need to continue in business after the first real disasters Windows Virii cause will probably take care of that. Our military did an abrupt about face on using Windows in theater after it was demonstrated how idiotic that was, and I credit the automation majors with more acumen than the Army. I hope that trust is not misplaced. In the real world, the extreme CYA desire on the subject of security is not going to favor any startup or unknown.

Real world factors considered, it could happen this way: Security becomes a for real, contractual _requirement_ on important big dollar projects, infrastructure comes to mind. One vendor makes a serious attempt at becoming the "go to" for those contracts, which precludes the use of Windows, and provides the financial incentive to create an end to end product that automation people can grok and can risk using, with the (dubious) comfort of big name backing for the CYA factor. It works much like the familiar. The others move at the usual glacial pace, providing a window to garner market share. Game Over.

The reason that I see this as a possibility is not because I am a Linux advocate or glimpse any vision of world dominance, but because the only remaining way to acquire market share may be to actually do something different, and solve this problem. And no perfectly good disaster should go unleveraged. Being the solution would be a far more powerful position than being part of the problem. I think some entity is close to the tipping point already, and they could change the world in their favor. Have to close, it's getting cold in here again.

Regards
cww
 
C
A secure, purpose built, automation version of Linux might not be impenetrable, but it could come close to the best possible case and it would be unlikely to generate any interest from the vast majority of virus authors. And since nearly all of the known exploits involve features totally unnecessary for an _automation_ distribution, it could be far, far, more secure than OTS Windows. Or even what is practically achievable with Windows. And it's doable today, with an investment truly trivial compared to _actually_ securing the status quo. But, I do expect unbelievable extremes and gyrations rather than the simpler solution.

Regards
cww
 
Top