Tricking Other Users

A hacker prefers to gain additional access to resources on the system rather than launch DoS attacks. To get beyond the system’s defined ACLs, a local user needs to trick another user into either granting this access or into operating on behalf of that user. Obviously, if you can determine someone else’s password, you can impersonate them. Another approach is to trick the victim into doing something without knowing the operation is happening. The old PATH hack against inexperienced administrators is the favorite example of the latter technique. In either case, you can use this attack to gain read or write access to a resource for which you do not normally have privilege. In the end, as the “Introduction” described, all activities on a system can be reduced to read and write operations for an object.

One of the oldest tricks is to ask an unwary user to run a Trojan Horse that you have set up. The classic example is to tell the administrator that you cannot see a file that should be in your directory. To set up the attack, you create a program in your directory that has the same file name as a system utility such as ls.

cat >> ls
** hack code goes here, such as copying /bin/sh into one of your
   subdirectories **
/bin/ls $*
exit 0
/bin/chmod +x ls

Next you set your PATH environment variable so that your trick directory (perhaps your home directory) is the first directory in the search path:

export PATH=.:$PATH

You then call your friendly administrator to your desk for help. If you’re smart, you will have carried out some social engineering to build up trust so that this person trusts you. The novice administrator would type the following:

su root

This command logs him in as the superuser; he then lists the files in your directory using your ls command and proceeds to show you the file in the directory listing. If the preceding script is run, you can write the hack code to create a SUID root shell in the directory of your choice.

Of course, the administrator should have typed the following:

su - root

This command loads the login profile of the root user and resets the environment. This hack is so well known that it’s unlikely an administrator today would fall for it but this depends on how much training the person has received. Someone who has just been appointed lab moderator and given superuser privileges may be a total security novice and could fall victim to this attack. Even if you have trained administrators, you want to watch for this type of behavior.

To detect the path attack, you look for evidence of someone creating a Trojan Horse. In this specific case, the Trojan Horse is any well-known system command: ls, rm, who, or cat. Hopefully, the IDS you purchased already will have the list of potential Trojan Horse filenames or directory names in a configurable list that you can augment. Otherwise, you would need to compile a rather long list yourself. The monitoring program would look for the file name in the list of system directories, and if the same file name is found in one of these directories, someone is planting a Trojan Horse. In the audit trail, you will look for several events. First, you need to detect that the Trojan Horse was created by looking for audit records with the following:

•  AUID, RUID != 0 (not the root user)

•  FILE_Create or FILE_Rename

•  Filename appears in one of the protected system or application directories specified in the configurable list

You need to consider rename operations because someone can create the file foo and then rename it to avoid detection by a monitor that looks for only file creations. Also, this particular monitor is looking for more than a normal login user trying to do this from a shell. Many SUID and SGID programs create files. If you want to consider whether someone is making the Trojan Horse via indirection, by using a SUID or SGID program, you want to look at the AUID and RUID because these do not change as a result of running SUID or SGID programs. For the moment, this audit event is labeled E1.

Next, you want to look for the event that turns this file into an executable. In AIX this would be a FILE_Mode event. For this example, the audit event for this activity will be labeled E2. The sequence of interest is E1, followed by any number of other events, followed by E2. E1 alone is probably not sufficient to warrant an alarm because the file is not really a threat until its executable bit is set. Because the sequence of events, E1 and E2, are important, you can now see the need for tracking the sequence of activity with some type of graph or state transition model. In order to avoid false positives, an alarm should be signaled if E1 and E2 have the same data values in some of their fields:

•  Same subject (AUID and RUID)

•  Same filename

This means that the IDS not only needs to track sequences of events, but it also must be capable of matching related data across events. This capability is a fundamental requirement implemented by pattern-matching IDSs.

When you must have the same value in fields across events and when values can vary are two conditions that greatly complicate the process of attack signature development. The core problem in signature development is to make the signature flexible enough to catch a number of problems, yet not so broad that it generates false alarms.

In the preceding example, the system should not generate an alarm if someone sets the executable bit for a different file from the one that was created in the first event. Also, if two different users appear in the audit records, this does not constitute an attack (at least not this attack). If two different users did appear in the audit records, you would have an attack in which two users participated—one created the file, and the other set the executable bit. Notice that these two events can be separated by any number of intervening events, so the scope problem still exists. The attacker could first create the file and then run chmod on a subsequent day, particularly if this person knew that the system was being monitored.