New Windows Virus Targeted at Industrial Controls

M

Thread Starter

M Griffin

There has been a news announcement that there is an MS Windows virus which is specifically designed to take over industrial controls, and this virus has been found in at least 14 plants in several parts of the world. This is <i>not</i> the same virus which we discussed earlier this year, but rather another one altogether. The full story is here:

http://www.itworld.com/security/120550/siemens-stuxnet-worm-hit-industrial-systems

The following is a quote from the story:

<i>The software operates in two stages following infection, according to Symantec Security Response Supervisor Liam O'Murchu. First it uploads configuration information about the Siemens system to a command-and-control server. Then the attackers are able to pick a target and actually reprogram the way it works. "They decide how they want the PLCs to work for them, and then they send code to the infected machines that will change how the PLCs work," O'Murchu said.
</i>

End of quote.

There is now a security patch from Microsoft to deal with this. The virus was first detected over a year ago. However, it is normal for information of this type to be held back from the public until Microsoft writes a fix for Windows and is ready to release it. In other words, anyone using this software could have had this virus on their systems for over a year.

The article also states that due to the nature of this virus, simply running a virus removal program will not remove all parts of it. You need to wipe everything and "restore from a secure backup". The article doesn't give details, but that usually means wipe the hard drive and re-install everything (including Windows) from CD. Get some good advice from a qualified IT person before just running a virus scanner and assuming that you're covered.

This particular virus has been targeted at Siemens WinCC and PCS-7, but users of other programs should not feel complacent. There could easily be other variants of the same virus targeted at other packages. The virus is using Windows security holes, so any software using Windows is potentially vulnerable to similar attacks.
 
You have to wonder if it is really worth it to hook your machines up to the network. I think if you can it is worth it to have your network physically on its own wiring/switches and IP subnet that is not connected to office computers and/or the internet router. I don't know if you could then have a "secure" router/firewall linking your industrial network to your database and file servers, etc. In the end someone has to set this up and maintain it and if your not an almost fulltime IT guy or a security expert what do you do? The problem becomes more tricky when you consider anyone with an infected laptop can plug in behind the firewall (maybe to do some innocent programming) and infect everything anyway.

I guess one question we must ask ourselves is this: "Is it really worth it to connect your office computers [or other non secure servers/PCs] with your critical manufacturing machines?" Does a power plant or a chemical plant really need to expose itself to the internet or office PCs?

So much for Antivirus scanners.

~Ken
 
C

curt wuollet

It's not a good idea, never has been, probably never will be, as long as Windows is the target. Someone did the research and came up with the number that Windows was the target for 99.4% of the malware written to date. It would seem irrational to expose it to the wider world unnecessarily. I think that makes it irrational to consider for Line of Business automation work, period. But, if you are going to use it anyway, you should at least isolate it, especially since automation systems tend not to be updated or brought up and down for virus scans etc. It's not hard to see why security is an iceberg up ahead. The least maintained systems with the most attacked software doesn't seem like a recipe for sound automation. But, I must not be thinking clearly :^) After all, _everybody_ does it.

Regards
cww
 
I think there's two lessons to learn from this. One is that in the past a lot of people knew that this was possible, but they stuck their heads in the sand and said it won't happen because industrial control is just too obscure. Now, there have been two separate incidents where specific industrial control systems have been targeted. We can't ignore the issue anymore.

The other lesson is that we can't expect automation engineers or plant operators to be security experts. I can guaranty that the majority of the people who are or become affected by this virus won't know how to deal with it properly.

The security problem in this instance is a complex one with multiple aspects to it, but neither vendor (Microsoft or Siemens) is taking responsibility for fixing the problem as a whole. What we have in this announcement is that Microsoft is plugging one hole (out of several), but washing their hands of the matter so far as the other aspects are concerned. If you apply their patch, you won't get the virus the same way again if you don't already have it, but it does nothing for systems that are already affected. None of the reports say anything about what Siemens is doing (or if they are doing anything at all).

I believe the automation vendors need to take responsibility for handling this type of problem by offering a complete managed package from top to bottom just like the enterprise Linux distros do. By that I don't mean the solution is to stick a Linux OS under their products and call it done. I mean they need to take the same operating approach where the vendor takes responsibility for *all software* in the system, including the OS (whatever they happen to use), database, and SCADA. In this case as long as the customer pays their maintenance contract, a single source (the vendor) takes care of all these issues from top to bottom and the user just has to worry about how to apply the software to their business operations.

