Trojan Horses

9.9.1 Trojan Horses

Writing malware is one thing. You can do it in your bedroom. Getting millions of people to install it on their computers is quite something else. How would our malware writer, Mal, go about this? A very common practice is to write some gen- uinely useful program and embed the malware inside of it. Games, music players, ‘‘special’’ porno viewers, and anything with splashy graphics are likely candidates. People will then voluntarily download and install the application. As a free bonus, they get the malware installed, too. This approach is called a Tr ojan horse attack, after the wooden horse full of Greek soldiers described in Homer’s Odyssey. In the computer security world, it has come to mean any malware hidden in software or a Web page that people voluntarily download.

When the free program is started, it calls a function that writes the malware to disk as an executable program and starts it. The malware can then do whatever damage it was designed for, such as deleting, modifying, or encrypting files. It can also search for credit card numbers, passwords, and other useful data and send them back to Mal over the Internet. More likely, it attaches itself to some IP port and waits there for directions, making the machine a zombie, ready to send spam or do whatever its remote master wishes. Usually, the malware will also invoke the commands necessary to make sure the malware is restarted whenever the machine is rebooted. All operating systems have a way to do this.

The beauty of the Trojan horse attack is that it does not require the author of the Trojan horse to break into the victim’s computer. The victim does all the work. There are also other ways to trick the victim into executing the Trojan horse program. For example, many UNIX users have an environment variable, $PATH, which controls which directories are searched for a command. It can be viewed by typing the following command to the shell:

echo $PATH

A potential setting for the user ast on a particular system might consist of the fol- lowing directories:

:/usr/ast/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/ucb:/usr/man\ :/usr/java/bin:/usr/java/lib:/usr/local/man:/usr/openwin/man

Other users are likely to have a different search path. When the user types prog to the shell, the shell first checks to see if there is a program at the location

/usr/ast/bin/prog. If there is, it is executed. If it is not there, the shell tries /usr/local/bin/prog, /usr/bin/prog, /bin/prog, and so on, trying all 10 directories in turn before giving up. Suppose that just one of these directories was left unprotect-

ed and a cracker put a program there. If this is the first occurrence of the program in the list, it will be executed and the Trojan horse will run.

SECURITY CHAP. 9 Most common programs are in /bin or /usr/bin, so putting a Trojan horse in

/usr/bin/X11/ls does not work for a common program because the real one will be found first. However, suppose the cracker inserts la into /usr/bin/X11. If a user mistypes la instead of ls (the directory listing program), now the Trojan horse will run, do its dirty work, and then issue the correct message that la does not exist. By inserting Trojan horses into complicated directories that hardly anyone ever looks at and giving them names that could represent common typing errors, there is a fair chance that someone will invoke one of them sooner or later. And that someone might be the superuser (even superusers make typing errors), in which case the Trojan horse now has the opportunity to replace /bin/ls with a version containing a Trojan horse, so it will be invoked all the time now.

Our malicious but legal user, Mal, could also lay a trap for the superuser as fol- lows. He puts a version of ls containing a Trojan horse in his own directory and then does something suspicious that is sure to attract the superuser’s attention, such as starting up 100 compute-bound processes at once. Chances are the superuser will check that out by typing

cd /home/mal ls –l

to see what Mal has in his home directory. Since some shells first try the local di- rectory before working through $PATH, the superuser may have just invoked Mal’s Trojan horse with superuser power and bingo. The Trojan horse could then make /home/mal/bin/sh SETUID root. All it takes is two system calls: chown to change the owner of /home/mal/bin/sh to root and chmod to set its SETUID bit. Now Mal can become superuser at will by just running that shell.

If Mal finds himself frequently short of cash, he might use one of the following Trojan horse scams to help his liquidity position. In the first one, the Trojan horse checks to see if the victim has an online banking program installed. If so, the Tro- jan horse directs the program to transfer some money from the victim’s account to

a dummy account (preferably in a far-away country) for collection in cash later. Likewise, if the Trojan runs on a mobile phone (smart or not), the Trojan horse may also send text messages to really expensive toll numbers, preferably again in a far-aw ay country, such as Moldova (part of the former Soviet Union).