Tracing the Path of Activity Can Be Difficult continue…

Posted by arlene

Still, this seems to be something that an IDS can track. As long as a path can be found from the source buffer to the final memory storage location written to the socket, the IDS will be able to detect that data has been compromised. Before you get another cup of coffee or tea, consider a more complex scenario. The daemon’s first two steps are the same as before. Instead of transforming or copying the buffer as the next step, the daemon follows an algorithm.

1. Grab the first byte of the buffer and store it as an integer in temporary variable X.
2. Compute the Xt^h Fibonacci number and write it to the socket.
3. Your program reads the socket and computes Fibonacci numbers until you find the same result, and now you know X.

This is really getting hard. Of course, you could have picked a more efficient algorithm. The point is that the path is getting harder to follow. The compromised data is becoming more obscured. Now instead of the path being based on memory copies and elementary transformations, all we know is that part of the buffer was used in computing some function f(x). The result of the function then was written to the buffer. There is more to consider before drawing some conclusions:

1. Grab the first bit of the buffer and store it in temporary variable X.
2. If X=1, write an odd number to the socket, else write an yen number to the socket.
3. Your program reads the socket and inverts the previous step.

In this case, the action the daemon took by inspecting the buffer indicates a problem, and not the fact that the buffer itself or some derivative of it was communicated to your program. This is a simple case of a covert channel. Anytime one program can leak at least one bit of information to another program, there is a threat that a read constraint will be violated. Any number of operations not related to the socket could have been performed to leak the bit of information contained in X:

The daemon could create a file in directory A that is readable by your program when X=1, and create a file in directory B otherwise (where B also is readable by you).

The daemon could write data into a file that you are allowed to read. Then the daemon reads data back from this file into a buffer. The buffer then is written to the socket for you to read. The IDS would not know, without detailed knowledge of the file’s history, whether the data sent to you was allowed or not. Note that an MLS OS will not permit this operation because it does not allow write down when the operation violates sensitivity labels.

If X=1, the daemon runs the /bin/true program, else it runs /bin/ls.

In other words, the daemon can perform a number of different sets of two different actions to leak information to your program.

You’re not done with extending this line of reasoning yet. What happens if the daemon is listening to any number of sockets simultaneously? The daemon reads data values Y from N different sockets, reads X from the privileged file, and then it computes some function f(X,Y₁, Y₂,.. Y_N)• After this, the daemon returns this value to your socket. Beforehand, you and the daemon signed a pact agreeing on the algorithm so that you can invert the data received on the socket. All of the Y values are meaningless except for yours.

The problem here is that the leaked data is getting more obscure. To make it worse, assume that there are some legitimate f(X,Y₁, Y₂,… Y_N) computations that the daemon sends to you, those which do not leak information about the privileged file. With this slight twist, the IDS will really have a difficult time distinguishing between legitimate and intrusive behavior. Some theory-minded people would look at this last case and start mumbling terms like intractable. In practical terms’ the examples indicate that the more indirection an attacker can introduce into the intrusion, the harder it is to find the path that identifies the events as intrusive.

Taking a few steps back, what happens if your program and the daemon are running on different systems? In this case, the IDS needs information from two systems to keep a path of identity and activities. If the path you took to obtain a login shell traversed several intermediate nodes, then each of these also would need to report activities to a central IDS monitor in order to maintain the path. Tracking activities across multiple systems is challenging. The Distributed Intrusion Detection System (Snapp et al., 1991) was a research system that tried to solve this problem. When you log in into a system, your UID represents who you are. To preserve your activities across UID transitions, the OS assigns an AUID to you. If you run a SUID root program, your AUID does not change. Therefore, auditing can assign accountability for behaviors.

The same type of immutable ID is needed for tracking activities across a network of nodes. DIDS assigned a network ID to the user when the first login event for that user occurred in the network. This assignment was actually made in a batch fashion when the audit logs were processed, but it easily could have been accomplished in real time. DIDS tracked users as they jumped across systems using remote commands. However, it did not track communications activities, such as socket data contents, to find complex attacks such as the scenarios just discussed. No commercial products can detect interprocess hacks in a general way, although some specific attacks are monitored. For example, Ping of Death is an a example of a client-server socket data flow that launches an attack. No commercial product claims an attack signature for detecting when a remote user accesses a local process via a socket and then reads privileged information through that socket.

Is this series of examples really intrusion detection? Well, if the file being read happens to be the shadow password file, the end result is no different from when a user manages to read encrypted passwords via a buffer overflow attack. As hackers get more sophisticated, complicated threats like the ones discussed will increase. The key to success for an IDS is to determine that a path exists. The path must reflect knowledge about data and actions to be useful for detecting intrusions. Success requires tracing this path through a variety of activities on the system.

If you are an intruder who gains privilege in order to read privileged files, you can bet that most IDSs will report that as an event. The more complicated scenarios in this article are not handled by commercial products today. The reason is that enough data is not available to the IDS. To detect sequences, such as those presented in this article, the IDS needs access to memory locations used by the program as well as very detailed information on instructions executed by the CPU for that program. Not only is the level of detail minute, but for the OS to provide this much information, it would need to emit an auditable event for almost every CPU instruction. If one were really paranoid about covert channel leaks, every CPU instruction and its parameters would need tribe logged. This means that each CPU instruction requires several other instructions for writing the audit log. It doesn’t take a genius to see that in this degenerate case, intrusion detection dominates the system’s resources.

Note that in these examples the daemon is essentially an application running on top of the OS, although it has not introduced its own security model (its own subjects and objects). Interprocess communication between programs on the same system is one place where a boundary occurs—between the two endpoints of the session. At a given moment in time, either half of the session is performing services for the other half. When this happens, it is imperative that appropriate security be enforced. As you have seen in previous sections, lax programming practices can lead to problems.

Possibly related posts: (automatically generated)
Tracing the Path of Activity Can Be Difficult continue…

• Tracing the Path of Activity Can Be Difficult
• E-mail Marketing
• Tracking Other Users
• Website Designing and Enhancements
• Avoiding Blooper 28
• Should You Continue to Use Windows 2000 Professional or Move to Windows XP Professional?
• Security Facilities in Java
• Basic Computer Security
• WEP
• Some Issues in Deploying Wireless Systems Network