Viruses and internet enabled control systems

M

Thread Starter

Michael Griffin

Mark Hill wrote:
<clip>
>During the past two weeks I've received dozens of forwarded messages
>from [email protected]
>
>Each of these messages originated from the Automation List archives and
>contains a virus.
>
>My software is able to spot and immediately delete these intrusions, but
>I'm wondering if the List couldn't do something about tracking down this
>source and putting an end to it.
<clip>
I have also received dozens of messages from this fellow. These are sent directly from the originator - they do not pass through the mail list. The forwarded mail you are getting is coming from his own mailboxes (i.e. past list postings he received). The only person who can stop the messages from being sent is the one who owns the computer in question. I suppose that
being subject to problems like this is one of the "benefits" of modern communications.

This raises a rather interesting question though. Some people are building control systems using Windows and various bits of common Windows
software (e.g. the Outlook mail system, Excell) duct taped together. Some of these machines are now able to send (and receive) e-mail. Once these systems are connected to the internet (or even just to a large intranet), and they become widely known, how long will it be before people start writing viruses which are intended to attack control systems? We may also find that a
conventional office oriented virus does a nice job on machines as well.

I don't think the firewall/virus scanner approach is really all that secure. This doesn't really seem to provide defence in depth. The control systems themselves need to be at least somewhat immune to attack. Windows and typical office type software seem to be ridiculously easy to crack. Is there some fairly reliable means of addressing this problem?


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
A

Alex Pavloff

Michael Griffin wrote:
> This raises a rather interesting question though.
> Some people are building control systems using Windows and various bits of
> common Windows software (e.g. the Outlook mail system, Excell) duct taped
> together. Some of these machines are now able to send (and receive)
> e-mail.
> Once these systems are connected to the internet (or even just to a large
> intranet), and they become widely known, how long will it be before people
> start
> writing viruses which are intended to attack control systems? We may also
> find that a conventional office oriented virus does a nice job on
> machines as well.

(I'm going to reiterate the things I said in my post some time back about security for internet-enabled devices).

Its not viruses which you have to worry about. Control systems aren't going to be running scripting enabled email clients (like Outlook), because, well, that doesn't make any sense. Will they send mail? Sure. Will they recieve mail? Sure. The problem with Outlook and its users is that there are far too many people that will click open attachments.

The main problem with Windows, and indeed, ANY complicated OS used as a control system is their vulnerability to generic denial of service and
buffer overflow attacks. Every operating systems out there has had bugs in web servers, ftp servers, DNS server that have allowed people to halt and/or take control of the targeted system.

Now, Microsoft, as well as the maintainers of affected Linux programs, and the various other people responsible for affected systems all in all do a fairly decent job of reacting to major problems like this. They put out a hot fix or release a note saying how to fix the issue.

The main problem though is that there are HUGE numbers of people that never, ever bother to install these fixes (and most of those people run Windows, rather than Linux or some other Unix). Is this due to lack of knowledge? Seeing as how most control systems are done by integrators or consultants or the like, are companies going to pay the integrator on a contract basis to ensure that their internet-connected control machines are constantly updated with any needed security patches?

> The control systems themselves need to be at least somewhat immune to
> attack. Windows and typical office type software seem to be ridiculously
> easy to crack. Is there some fairly reliable means of addressing this problem?

There is no mechanical or technical ways to ensure that a system is safe. It takes constant vigilance by a human being.
 
M

Michael Griffin

Alex Pavloff wrote:
<clip>

>Its not viruses which you have to worry about. Control systems aren't going
>to be running scripting enabled email clients (like Outlook), because, well,
>that doesn't make any sense. Will they send mail? Sure. Will they recieve
>mail? Sure. The problem with Outlook and its users is that there are far
>too many people that will click open attachments.

Well, imagine a PC based test system with an internet connection. When you buy a PC with Windows, it comes with "Outlook Express". Suppose a service man from the equipment manufacturer asks someone from his own office to e-mail him some test data via the tester - which might be in MS Excel format. The MS Excel file could have a virus in it. Excel is on the computer because it is used to log data from the application. We now have two potential virus entry methods (Outlook and Excel).
All the supposed advantages of using Windows - "familiar to everyone", "lots of standard applications", "easy to buy a PC with it
already installed" etc. start to look like disadvantages in this light.
I think you would have to heavily customise your Windows installation to get rid of these security holes. I'm not sure whether this
always possible. For example, I had a version of Autocad (on my desk computer) in which the help system would not function correctly unless MS
"Internet Explorer" was installed. This was a completely unpredictable interaction between two unrelated programs.


>The main problem with Windows, and indeed, ANY complicated OS used as a
>control system is their vulnerability to generic denial of service and
>buffer overflow attacks. Every operating systems out there has had bugs in
>web servers, ftp servers, DNS server that have allowed people to halt and/or
>take control of the targeted system.

Actually, I'm not overly concerned about the effects of denial of service attacks on communications in my own applications. The type of
equipment I use is intended to continue to run for some time without any network connection at all. I can see how this would concern someone who is relying on an internet connection to monitor a remote site. Within a single plant though, a denial of service attack coming from the outside should be able to be blocked before it reaches the equipment.


>Now, Microsoft, as well as the maintainers of affected Linux programs, and
>the various other people responsible for affected systems all in all do a
>fairly decent job of reacting to major problems like this. They put out a
>hot fix or release a note saying how to fix the issue.
>
>The main problem though is that there are HUGE numbers of people that never,
>ever bother to install these fixes (and most of those people run Windows,
>rather than Linux or some other Unix). Is this due to lack of knowledge?
>Seeing as how most control systems are done by integrators or consultants or
>the like, are companies going to pay the integrator on a contract basis to
>ensure that their internet-connected control machines are constantly updated
>with any needed security patches?

I don't see continuous upgrades as being technically or economically feasible (at least with today's operating systems) in a production setting. There often simply is no time when the machine is available to do this. Furthermore, how can it be feasible to regularly test (and possibly modify) custom applications regularly to accomodate these updates? For example, there is no guarantee that a program written for Windows NT4.0 will work with Windows 2000, yet you might have to switch to Windows 2000 if updates are no longer offered for Windows NT4.0.

>
>> The control systems themselves need to be at least somewhat immune to
>> attack. Windows and typical office type software seem to be ridiculously
>> easy to crack. Is there some fairly reliable means of addressing this
problem?
>
>There is no mechanical or technical ways to ensure that a system is safe.
>It takes constant vigilance by a human being.
<clip>
On the other hand, there must be certain common weak points for viruses or worms to exploit. If these can be avoided, the risk would be greatly reduced. Most industrial computers are applied in very clearly defined roles. They simply don't need much flexibility. This suggests that it may be possible to create some clearly defined design and configuration rules for industrial computer systems which can avoid most of the common risks. Perhaps we could even have an "industrially hardened" configuration which removes some of the common high risk software.

I suppose someone could offer a standard version of Linux which left all the high risk features out if they felt there was a demand for it.
With Windows, it might be possible to customise a standard installation, but this would probably require more Windows expertise than
most people writing custom software for Windows have. Some clearly defined standards would need to be written for these people to use.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
Sitting on Bombs ready to explode ???????

OR

It's a big bad world out there!

I once wrote an article to a magazine titled "firewalls in your control room", which has had no luck of coming on print till now. And technology runs so fast, it would probably have some "obsolete value addition" today.

