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 working with root privileges when you run this command, it will continuously write a message to the console. If the programmer were malicious, it could do something worse. The only thing missing in this plot is access permissions.

A malicious user could implement this Trojan horse by changing root'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 a user with root privileges 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 will run it. Thus, the next time a user working with root privileges 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 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 (page 488) permission. The following command lists these files:

Listing setuid files $ sudo find / -perm -4000 -exec ls -lh {} \; 2> /dev/null

-rwsr-

xr-

x

1

root

root

25K Oct

19

15:

52 /usr/bin/newgrp

-rwsr-

xr-

x

1

root

root

35K Oct

19

15:

52 /usr/bin/chfn

-rwsr-

xr-

x

1

root

root

29K Oct

19

15:

52 /usr/bin/chsh

-rwsr-

xr-

x

1

root

root

38K Oct

19

15:

52 /usr/bin/gpasswd

-rwsr-

xr-

x

1

root

root

35K Oct

19

15:

52 /usr/bin/passwd

-rwsr-

sr-

x

1

root

root

21K Dec

6

22:

11 /usr/bin/X

-rwsr-

xr-

x

2

root

root

104K Oct

9

04

:39 /usr/bin/sudoedit

-rwsr-

xr-

x

2

root

root

104K Oct

9

04

:39 /usr/bin/sudo

-rwsr-sr-x 1 daemon daemon 44K Jul 20 2007 /usr/bin/at -rwsr-xr-x 1 root root 14K Oct 16 10:33 /usr/bin/arping

-rwsr-sr-x 1 daemon daemon 44K Jul 20 2007 /usr/bin/at -rwsr-xr-x 1 root root 14K Oct 16 10:33 /usr/bin/arping

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 it does not clutter the screen.

Another way a Trojan horse can enter a system is via a tainted ~/.bashrc (page 554) file. A bogus sudo command or alias in this file can capture a user's password, which may then be used to gain root privileges. Because a user has write permission to this file, any program the user executes can easily modify it. The best way to prevent this type of Trojan horse from entering a system is to run software only from sources you trust.

Run software only from sources you trust

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

Was this article helpful?

0 0

Post a comment