I don't think that's a one size fits all solution. For smaller operations it probably doesn't make sense. For very large complex systems however, I think it's the only feasible solution.
 
The worst that can happen to Linux is to succeed.
As soon as the number of Linux installations will be considerable, the malware will get there.
 
In reply to MiguelS: Linux is already widely used in critical applications, including banking, stock markets, e-commerce, etc. It is in fact much more widely used than Windows in applications where real money is at stake. Large automation systems could be viewed as similar to those.

So, how does your argument that security is simply inversely related to market share fit with that? It certainly doesn't fit with what Microsoft themselves have said about such things. They claim it most definitely is possible to make a more secure OS than whatever they sold you the last time, and they always claim that each new version is more secure than the last one. As to where their OS product line sits with respect to others on security, I will leave that argument to others.

As I said before however, I don't think the solution is to just stick a different OS underneath the SCADA and call the job "done". I think there needs to be a different business model where the SCADA vendor takes responsibility for the full software stack from top to bottom rather than the endless finger pointing which we have now.

If a SCADA vendor decides their solution to this includes using Linux or BSD, then that's fine. It's not however the goal. The goal is to have a professionally managed secure platform. The present situation where the vendors wash their hands of all responsibility once they've cashed your cheque simply isn't working.
 
C

Chris Jennings

> As I said before however, I don't think the solution is to just stick a different OS underneath the SCADA and call the job "done". I think there needs to be a different business model where the SCADA vendor takes responsibility for the full software stack from top to bottom rather than the endless finger pointing which we have now. <

> If a SCADA vendor decides their solution to this includes using Linux or BSD, then that's fine. It's not however the goal. The goal is to have a professionally managed secure platform. The present situation where the vendors wash their hands of all responsibility once they've cashed your cheque simply isn't working. <

I totally agree!

Remember the good old days when control system vendors used to make their entire product, from I/O and controllers to the HMI. They had their own operating systems and software that only worked with their hardware. Customers complained that it was closed off and didn't allow for competition, customers wanted "Open Control Systems". Well now we have it, but we still aren't happy.

Is it another example of globalisation gone wrong, one product that does a lot of different things but very badly? Or are we ourselves to blame by asking vendors to make their products standardised, open, compatible we are now bearing the fruit of our requests.

As technology gets more and more complex it gets harder and harder for one company to make an entire product themselves without getting something "off the shelf". I can't imagine that we can return back to the good old days, that perhaps weren't so good. But we need to put more effort in specifying our needs as customers and what we view as important. This will drive the market to make the changes necessary to meet that need.

Be it Windows, *nix, Linux, iOS or whatever they are each complex, and because of that are just as likely as each other to have errors, faults and mistakes that could cause security concerns. Market share does play a major part in the amount of malware available for a software platform. Just look at the recent issues with "Jailbreaking" iPhones and iPods, initially Apple was insisting that Viruses and security concerns don't exist for their products. Suddenly they are the market leader in something and hacks, cracks and vulnerabilities are uncovered regularly. Linux has the advantage of being open source so security through obscurity is no longer an option, if that option wasn't available to the closed source companies I imagine that we would have a much better outcome. However this would also require end users to be more capable. The dumbing down of computer software is a major concern, by making software accessible and very flexible they open to many more vulnerabilities than locked down, specific applications.

Sorry for the rant, but I lament at what has become of IT.

Chris Jennings
 
C

curt wuollet

I'd be interested in any justification for that statement. It comes straight from Redmond, but even they don't _believe_ it. Check out what the NSA, people who know, did for Linux as a platform for various govt. agencies when security is an issue.

Regards
cww
 
In reply to Chris Jennings: The newer SCADA and HMI systems are still (mainly) proprietary and are (mainly) using proprietary operating systems and databases. They're just running on cheaper commodity hardware and you know the brand of the third party OS and other components that they use.

What has happened more recently is that operating systems, databases and other infrastructure have now themselves become commodities. If switching to commodity hardware makes sense, then it makes equal sense to continue the same logic up the stack. Automation vendors could be taking advantage of this to not just cut their costs, but to change how they operate and offer their customers a managed product.

There's no reason why a SCADA vendor shouldn't be able to take commodity software (OS, database, language tools, etc.), add their own product (which would still be proprietary), and offer it to customers all on a single disk. They could then promise to support everything on that disk 100%, including security issues. This is a very successful model in critical financial systems, so there's no reason why it couldn't work here as well.