Consider this:
a.. If you have your programming software and HMI in the same PC and your PLC is in run-program mode then anybody who can write viruses or who can control your PC could change your program without your noticing it.
b.. If the people writing anti-virus softwares around the globe cannot write them fast enough to prevent viruses in commercial software's then
control systems could be sitting ducks.
c.. I have used DCS systems with FTP and Telnet and the one vendor representative had stated that though the Operator stations, the information management stations and the controllers are in the same network and the information management station is connected to a PC and thereby to another LAN/WAN and thereafter to the internet, the different networks make the system impregnable. I was not clear what he meant and
the train reached my destination so the discussion was cut short, but am still not convinced on the safety aspects.
d.. Add the fact that in most control systems, the passwords are relatively simple. In fact many do not change the default passwords.
e.. Most systems are proprietary in nature and hence the user can rarely obtain the detailed knowledge for protecting his own interests.
f.. As more and more people start using various other OS's, viruses, trojans, timebombs, worms and their likes for all OS's grow. Safety is
only for the day and breached by some new crack tomorrow.
g.. One leakage in Bhopal affected more than 30000. How many lives can a break up of your safety systems affect?

If any fantastic programmer-hacker or worst a very good cracker set about to the task, many a plant could suffer a major disaster.

All said and done the safety interlocks are "better off" not connected to the big bad world of internet. A lot is at stake even to risk that one in a billion or trillion chance of a crack.

More comments criticisms are sought in order to benefit us all !!!

Some guidelines that I believe could lessen your pressure are:
1.. Do not use default passwords in your controllers, PLC's, DCS, SCADA and other systems.
2.. Engineer password should not be Engineer. Use cryptic passwords.
3.. Do not keep your system running with the highest level password where all changes are possible. logout and login to lower levels when
your work on the highest level is over.
4.. If FTP and Telnet and other such facilities are not being used then disable them.
5.. If your controller, PLC or control system has a run-program switch, please keep it in run mode. Put in program mode only when required and switch back to engineer mode when the need is over.
6.. restrict access to passwords.
7.. Keep your programming software in a different machine and not on your regular MMI-HMI machine, so that if the culprit tries to use your
software, he is effectively blocked.
8.. When your engineer leaves your setup, change your password and use a different logic in the password than the one used previously.
9.. Firewalls where you connect to the internet. Additional Firewalls-protection in your PC-DCS or other controls stations could help.
10.. Audit your system and program software regularly.
11.. No connection between your safety interlocks and the big bad world is "best" policy.
12.. Do not put bypass algorithms in your operator station or DCS. many people find the use of some memory bits as bypasses in their
logic's very very convinient. A happy announcement "No more trips when the foreman/technician/engineer puts the piece of metal to bypass and there is a loose contact.!" These are then mapped in the SCADA or DCS and the operator with some password is able to bypass the safety interlock when maintenance is going on. Though such systems have safety procedures for their use built in by the user, they do not protect you from outside world attacks.
13.. If you have a system which uses conventional mnemonics, (For example a control system for a standard machine like gas turbine with a standard control system has standard mnemonics used for accessing control points from other systems) then these could prove to be very
vulnerable. Protect them in the best possible way.
14.. Remember bad things always have a lead over good things or "the thief is one step ahead of the police". Connect to the internet
intermittently and monitor these connections. Check and audit your system regularly.
15.. A happy Control system need not have a CDROM or Floppy disk drive. The two common sources of viruses.

Please add to this mail and critics are most welcome.

Anand
 
C

Curt Wuollet

There is a really easy way to deal with this problem. Don't use Windows. Linux avoids most of this because what these programs are are not really viruses. They are perfectly valid Windows application programs using features that Microsoft put there intentionally so you can do the same things the "viruses" do. Having these glitzy features is more important than security because obviously you don't care about security if you use Microsoft products. They can't close them or people's pet gee-whiz gizmo stops working. So they stonewall. It works for them! Even after whole sections of the government were taken down by a curious teenager they still won't diversify. Love Windows, love the "virus of the week".


Regards

cww
 
&lt;snip>
There is a really easy way to deal with this problem. Don't use Windows.
&lt;snip>

Interesting idea Curt, but try convincing an IT manager with a 1,200 node Win2K network to convert to Linux. Ain't gonna happen...... not on
my network.
A properly configured Win2K network will avoid MOST of the virus, DOS and DDOS attacks that have happened recently.

I haven't had a problem.

