Avoiding a Trojan Horse

A Trojan horse is a program that does something destructive or disruptive to a system while appearing to be benign. As an example, you could store the following script in an executable file named mkfs:

while true
do
echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console
done

If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions. A malicious user could implement this Trojan horse by changing Superuser’s PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profile-where the PATH variable is set for root-and only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell would run it rather than the legitimate version. The next time Superuser tries to run mkfs, the fraudulent version would run.

Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.

A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid permission. The following command lists these files:

# find / -perm -4000 -exec ls -lh {} \; 2> /dev/null
-rws--x--x. 1 root root 30K Oct 5 12:10 /usr/sbin/userhelper
-r-s--x---. 1 root apache 11K Aug 21 07:15 /usr/sbin/suexec
-rws--x--x. 1 root root 1.9M Oct 4 21:38 /usr/bin/Xorg
-rws--x--x. 1 root root 15K Oct 5 08:28 /usr/bin/chsh
-rwsr-xr-x. 1 root root 23K Sep 14 05:14 /usr/bin/passwd
-rws--x--x. 1 root root 16K Oct 5 08:28 /usr/bin/chfn
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudoedit
-rwsr-sr-x. 1 root root 45K Aug 21 03:26 /usr/bin/crontab
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudo
-rwsr-xr-x. 1 root root 60K Sep 7 08:04 /usr/bin/gpasswd
-rwsr-xr-x. 1 root root 51K Sep 29 11:58 /usr/bin/at
...

This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.

You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment; part of the aide package), that will take a snapshot of the system and check it periodically. See sourceforge.net/projects/aide for more information.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition