New Windows Virus Targeted at Industrial Controls

> 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. <

That's the point. In the past we had PGs, just for that reason, ugly, heavy and slow. No shiny PC with browsers, mail, entertainment and internet.

Roll back!

Keep the Step7-box just for programming and all is fine. Close projects and let MD5 seal it.

Use the keyswitch at the PLC.

Use MD5 always.

The "virus" was successful because of laziness. You maybe care about becoming infected by using stuff from usb-sticks but none of you thinking the same way by using the cable for the network.

Safety is a permanent process and it is hard work, anytime and anyplace.
 
I do reply to Griffin
You wrote: 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.

Its not the forum to debate but: Why nobody blames Siemens for selling technology to Iran, that helps their nuclear industry.

I don't understand about Viruses and not about nuclear industry but it seems to me that the second is much more dangerous.
 
Numsi said:

> That's the point. In the past we had PGs, just for that
> reason, ugly, heavy and slow. No shiny PC with browsers,
> mail, entertainment and internet.
>
> Roll back!

While I mostly agree with this, some of us (maybe even many of is ??) are in situations where we have to store or backup our files to a shared fileserver. Most of the time these shared resources are open to office computer access.

Somehow spending my whole day on a computer editing PLC files in a "black box" programming unit and then having a regular computer next to it that is hooked up to the mothership is unreasonable. Do you have all of your "programming units" backed up regularly and store copes of these backups off site in case of a fire?

Even if you could pull this off your network administrator and fellow employees would think you are crazy, even though you would be mostly right to work in this way!

I think the automation, business, and "office" all need to be on separate secure physical connections and bridged only by tightly managed secure switches/firewalls. Unfortunately many small and medium sized companies don't have IT staff that is trained well enough to analyze and support these cobbled together manufacturing situations. For years companies have been busy trying to tie their automation into the business backbone and now we are suffering.

~Ken
 
S
"While I mostly agree with this, some of us (maybe even many of is??) are in situations where we have to store or backup our files to a shared fileserver. Most of the time these shared resources are open to office computer access."

I see no reason they couldn't be archived or encapsulated in some way the virus isn't prepared to deal with. Simply ZIPping them might be adequate. ZIPping with a password or encrypting the entire application would be other steps that should be increasingly confounding to the virus.

"Even if you could pull this off your network administrator and fellow employees would think you are crazy, even though you would be mostly right to work in this way!"

That's an odd statement. So if you're doing the right thing and everything thinks you're nuts, you should stop doing it? Sounds like THEY'RE the ones who need to adjust.
 
@Ken
Yepp, I know the probs.

A couple of years ago I stated that there is no one who knows both sites, the PLC and PC. And joining them together in a safe way is a big challenge. Today this is still true, unfortunately.

Security is a hard job and it is full-time.

I remember a line in Australia where a secretary printed to a printer which ip owned by a frequency drive. That was fun... Took a couple of days with a lot of manpower to find out what went wrong including no production.

As I sayed, this everyone network with anything stuff. Its like heaven and hell. Heaven is if you get what you like from your boss. Hell is if you have to make it work what your boss is expecting from it. Try to get your boss at least half way on your side.

Thanks for reading :)
 
In reply to Ken E: I think you've hit the nail on the head on several points. There is risk in doing certain things, but there is also risk in not doing them. Consider the following dilemmas:

1) Your new production line has just started up, and as the machine builder is on his way out the door he holds out a USB stick to you and says "here's a copy of all the PLC programs, do you want them?". If you take them, might they have a virus (after all, who knows where his laptop has been)? If you refuse them, how do you get the line running again when a PLC loses its program, or has to be replaced?

2) Your backup system consists of storing copies of the PLC programs on the network where everyone can get them. Unfortunately, the virus can get them as well. If you *don't* store them there however, then what are the chances of ever finding an up to date and working copy of a PLC program again when you do need it again in an emergency (probably about zero)?

3) If you connect the production system to the business, you risk having a virus spread from one to the other. On the other hand, if you don't connect them together how do you move accurate and timely production information between the two so that your company can remain competitive?