Mark Hill
 
M

Michael Griffin

At 08:39 13/06/01 -0700, Mark Hill wrote:
&lt;clip>
>Interesting idea Curt, but try convincing an IT manager with a 1,200
>node Win2K network to convert to Linux. Ain't gonna happen...... not on
>my network.
>A properly configured Win2K network will avoid MOST of the virus, DOS
>and DDOS attacks that have happened recently.
&lt;clip>
"A properly configured Win2K network" is missing the point. If someone is building a piece of test equipment for a costumer, how do they know how to configure *that specific machine*? What do they do if it's a standard machine intended to be sold to *many* customers? You can't worry about how every possible customer will configure their network. Forget the the other
1,999 computers on the network. What do we do about this particular one?

I don't think the firewall/virus scanner approach is reliable enough. I think each particular piece of equipment needs to have a large degree if immunity designed into it. Some form of defense in depth is important, otherwise if the outer "hard shell" (the firewall) is penetrated everything inside is vulnerable.

And why would a few Linux (or QNX, or something else) computers be a problem for a network which has Windows 2000 computers on it? I don't believe a network needs to be homogeneous to function correctly. I know that various people like to say bad things about any form of Windows, but I don't believe that it can really be so bad that it won't communicate with other software systems using standard protocols.


In another message, Eminent made a pretty good list of operating procedures which will reduce potential vulnerability. These can probably be summarised as:

1) Don't leave programming or configuration software on the same PC as your application is running on.
2) Use proper passwords, and change them as required.
3) Don't leave features in your software which will let someone bypass interlocks.
4) Turn off remote access methods (FTP etc.) unless you really need them. We have a system which we allow someone to access remotely to perform minor changes off site. We install an external modem for each scheduled access, and remove it from the machine completely when it not being used.
5) Don't connect to the internet if possible.
6) Have good physical security (e.g. no floppy drives).

I wonder though if there is a particular operating system and application software configuration which will reduce the potential for problems.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
B

Bruce Durdle

AND another issue ...

As a tutor at a relatively impoverished (but aren't they all?) teaching institution, I have to operate on multi-use machines.
Having set up a new PC successfully with a popular SCADA package, I tried to install the same software on a second machine. No luck!. The difference ... the the second machine had been connected to the Internet and had (apparently) promptly automatically connected to the Microsoft site and downloaded a few new drivers, that were not compatible with the (dated) SCADA package. That is SCARY.

Bruce.
 
D
Bruce, you've hit the nail on the head with your example. This is truly what is frightening about Windows and internet connectivity. The problem
isn't so much that this stuff happens (downloading new drivers for example) but that it happens without your intervention/permission, and it does it without regard for the ramifications.

I haven't seen it for a while, but there were some internet applications like BackWeb that used so-called "Push" technology to automatically download information to your PC without requiring your input. Ostensibly the purpose of such an app is to have a virtual newspaper, for example,
delivered to your desktop. Of course the technology could be used (and probably was) for nefarious purposes, which probably explains why I
haven't seen it around much.

Personally, I think the pace of advancement in technology is too high. It simply outpaces our capacity to understand all the potential
ramifications. Why do you think Windows crashes so much? It is largely because of so many applications doing their own thing without regard to the other apps, and the fact that Windows actually allows these programs to f*** with the OS. I've never used Linux, but from what I've read on this board (especially from cww!) it seems as if they've developed a more bulletproof OS. I have a feeling though, that if Linux makes some inroads in market share and more software is developed for it, we will start to see some of the same issues arise. Vendor X's app is going to
cause problems with vendor Y's app.

To expand on the above, why do you think PLC's are still so popular for industrial control? It's because people like me are paid to understand the ramifications of what we do. We know that PLC technology is mature. We appreciate that the pace of advancement is in line with our level of risk tolerance. Consumers (to whom bleeding edge tech is pushed) are typically less concerned with 100% reliability and processor uptime.

Dean Reimer
Westroc Inc.
 
Top