Protecting your network from rogue programs

PROTECTING YOUR NETWORK FROM ROGUE PROGRAMS

Hanna Goodbar

CIS 4220 01N

Business Telecommunications

AUTHOR’S NOTE

I have discussed the Internet Worm in greater detail than necessary to illustrate how viruses and worms penetrate a network and how they could bypass normal network security.


UNIX computers connected to the Internet network suddenly found themselves besieged on 2 November 1988. Starting from the MIT Artificial Intelligence Lab, a program started infiltrating computers on the Internet. (Internet is the child of ARPANet, a nonclassified military network. Internet contains computers of the scientific and university communities.) The program seemingly had very little trouble breaking into computers. Nobody might have noticed that a program was penetrating their system, except for the fact that the computers were operating at excruciating slow speeds.

Hours later, after a copy of the program was isolated and de-engineered (converting binary machine code to human-understandable code), it was found to be a worm. A worm is in the same family of usually malevolent programs that systems breakers use to destroy or illegally modify data. Specifically, a worm is a program that moves from one computer to another, and can have multiple copies running in the same computer.

The worm’s main gateway into a computer was through the UNIX sendmail program. Two features in the program allowed the worm to send over a “boot program” and have that boot program bring over the main worm code, and allowing it to run in the newly infected computer. The first feature was allowing a program to be attached to a mail message, and making the computer run the attached program. The second feature was a “debug” option that examined connections in the sendmail and let an embedded “mailed” program run from a remote connection. These two sendmail features were the worm’s primary route to infecting trusted machines. (Deitel 553, Hafner 257-258)

One of the worm’s best tricks was getting access to a connected machine through a gateway. Called trusted access, this normally allows a user to gate to another computer without remembering another password, once the user was initially connected.

The worm also had other options. It used the finger program to glean information about users on the computer or network. Finger’s stack could be overrun, forcing user information to be placed in a buffer where the worm could find and use it. The worm also used UNIX’s public password file. (This file contains one-way encrypted passwords. The worm would encrypt passwords to find a match in the file.) With the user’s information, the public password file, and an internal “common word/password” dictionary, the worm could often crack passwords to neighboring computers or networks. (Deitel 553) Once in a computer, the worm ran in the background, usually as a daemon (a common name for utility background tasks) owned by a legitimate user of the system (purloined from finger). (Hafner 258)

All of these features made the worm hard to spot initially, an important feature for a program designed to infiltrate as many computers as possible.

Fortunately for those computers and networks affected, the worm did nothing to data or programs. The worm was explicitly designed only to infect a large number of computers, not change data. The worm’s author, Robert T. Morris, Jr. was very careful in assuring that the worm did not modify data; he was only a curious person, not a data saboteur.

How can networks be protected from such “rogue” programs; that is, are there ways to prevent unauthorized programs from executing? The answer is complex, and stem from three areas: how the network is managed, the built-in security features of the operating system, and the network software and hardware. No one area is at fault; a combination of these allow programs such as the “Internet Worm” to roam free through computers.

Perhaps the weakest link is network management. In this particular instance, the sendmail debug feature could be disabled, and finger’s stack could be fixed so that it could not be overrun. Ideally, program execution control should be kept to a minimum; however, since widespread virus infections are common, more execution control needs to be exercised.

The trend for controlling virus infections has been virus detection. Programs sit in the background, waiting for “illegal” disk access, inform the user of a possible virus. These programs are only useful when it can detect a virus. Most programs of this type have an internal list of virii it can recognize. If a new or modified virus were planted into the system, the detection program can’t recognize it. A few programs are “pattern” cognizant, which means they know that most viruses perform certain actions. The detection program does not have to know what the virus is, just that it does not act in a normal manner. It should be noted here that these programs do not keep programs from running, per se, just that they block illegal disk writes.

It is known that a network is only as secure as its operating system. One reason that the Internet Worm was so successful was that its creator, Robert T. Morris, Jr., had read the UNIX source code and understood its weaknesses. To most users, the security flaws in UNIX would be unknown; but to someone who read the source code, it was as good as having access to the power switch.

Most operating systems have built-in controls that limit disk access - the modification of files. However, operating systems that limit the execution of programs are yet to exist. Of course, password protection is available, to keep unauthorized users from accessing programs or data files, but not to keep certain programs from running.

Perhaps the area in need of the most work is networking software and hardware. Current network designs seems to depend on external programs or hardware for virus detection and protection. None of the programs keep the virus from running; they lock out unauthorized disk access. Hardware add-ons do the same thing. Some operating systems have attributes that can be attached to a program for execution access, but that is to prevent other users from running the program, not the author. No programs were encountered that keep virus programs from running. The computer cannot know what a program will do until it is run; this is the current state of virus protection.

With the proliferation of virus programs, network design needs to be retooled with virus protection in mind. General solutions for keeping virus damage to a network to a minimum can be found. Tag every running program with the user’s ID, so if damage occurs, the user responsible can be easily determined. Another solution is to limit the number of system resources a program can have. The Internet Worm occupied so many system resources that systems crashed. Computers could also limit the amount of time a program can run, for a certain access. Certain system programs need to run all the time and would be given a higher access than normal.

For each of these solutions are compromises, also. Program tagging can be misleading if a systems breaker enters the network using a legitimate user’s ID. A program could give itself more resources than normal by adopting a parallel processing approach to run multiple copies of a program that communicate with each other. If the time limit for program running is known, a program might save its data and time information, then run another copy of itself to continue the process.

However, none of these implementations can be efficient if the systems breaker has access to the operating system or network software source code. With the source code, the systems breaker has a gold mine in designing efficient and virtually undetectable rogue programs.

Can virus programs be prevented from running? With current technology, no. The current state of technology is sufficient to detect most known viruses, but not new strains. Network design needs to be thought out for better protection from such rogue programs. Until systems breakers learn they cannot penetrate a network, the above implementations need to be considered.


WORKS CITED

Deitel, Harvey M. An Introduction to Operating Systems (Second Edition). Addison-Wesley Publishing Company: New York, 1990. pp 527 - 556.

Fitzgerald, Jerry. Business Data Communications: Basic Concepts, Security, and Design (Third Edition). John Wiley & Sons: New York, 1990. pp 471 - 524.

Hafner, Katie and Markoff, John. CYBERPUNK: Outlaws and Hackers on the Computer Frontier. Simon & Schuster: New York, 1991. pp 251 - 341.