In each of these cases we are balancing two risks. If we do one thing we *might* have a virus problem. If we do the other we will almost certainly suffer other problems (lost programs, uncompetitive operations, your company going broke, etc.). I expect to see happen is for companies to sell expensive and useless placebo software "solutions" that do nothing to address the root of the problem.

Here's the root of the problem. Businesses have been getting viruses on their office PCs for years (decades even), with no sign that this will ever change. If we do things exactly the same way in the plant, why would we expect to see different results? After all, if it were just a matter of following a few simple security check lists, then wouldn't the office IT types be doing that already?

On the other hand all banks, insurance companies, and large businesses of many description use very different back office system designs than what gets used in front office applications. They have their "production systems" hooked up to the Internet, but I don't see too many of them getting taken down by viruses, despite the attractive target they must make. When companies like Google get hacked, it's generally through things like people in their sales departments getting a virus on their office PC and getting their account passwords stolen (which is the same thing as mentioned above). Genuinely critical back office stuff rarely gets hacked directly.

We have two types of system to consider. Type "A" is the front office desktop PC. Type "B" is the "critical" back office business systems. Type "A" gets viruses regularly (enough that selling virus scanning software is a multi-billion dollar business). We just live with the problem because let's face it, it doesn't really matter if the latest policy memo from HR on the allocation of parking spots gets e-mailed this week or next week. For type "B" these sorts of problems are very rare (almost unheard of). When type "B" systems go down, the business loses money; sometimes a *lot* of money.

So, are automation applications type "A" (non-critical) or type "B" (critical to the business)? If they're type "B" (critical), then why are they designed to be exactly like type "A" (non-critical) systems?

Someone once said that the definition of insanity is doing the same thing over and over again and somehow expecting different results. I look at what is going on in the automation industry and it looks pretty crazy to me.
 
In reply to Steve Myres: You said: "I see no reason they couldn't be archived or encapsulated in some way the virus isn't prepared to deal with. Simply ZIPping them might be adequate."

This virus already looks for PLC program files in ZIP archives and infects them there. The answer's not that simple.

Once a virus is established in your computer, it can do literally *anything* the computer is capable of doing. It can do things like insert itself into the operating system so that if you attempt to look at a file to see if it has been changed, it can just intercept that operating system call and show you innocuous looking data. Some viruses do exactly that.

There are literally tens of thousands of different MS Windows viruses. If there was an easy answer to them, the people running office IT systems which use MS Windows would be doing it now. They're not, so there probably isn't any answer that doesn't involve a complete re-design of MS Windows from the ground up, and if Microsoft did that, then probably none of our existing MS Windows software would run.

If there's an answer here, it isn't going to be quick or simple.
 
R

Rahul P Sharma

Is it time to go back to the good old days when PLCs ladders were programmed not thru a PC terminal but directly by using the Keypad on the PLC and assigning the memory addresses to the contacts.....!!!! Something that we used to do with the 8085 Microprocessor kits in college labs..... Instead of using a cross compiler and PC based system and programming the kit, it used to be directly programmed from the attached key pad.....!!!

Even then the system cant be declared foolproof..... Cos the PCs would be used at at least some level.... May be the PLC manufacturing process is some PC based system..... If a person is genuinely interested in letting a virus loose, he may do it at the PLC manufacturing end..... some virus code may be made memory resident at the time of manufacturing the PLC hardware...... And when the PLC is programmed at the site even using a direct keyboard attached to it without a PC, the virus would still be there.......!! and I guess there is no limit to going backwards in stages...... If PLC manufacturing process can be made manual and PC independent, then the virus writer can target the memory chips making companies and make their chips virus resident at some stage before they are shipped to the PLC manufacturer.....

The dangerous aspect of stuxnet is the idea, that PLCs can be infected with a virus and the possibility of an industrial disaster can happen..... I think there's no good way to stop the viruses from spreading itself..... Today we have stuxnet..... And am sure, there would be a hacker smiling somewhere thinking to target other PLC makes too..... Siemens is just a symbolic case, may be cos the fathers of Stuxnet had a certain country in mind which might be running a Step 7 system for their nuclear plant...... But this certainly raises the possibility of similar viruses for other systems too......
 
In reply to Rahul Sharma:

Again, someone had already mentioned this. If you take a programming PC (any OS, doesn't matter) and just load the PLC software and super glue all removable media and network ports/wifi you will essentially have a extremely secure system (and lock it in a vault with security guards for extra measure...). For something like a nuke plant or a high risk power plant/refinery, whatever, this sounds like a good idea. You need to do manual backups to a device that can be removed and not shared with any other computers.

Some of us fall in the middle, however, where we need to collaborate with others, put our files on shared resources and don't always have a choice of how that information is protected (it is guarded by IT and you are at their mercy).

Others are in situations where the manufacturing floor has to be linked into the business end of the company for critical run time data exchange and control and the automation guy doesn't always have a choice of how the network switches and routers are configured in the server/network room. The automation guy doesn't always know how to do this or has time to do this either.

I've always tried to design my machines where you pull the network plug and the machine still runs. Maybe I've been lucky in that most of my machines are standalone and don't need a lot of network connectivity to the corporate LAN other than non critical data such as reporting, etc. Others are not that lucky.

The fact that a virus is attacking PLC backup files on a filesystem is very disturbing and blows the whole theory of "running your machine unplugged". One consolation I have is that most of the office computer accounts don't have access to the machine backup files, but there are enough people that do have access that it worries me.

~KEJR
 
In reply to M. Griffin:

Yeah, I agree with your points too. We are now in a complete catch 22 that has allowed a culture that accepts someone [in a business setting] to install flash player to play facebook games at lunch time and letting grandma in accounting click on MrCutieCat.jpg.exe from an email attachment, all with administrator rights!!!! Some of this is dying down, but very slowly and many people don't have a choice at the present (There may be a critical application requiring administrator rights, etc, and changing it would nearly bankrupt the company...).

I have to be nice to my IT guy because he might be monitoring this (wink, wink) :eek:) but in reality the automation guys are going to have to be their own security experts in order to understand the unique requirements of networking and security as it applies to manufacturing and equipment. Lets face it, it doesn't follow the typical model of typical databases and servers.

Its one thing to say that "we should know better", but in reality many companies in this economy have extremely limited resources, to the point where day to day business operations are barely getting done. When you are always putting out fires you don't have time to put up the fireproofing and sprinklers! :eek:)

KEJR
 
S
<i>This virus already looks for PLC program files in ZIP archives and infects them there. The answer's not that simple.</i>

OK, but that was the LEAST aggressive option I mentioned. If the archive is stored with decent encryption, I think either the extension or file format (if the virus directly examines the file) would be likely to cause the virus to overlook them, and if not, the encryption should prevent it from infecting the archive.

That still leaves open the question of how to secure against the virus when it's converted back to native form when you have to use it, but that can be viewed as a separate issue, and an easier one than if its solution had to deal with security during backup storage.
 
Your Virus could just corrupt your super secure archived project on a file server.... In other words it couldn't infect your project file, but destroy it.

KEJR
 
C
I find it amazing the extremes that people will go to in ignoring the real issue and taking the most complex way out. We're already talking about vastly more screwing around to continue using Windows than is expended in solving automation problems. Yet, when I conclude that it simply is not suitable for automation, there is a great hew and cry and extensive rationalization for using, arguably, the worst possible choice. For example, they are called PC viruses and PC problems when there is absolutely nothing wrong with the PCs. And some say that a change of operating systems would do no good when well over 95% of the known successful virii live on Windows, and the rest you've never heard of, because they were not successful. And the virus problem is only a minor part of why Windows is a poor choice. Speaking of Windows generically, it's huge, it includes vast amounts of cruft of no conceivable use in industrial applications, it has been notably unreliable and insecure and is aimed at gaming, multimedia, and entertainment. There is no way to customize it, you take it all or none at all. The authors have been busy trying to do away with serial and parallel ports and the simple busses that work well for control. The licensing excesses are legendary and although they've finally been unsuccessful at forcing upgrades and had to concede on XP, they will surely get back in stride if at all possible. There are technical issues with control and the design of needed features is a secret and there is little hope of seeing or modifying the source to tailor scheduling, latency or IO to best meet automation needs. Their upgrade treadmill costs millions to support on the user side so that they can make millions on the supplier side and ISVs no sooner complete an upgrade than that version is thrown away and you start over. Except that you have that legacy to support for 20 years. With all that, and there's much more, I cannot see how it's so wonderful that people will all but lay down their lives defending it and reject any suggestion that an OS that can be tailored to automation and revved in a rational manner and has well established security and reliability might, be a better idea. What's wrong with this picture?

