Having Another User Run a Program

I l @ ve RuBoard

A hacker is always looking for someone else to do his work for him and to take the blame. When the hacker can accomplish this, he can utilize the other person's privileges. The main way a hacker will get another user to run a program for him is through the use of a Trojan horse or by inserting the program into the user's start-up scripts. However, there are a wide variety of ways for a hacker to get other users to run programs on his behalf .

Compromised Software

There are a number of ways to compromise software so that it behaves differently from how it was designed to behave. Virus software infects the host code so that when the host code is executed, the virus is also executed. Virus software can be sophisticated code which inserts itself into binary executables or simple macro command files which are attached to data files. Once executed, the virus code has the privileges of the user who unknowingly executed it.

Trojan Horse

A Trojan horse is a useful or apparently useful program containing hidden code that, when invoked, performs some unwanted function. Trojan horses can be used to accomplish functions indirectly that an unauthorized user could not accomplish directly. When the Trojan horse is executed by the unsuspecting user, it inherits all the privileges that the user who executed it has. It will then use these privileges to perform functions which were unavailable to the hacker. This is why Trojan horses are often impersonating system utilities or other functions which privileged users are likely to run.

Trojan horses have also been introduced in the packaging of software itself. Software can be packaged in a "shar" format, which is un-"shar"ed by sending the package as input to the shell. Commands can be inserted into a shar file that will be executed when the package is un"shar"ed.

Recently, the World Wide Web has been targeted by hackers who have created web pages that appear harmless, yet deliver more than expected by utilizing undocumented features in the browsers and exploiting Java applets.

You can reduce the risk of Trojan horses by creating a quarantine system. This is a system that is not connected to your network and exists only to unload and test software that is from an untrusted source. This will catch the Trojan horses that are in the packaging and will give you a chance to examine the code and test the software in a safe environment.

Spoof

A spoof is a particular type of Trojan horse; it duplicates the action of an existing command and it is run unknowingly by the user.

Spoofs are generally invoked because of an inappropriate PATH variable. The PATH variable should never contain a "." or a blank field "::". These both indicate current directory. The PATH list should be ordered from most secure to least secure. This will prevent system commands, like ls, from being executed from a public directory instead of a system directory. This is very hard to police, since users can change their PATHs and many now build their PATHs with scripts that are dependent on terminal type, character-mode terminal, or X terminal. The minimum you can do is validate the PATH variable in all users' start-up scripts and the PATH in system start-up scripts. All scripts should be checked. Another danger is the listing of a directory that does not exist in the PATH. This could allow for the creation of that directory and the inclusion of numerous spoof programs. All shell scripts should set their own path in the script.

Spoofs also require that the spoofing program have the same name as an existing program, so you may want to search for files that have the same name as common utilities. However, this effort may outweigh its usefulness .

Software Start-up / Shutdown

When software is started, it can read an initialization file that can affect the behavior of the software. There are also a large number of programs that support macros. These macros are generally initialized when the program starts and often have access to all the information to which the user has access. These macros can be disastrous to an unsuspecting victim. They are often written within the context of what they are intended to do and are not evaluated for security risks. In many cases, they have access to command interpreters which have complete access to the system. The values in this initialization file may compromise the security of the user who is running the software or it may cause unexpected results.

For example, there are configuration files for the X windows system that can include values that will allow anyone to access the X terminal. There are also a large number of word processors that support macros. These macros can be disastrous to an unsuspecting victim. For example, the vi editor has a start-up script, .exrc. This file is processed as input commands to the vi program, so you can use the shell escape to insert shell commands that will be executed when the user runs vi.

 ! chmod 666  /etc/passwd

You can keep the vi editor from running the .exrc file by setting the EXINIT environment variable. If this variable is set, it will be executed instead of the .exrc file.

All start-up files should have read-only permission for the owner, who should be the owner of the home directory that they are in.

User's Login / Logout

Every time a user logs in to the system, there are a series of start-up commands that are executed. Some of these commands are executed for every user, while others are specific for specific users. These scripts are generally used to personalize the user's environment and notify users of any critical communications.

A user's login and logout scripts are a fruitful area for hackers. These scripts are often written by the user and have permissions that are lax, or call programs without the use of fully qualified path names , making them vulnerable to Trojan horse attacks.

There are many access methods available to access a system, so there are many login files which have to be modified to support peruser features. Table 11-1 lists the files associated with each shell.

Table 11-1. Shell Start-up Script Files

Shell Name	Global Login Script	User-specific Login Script	Shell Invocation Script	Logout Script
BASH (bash)	/etc/profile	~/.bash-profile	~/.bashrc
Bourne (sh)	/etc/profile	~/.profile
C Shell (csh)	/etc/csh.login	~/.login	~/. cshrc	~/.logout
Korn Shell (ksh)	/etc/profile	~/.profile	~/. kshrc

All these files must have proper permissions. Those in the user's home directory, which are often created or modified by the user, are especially susceptible to permission errors. If there are script files for shells other than the user's default shell, they too must be checked, because the default shell can be changed with the change shell, chsh , command. Some versions of UNIX systems may limit valid login shells to those listed in the file /etc/shells . Limit the shells to only those you utilize.

System Start-up

Each time a system is booted up, it executes a specific set of start-up procedures with superuser privileges. Initially, the operating system is loaded into memory from the file system. The system generally has a default operating system file or kernel, but any properly configured file can be used. Then the initialization process, init, is started.

The initialization program executes the programs and scripts as directed by its configuration file. Any programs or scripts that are run during this start-up procedure are an area that can be exploited because they generally run as the superuser.

If the permissions are such that any of these programs can be replaced , a hacker has the ability to alter the system in any fashion. This is a place where a Trojan horse can be used if the program search path is not set correctly or properly secured.

You need to fully understand this process, as well as all the programs that are executed during a system start-up. First of all, if the boot file is replaced or removed, the system will either not boot up or will boot up differently from its intended method. All the programs that are started from the initialization program and all the subsequent programs must have their permissions checked. All programs and scripts executed during system start-up should be owned by root and be readable only by root. All programs that are executed from these scripts should either use fully qualified path names or the path variable should be set in the script. All of these scripts and the programs that they execute should be periodically checked to validate they have not been tampered with.

System Shutdown

Each time a system is shut down, it goes through a specific set of shutdown routines. These routines, either a series of scripts or a directory containing a number of scripts, are automatically executed at system shutdown. These scripts normally execute with root privileges. This allows for the orderly shutdown of software subsystems before the system's shutdown.

Quite often these scripts are not closely monitored for security. Just like the start-up scripts, subverting any of these scripts, or any of the scripts or programs they call, will allow a hacker to subvert the entire system the next time that the system is shut down.

These scripts are as important as system start-up scripts and are vulnerable to the same type of attack. Unfortunately, they are often overlooked by the automated security checkers. Any script that is executed during system shutdown should be readable only by root. All programs that are executed from these scripts should either use fully qualified path names or the path variable should be set in the script. All these scripts, and the programs that they execute, should be periodically checked to validate that they have not been tampered with.

I l @ ve RuBoard