I think that someone *will* do this eventually, and the other vendors will have to scramble to match it.
 
An analysis of this virus has been published by a security consulting firm in Germany, and the results are very interesting.

http://www.langner.com/en/index.htm

The summary is the virus appears to inject S7 code into OB 35 (timed interrupt), presumably to disrupt a process.

The article's conclusions are even more interesting. The virus appears to be targeted at the Iranian nuclear industry, and is the product of a country who has a strong interest in monitoring and disrupting that program.

The virus infection probably entered the system via an integrator (who was not aware that his own computer had this virus) who also does a lot of business in other the other named countries which were also affected. These secondary sites were not the actual targets however, and tertiary infections spread from there.


The following is my own conclusion. If I had to guess, I would suspect that the integrator was targeted by sending him an e-mail with any one of numerous viruses that target Outlook. The virus would then remain dormant on his laptop until he was present at a customer site and connected to their control network, at which point the virus would then cross to the (MS Windows part of the) control system.

Someone who wants to target a control system does not have to develop a new virus. You can purchase these off the shelf from the thriving MS Windows virus industry. If you are willing to pay a premium, you can get the first use of a new virus.

Now what you do is you pick your target. You find an engineering employee in that target company our you find an integrator who does a lot of business with that company. Next, you send an e-mail to them with an attachment (e.g. "see the attachment for the new project spec"). If you are using a new virus, your virus scanners probably won't block it. The virus then runs and installs itself in his computer.

Now, at some point that employee or integrator will need to do some work related to the target control system and the virus can do whatever it is that it is intended to do. If you have a SCADA or HMI system that uses MS Windows, it can install itself on that system. If you are just using PLCs, it can read the PLC memory or inject code into the PLC program. As to why someone might want to do that, well I suppose there could be lots of reasons.

This is an interesting example of how security is no stronger than the weakest link. You can have all the wonderful firewalls, virus scanners, and network isolation you want, but you still have to connect that laptop (or USB key) into the system if you hope to do anything useful with it.
 
C
This is one of the few areas where I respectfully disagree with Michael. Not because it wouldn't improve the situation for security, but because it would provoke a era of proprietary zeal such as even the automation world has never seen. Everything possible would be perverted for absolute lock-in and wrapped in the flag of security. I think that the vendors should be responsible for their solutions end to end, that's good, but that they should do it by adopting the standards and commonality that would make it manageable. So, if they need a secure OS, they should all use the same one and spend the time they would spend developing N totally incompatible ones improving the security of the one standard. And maintaining it, so that it remains secure. This could be easily done with Linux, for example, an "automationix" distribution could be tailored specifically for automation and could be made very bulletproof by exclusion of unnecessary cruft and concentrating on the real problems in industry. I feel one arrow with all that wood behind it, would be infinitely more secure than the 50 independent parallel implementations we would see each with one fiftieth of the possible effort to secure them.

Just my opinion

Regards
cww
 
C
I'm sorry Michael, I just posted my reservations as disagreement with you. Now I see we are, as usual in agreement that we shouldn't throw standards and commonality away in hopes of security. Giving the vendor license to roll their own OS, for example, would be moving in the wrong direction.

Regards
cww
 
In reply to Curt Wuollet: If you are using a proprietary SCADA or HMI, you're already locked-in to the vendor. If you want an open SCADA system, then you need to be using open SCADA software. What I'm talking about is the "appliance" model of software, which can be proprietary, open, or somewhere in between. I don't doubt that an open system is better, but that's another discussion.

As for creating an "Automationix" distro, you might want to look at something like this:
http://susestudio.com/

That's from the number 2 enterprise Linux distro. People are also doing "spins" (derivatives) based on Fedora and Debian, but those take a bit more work. EMC2 (the open CNC project) do a derivative based on Ubuntu. If you're looking for an interesting project, try making an Automationix spin and see how it turns out.

From a practical point of view, I would imagine that a SCADA vendor who wanted to make a SCADA appliance would use something similar. They definitely wouldn't write their own OS (it wouldn't be economically feasible). They could outsource platform technical support to the parent distro, but still retain the option of changing platform suppliers later if there was a business justification for it. There are companies outside of the automation field which are doing this for a while now. The automation business is simply (as usual) several years behind the curve.
 