Regards
cww
 
S
Ken,

When you figure out exactly what you think the hazard vector is, state it and we can discuss it.

In the meantime, you're correct of course that the virus could destroy the archive rather than subtly corrupt it, but a destroyed archive is orders of magnitude less dangerous than an altered one. Besides, if the virus is incapable of recognizing the archive and damages it anyway, that means it's attacking files randomly whether automation-related or not, which is not a new or unique hazard. Generic virii have always had that capability.

Look, I'm not defending Windows per se, in fact would probably prefer Linux-based programming tools, but if you're going to raise a hypothetical, think it through well enough that if I respond to it, you're first response isn't "But that doesn't address this other issue!" (It wasn't intended to. It was a response to what was posted)
 
K

Ken Emmons Jr.

Steve,
I know there have been viruses taking out data for many years. If you are the guy who is in charge of getting your backup restored it doesn't matter if the archive is destroyed or altered, you still don't have a backup. Up until know I've only heard of viruses taking out the common file names like .doc, .jpg, or trying to currupt your entire hard drive.

Curt: I agree with your assessment of the Linux versus Windows debate in terms of security. I have also seen a trend in Linux lately where some newer distributions are trying to be too user friendly and sacrificing on security. Things like asking you if you want save the root password for package managers, etc. Hopefully Linux doesn't become too "friendly".

Having said that I just got a brand new Windows7 laptop from Dell the other night (Getting an UBUNTU laptop from them costs more apparently...) and I was unimpressed with how they went through all the great care to set up a user account and didn't even care to set you up with a separate administrator account. With all the alleged security updates for windows 7 they still set you up by default to be an administrator (without asking you). Sure you can go back and change it, but most people don't know this or care.

~KEJR
 
D

David Ferguson

Cmon Curt:

Lets get real, if the programming software was Linux based, and all systems running power plants etc was Linux based, how long do you actually think it would be before a determined hacker, accessed that control system if they really wanted to.

The internal processor in the PLC is being attacked using the programming software for that chip. That software is running on windows and they are getting in using social networking, bad practices etc. So how long before they access that chip through Linux using similar methods.

The real issue involves connecting control systems of any kind other than hard coded chip based systems, in other words anything that can be programmed, can be hacked if it is connected or accessed. If the machine is programmed and then we lose the flexibility to change it by burning the program to roms (and this has holes) is the only way to stop it and we lose the gains made in the past 30 years.

The other day I saw an ODB connector for a car, that is wireless and you connect to the wifi in your car with an ipod or iphone and access motor data. How long do you think it is before someone reverse engineers the Diablo preditor programmer or some such thing and hacks the Hemo motor via wifi and ruins or gathers data from the competition at the racetrack or just for fun going down the road if these systems are out there in numbers etc.

If it is accessable which gives us flexibility and the ability to modify (anything) these are the issues that ensue.

A gun can be used for target practice or to kill people, we implement laws to discourage the latter use. In the same way this is a new area and maybe it needs the same treatment, as death can come from this sort of a hack. It is one thing to be stealing corporate info and making a machine do things it was not intended to do.

Once again (12 years and running) switching the OS will not change a thing, if they want in, they will get in, even if that means walking in and accessing the machine with the Linux software...........IT IS NOT THE SOFTWARE, it is the fact that there is software at all, instead of hard coded HARDWARE.............

Dave Ferguson
Control Systems Engineer
 
C

curt wuollet

Let's pretend for a moment that the industry had finally had enough of the Windows insanity and wanted to actually pursue bringing forth an automation oriented OS. They could take an existing high quality Linux distribution (it's OK, everyone does this) although there would be vigorous debate about which, and retain a few good used Linux folks who know automation, (I'm available:^)) and before we're to service pack 3 on W7, they could have a really good target to port to.

If they were respectful of the Linux community, there would be an outpouring of help for such an important (to the community) development.

The up front cost would be minimal, insignificant in corporate terms. There would be costs for the extra security to head off the flood of MS reps offering discounts, bribes, gifts, threats, etc. once the word got out. But, since Linux is pretty close to optimal for customization, there wouldn't be any extensive code work or rewrites needed. They could then port their apps once.

This would not be trivial, but would be well justified by the vastly decreased cost down the line, since _they_ could control the upgrade pace. That would be a direct benefit. The indirect benefits would be stellar. If they want a protocol supported, a bounty that that wouldn't buy a customer golf outing would cause it to appear. A security issue like the subject matter, could be solved _fast_ by application of funds that wouldn't even rate a call back from Redmond. Instead of being surprised by new interfaces and features and having to write to them, they could request new features that make sense for automation.

Or they could continue using whatever version makes sense for them. It would very likely have Modbus and Modbus/TCP built in, rational support for all the serial variants, support for any number of serial ports. and they could very likely use the same distribution for embedded panels and network gadgets of all sorts.

At this point it would make sense for any vendor who sells boards r devices into the automation market, to develop drivers, and if they insisted, they would be Open drivers so they could be well understood. There would be extremely easy choices in the UI to differentiate and apply branding and having the whole *nix array of tools for scripting, programming, glue, etc., would preclude enormous amounts of one shot integration and programming.

After about 2.0, it would be an unstoppable force and nearly bulletproof and we could all get back to automation solutions. It could easily meet Michael's criteria where the whole ball of wax comes on one CD and configured for _real_ security. I'm surprised they haven't done this simply for the cost/benefit of knowing what environment you will be running on and not supporting the hundreds, if not thousands of significant Windows variations they have to worry about now. It would be a much nicer world, once you learned Linux.

Regards
cww
 
E

Eric Ratliff

There was an article, page 1 of Wall Street Journal, April 8, 2009, "Electricity Grid in U.S. Penetrated by Spies", which says "Cyberspies have penetrated the US electrical grid and left behind software programs that could be used to disrupt the system, according to current and former national security officials...The espionage appeared pervuasive across the US". This reminds me of the movie Tora Tora Tora, about Pearl Harbor.

I almost never have customers ask me about security when coosing a product. I was pleasantly surprised today to see that one of our customers using the WinPAC contrller http://www.icpdas-usa.com/products.php?PID=3380 (Win CE OS) did shut down ftp access (which is the user manual recommended procedure).
 
C

curt wuollet

It could be a very long time before anybody broke in. I don't think you're getting how dramatically different that environment could be. When you use Windows, you get the same system as everyone else with any thing that any app might need included, likely enabled, and commonly exploited. We've seen how that model works. You can do things to secure it, if you know about them, and you are allowed to spend the time and effort. Obviously this doesn't happen.

Now let's say I was selling into a critical application like, say a power plant. There would be the application. The system would boot into the application and shut down if the application was exited. No browser, no FTP, no MP3 player, no games, no unnecessary services at all. No outside access, no USB port drivers. SELinux set to high security, tripwire running, the integral firewall tight. For extreme security the necessary services could use non well known private socket addresses.

The system could even be run from CD which would make it pretty much hopeless trying to modify or corrupt files and the file count could be kept down to where it would be practical to checksum them on a cron job. If intrusion was detected or SELinux violations occur, you can simply reboot the CD and you're back to square one. The operator can't screw it up, even physical access wouldn't help much, it just won't do anything it's not intended to do.

They are already doing this for critical systems such as routers and the like. Practical systems for less critical applications could allow development and reasonable versatility and still eliminate any real practical route for takeover. When you can control the OS, you can tailor it to the threat and make it extremely difficult to mess with. Any level between consumer friendly Ubuntu and single purpose appliance is achievable and readily distributed locked down and about as hard as you can get. It would not be impossible to do mischief, but it would be pretty close to impossible to take over the machine and you would be detected doing it. That's a far cry from anything achievable with Windows where you take what they give you.

Regards
cww
 
Top