| Previous | Table of Contents | Next |
To simplify your task, you could just look for either of two separate events and request to be notified when either of these occurs:
Using the audit trail is again advantageous here. The file chmod event in the audit log gives enough information about the parameters to the command so that you can detect that someone did indeed set the executable bit on the file.
The other part of the attack is based on getting another user, hopefully root, to run your Trojan Horse. The event you want to detect is when a privileged user runs a program whose file name matches one of the system’s routines, such as ls. As before, an attack signature can be constructed to look for specific filenames, or it could be designed to look for the filename in a set of directories. The pattern would need to consider the following:
If you really are paranoid, you might prefer to be notified any time a privileged user runs a program that is not from a limited set of directories. With most commercial IDS tools, specifying a query such as this one is possible.
These simple examples have shown how you can use the audit trail to detect when local users abuse their right to use the computer and try to trick other users into doing something that grants additional privileges. Luckily, users are growing more cautious and watch for such attacks. Still, other possibilities for misuse exist when people are careless with permissions. The following are some examples.
A pattern-matching IDS starts with minimal data structures initialized. When an event occurs that is the first state for some patterns, data structures are allocated in memory to represent the graph for the pattern. As more events arrive, additional patterns might be set up in memory, and existing graphs may add new data structures to track the context of the events.
You can see how the scope problem affects the memory requirements of an IDS. If the scope for monitoring events begins when the system was first booted and continues until the current time, a number of partially completed graphs will be stored in memory. The total storage requirements for an IDS with a broad scope such as this would be extensive. One design dilemma that IDS vendors face is deciding when to perform garbage collection and remove stale or old patterns from memory. The danger is that a cracker might perform one part of an attack; the system garbage collects the pattern from memory; and then the second half of the attack is executed. The entire attack would go undetected, although a partial attack could be reported depending on how the IDS handles garbage collection.
If the scope is defined as too long of an interval, the storage requirements are too high. Should the designers choose a smaller interval, such as a single login session, attacks across login systems would be missed when they involve sequences of events. Most IDSs today rely on the a login session or a single day as the interval to use for the scope. Letting IDS customers configure the scope interval is more desirable because it enables customers to trade off storage for detectability.
Writing into Another User’s Special Files
Depending on the version of UNIX you are using, the system will run a login script for you during the login process just before you are given control of a shell. If this script file is world writable, other users can insert commands that run automatically when you log in. This attack is another way to trick you into running commands without knowing your password. An attack such as this is detectable in the audit trail by looking for the following:
Why not look at the EUID of the process that emits the file operation event? If the hacker manages to exploit a SUID or SGID program to change the user’s files, the EUID or EGID will be set to the owner of the SUID or SGID program, not the hacker’s UID. To really know the subject of the operation, you need to look at the AUID. This value is the only one that persists despite changes in the EUID or RUID.
Similar attacks can be detected by looking for other operations, such as a user reading from the directory of another user. However, watching for this type of activity may not be reasonable on your systems. If your users have a fairly open environment and constantly share data from their respective directories, you do not want to be bothered by alerts each time this happens. Looking for evidence of tampering in the special files should be enough in these cases. Should you require a tighter environment in which users should not be nosing around in directories belonging to others, you can look for events such as the following:
Explicit Privilege Escalation
The favorite attack for a cracker is to look for SUID root programs with exploitable bugs. SUID and SGID programs owned by other users are also important. For example, if a user can crack some SGID mail program, then that person will be able to operate with the group privileges of the mail account. A hacker strives for three goals with SUID root programs:
Depending on the internals of the SUID program being exploited, one or more of these goals could be met. If the program is interactive and run from the user’s shell, the usual goal is to have it run /bin/sh; thus giving the hacker a root shell with complete control of the system. The other two goals are equally worthy of concern.
| Previous | Table of Contents | Next |