Thank you Michael for continuing to feed us examples of security incidents and further information. I have stopped actively contributing to these discussions (I am bored of repeating myself) but appreciate the intent.

David
 
Generic malware isn't the problem; viruses like Stuxnet are specifically targeting a specific industrial site, and can be tailored to attack zero-day holes even in linux. No OS platform is 100% secure. Worse, the configuration and apps running on the OS are not necessarily secure; as I pointed out on a previous thread on this subject, the root account password on some industrial controllers is hardcoded to "password"!

Sites need to have procedures and policies in place that reduce their exposure--isolation of the networks, limited physical access to the PCs (ie it is hard to plug a USB drive into a machine locked in a cabinet), managed switches that do not allow unauthorized devices.

Stuxnet also shows that the supply chain is a risk--don't trust your vendors to ship clean PCs. :) That, certainly is a vote for open source, as it is hard to verify that nothing has been tampered with in a proprietary system--especially one with a huge number of files and processes like Windows.
 
C
No, nothing is immune from a determined attack by someone who is smart enough and has the resources. My question is: Why do we have to make it as easy as possible and use the worst case combination of the world's favorite virus target, insecure apps, and the worst case for virus propagation, having the whole organization using these? And conveniently networked together! If you wanted to make a Honeypot to deliberately collect viruses, you couldn't do much better than that. Seriously, how could you make it any easier? Traditionally, PLCs have been a hard target for mischief. Not because they are particularly secure by design, but because they were isolated and you would need to have physical access and the right tools to sabotage anything. Now, many are tightly tied to, and systems dependent on, extremely vulnerable PCs, that for many reasons, are probably the least frequently maintained and updated in the company. That's why it's not very surprising that this sort of thing is happening, what's surprising is what took them so long? And, of course, that people will continue to follow this worst case model.

Regards
cww
 
Yes, no OS is 100% secure. However, some are a good deal worse than others. You need to be able to spend most of your time concentrating on running your operations rather than babysitting the OS. That's just common business sense. Somehow banks and stock brokerages manage to be on the Internet without this being an insuperable problem. I would think that with all the money they have someone would have taken a crack at them if it were just a matter of making the effort.

As for the Stuxnet virus itself, there's really nothing that exceptional about it from a technical standpoint. You can buy zero day MS Windows virus exploits on the black market. There are businesses (mainly based in eastern Europe) that write them and then sell them to third parties. The third parties then add whatever payload they want. That's usually to set up a bot-net, but there can be other reasons as well.

As for targeting a specific site, again that isn't new. There's actually a name for it - spear-phishing. Up until now they have been targeted at business or communications systems rather than industrial controls.

There are really only two things that are new in this case. One is that it appears to have been used for political purposes, likely by a country who is trying to hinder Iran's nuclear industry and has no qualms about harming third parties while they are at it. I don't think this is the forum in which to debate on who that country likely is.

The other new thing is that this is targeted at an industrial control system. A lot of people who read this forum have been crossing their fingers and hoping this would never happen. It has happened though, and it has no doubt opened the eyes of a number of people as to the potential money-making opportunities available.

This time, it was likely a political attack. The next incident could simply be a more routine "business" effort. Many legitimate Internet businesses do pay protection money to organised crime to avoid being hacked or knocked off the Internet. You don't have to create a virus in order to use one. You can buy them off the shelf from black market specialists. After that, you just need a payload, and that probably isn't too difficult in itself.

I can think several people whom I believe have the technical ability to create such a thing (although I don't think they would) given an off the shelf virus. It is also relatively easy to think of ways of making large sums of money by knowing that a large plant will be disrupted at a certain time.

What I expect to see happen over the next few years is companies trying to sell useless "security scanners" and "detectors" that make customers feel better without actually doing anything for security. Most of that will contribute more to downtime than it will to security, and we'll have lots of questions here from people who just want to turn it all off.
 
C
That is amazing, and it sounds like Siemens is full on scrambling. If it does what they say it does, they _should_ be. They are extremely lucky that this was apparently a targeted attack. If the virus can load blocks into a running program, it's not hard to imagine making a general purpose Simatic killer if they opened up the trigger conditions. I'm sure someone could come up with a block, that when loaded, could hose almost any running program or do other malicious mischief. Even done blindly, that could cause tremendous mayhem and damage and maybe even kill people. At least they shared the blame.

Regards
cww
 
Top