BUTTSNIFFER

After all that time spent describing the usefulness of sniffers to administrators, it seems surprising that the first tool in our discussion is called BUTTSniffer. Written by one of the members of the hacker group Cult of the Dead Cow (most famous for their Back Orifice tool, to which BUTTSniffer pays homagesee Chapter 10), BUTTSniffer is a stand-alone, command-line, Windows-based sniffing tool. (You can download it from http://www.packetstormsecurity.com/sniffers/buttsniffer.) It's quite functional but rather complicated to use if you're unfamiliar with the concepts of packet sniffing.

Implementation

The first step in learning how to use sniffers is telling the sniffer what we want to know. We do that through the command line. BUTTSniffer provides a handful of options:

 BUTTSniffer v0.9 (c) 1998, Cult of the Dead Cow Usage: buttsniff -{idl} <arguments>  -i (interactive) arguments: <device number> <port>  -d (disk dump) arguments: <device number> <log file> <dump type> [filter]  -l (list devices) arguments: (none) 

In addition to the options above, BUTTSniffer tells you about the valid dump types and filters (used in conjunction with the d flag) that can be used as arguments. Dump types are specified using a single letter:

• r (raw frames ) Choose this option to dump raw network traffic.

• e (encapsulation) Choose this option to dump decoded packets with encapsulation information.

• p (protocol) Choose this option to dump fully decoded packets along with protocol information.

When performing a protocol dump, you can filter traffic based on a single port number (e.g. 80) or a port range (e.g. 2080). Alternatively, you can specify a filename on the command line (e.g. filter.txt) that contains a list of IP and port filter rules. The syntax of that filter file will be discussed shortly.

BUTTSniffer has three modes: device list, interactive, and disk dump. The device list mode tells you what network interfaces it finds on your machine. Each network interface, even a dial-up adapter, has device numbers assigned to them. In BUTTSniffer's other two modes, you'll need to know the device number of the interface on which you want to sniff traffic, so device list mode is the first step. Interactive and disk dump modes require a bit more explanation and are covered next .

Interactive Mode

We'll start with interactive mode because it's made with the beginner in mind. The command line for interactive mode tells you to specify a device number for the interface you want to monitor and a port number. This number isn't a filter to sniff traffic on a particular port, but the port number on which it binds the sniffing daemon. The interactive mode works by setting up a daemon on the specified port, say 8888 (that is, buttsniff i 0 8888 ). Then connect to that port with Netcat or telnet to use the sniffer. You should see the BUTTSniffer interactive main menu with the following options:

Monitor Connections The Monitor Connections option watches all IP sessions that pass through or by the interface, which is device number 0 from our example command line. We can give it a try by opening up a few web and telnet connections and seeing what happens. Select Monitor Connections and press ENTER.

We can see a telnet and a few web sessions from an IP address. If we scroll up or down to a particular connection, we can monitor the connection. Here we're watching an unencrypted telnet session:

The output is clunky , but if you look carefully , you can see that we've captured the root password on this box: guessme. The user's keystrokes are logged in the bottom section of the screen and the output from the commands is listed in the top section. After the user typed su, he typed in the root password guessme. As we can see from the output in the top section, he successfully became root. At the bottom of the screen, you'll see some display options. Full Screen is particularly useful if you care only about what the user is typing.

Tip 

Remember reading that no one should use telnet anymore? This is why. All your telnet traffic is readable by anyone with a sniffer who can access some part of the communication channel.

Now, to illustrate the importance of using encryption, let's see the exact same activity under an SSH session:

Not quite as useful, is it? Encryption keeps the root password and commands confidential.

Password Sniffer We were able to grab a password in the telnet session using the Monitor Connections option, but the Password Sniffer option looks specifically for login attempts and extracts any username and password it observes. In the following example, the user telnets to originix with the bob account and then switches user ( su ) to root. BUTTSniffer picks up the initial authentication because it's the beginning of the connection, but it won't capture the switch user command. We need the Monitor Connections mode to pick that up. Note that many systems won't let you telnet into a box with the root account, which is why the su command is used so often.

The interactive mode is pretty easy to use, but we're not recording any of this data anywhere . We'll cover the disk dump mode shortly.

Configure What if you were on a system that saw hundreds of network connections at once? How would you be able to sort through all the noise?

This menu option lets you set up filters for the interactive mode. It tells BUTTSniffer to watch only for particular kinds of network traffic to or from particular hosts . It's important that you understand how these filters work, because we'll be specifying them in text files when we get to the Disk Dump mode.

The main purpose of the Configure menu is to turn on the filters, which are similar to the Berkeley Packet Filter (BPF) schema, which we'll cover in the tcpdump section. Notice in the following illustration that we first specify to exclude all IP addresses ( *.*.*.* ) and then include only the host with IP address 192.168.1.100. By default, it includes everyone and everything that it passes to the interface. Before you can specify on which hosts and ports you want to focus, you have to exclude the ones you don't care about.

Two other options are listed here. First, we can choose to monitor only valid TCP connections. Abnormal connections, such as those that nmap stealth scans make when port-scanning a network, will be ignored. The second option, War Mode, is a throwback to the origin of this sniffer as a plug-in for the hacker backdoor suite Back Orifice. Since BUTTSniffer was originally intended to help monitor network traffic on a hacked Windows system, engaging War Mode allows the user to hijack certain network connections and reset them, frustrating users.

Disk Dump Mode

If you want to monitor certain types of activity over a long period of time, use disk dump mode. This mode doesn't have many of the convenience features of the interactive mode, but you gain the power to log the activity to a file in certain formats. This enables you to start the sniffer, leave it running for a day, and then analyze the captured traffic later. Hackers or system administrators might even write scripts to generate reports based on these output files.

As with interactive mode, the command line for disk dump mode requires the device number of your interface (obtained by first running buttsniff -l ) as the first argument. The second argument is the name of the logfile. The third option defines the format of the dump output. If you remember the beginning of the "Implementation" section, there are three possible choices for the dump type: raw ( r ), encapsulation ( e ), and protocol ( p ). Raw and encapsulation are useful only if you have a hex editor and a strong knowledge of the protocol you're sniffing. Most of us will choose to use the protocol option, as it decodes the TCP packets and displays them in an informative, easy-to-read format.

Using the command buttsniff d 1 proto.log p , here's some of the output from a logfile:

 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 0  Source Port: 2111  Target Port: 23  Seq: 0919F2F2  Ack: 00000000 Flags: S  Window: 65535  TCP ChkSum: 64163  UrgPtr: 0 Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length: 0  Source Port: 23  Target Port: 2111  Seq: 7BFD410D  Ack: 0919F2F3 Flags: SA  Window: 32120  TCP ChkSum: 49167  UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 0  Source Port: 2111  Target Port: 23  Seq: 0919F2F3  Ack: 7BFD410E Flags: A  Window: 65535  TCP ChkSum: 27212  UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 3  Source Port: 2111  Target Port: 23  Seq: 0919F2F3  Ack: 7BFD410E Flags: PA  Window: 65535  TCP ChkSum: 19269  UrgPtr: 0  00000000: FF FB 1F                                          . Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length: 0  Source Port: 23  Target Port: 2111  Seq: 7BFD410E  Ack: 0919F2F6 Flags: A  Window: 32120  TCP ChkSum: 60624  UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP Length: 18 Source Port: 2111 Target Port: 23 Seq: 0919F2F6 Ack: 7BFD410E Flags: PA  Window: 65535  TCP ChkSum: 10271  UrgPtr: 0  00000000: FF FB 20 FF FB 18 FF FB 27 FF FD 01 FF FB 03 FF    .'..  00000010: FD 03                                             . 

We've collected quite a bit of information here, so let's break it down a bit.

Every packet has its own log entry. We see from the first packet that 192.168.1.101 has sent a packet to 192.168.1.100 with a target port of 23 (telnet). If we take a look at the flags on this packet, we see that the S , or SYN, flag is set. The SYN flag indicates the initiation of a TCP connection. The next line shows a response from 192.168.100 back to 192.168.1.101's target port (2111, in this case) with the SA , or SYN/ACK, flag set. The next line is from 192.168.1.101 and shows a packet with the A , or ACK, flag set. This is the TCP three-way handshake used to establish a connection.

We've clearly caught the beginning of a telnet connection between these hosts. None of the handshake packets have any data beyond the TCP headers. If we look further down the list, we see a hex and ASCII dump of the TCP packets' data field. Before telnet presents the login prompt, the client and server negotiate some options, such as the terminal type. We look past the uninteresting negotiation to find some more valuable information:

 Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length: 7  Source Port: 23  Target Port: 2111  Seq: 7BFD418A  Ack: 0919F33F Flags: PA  Window: 32120  TCP ChkSum: 35305  UrgPtr: 0  00000000: 6C 6F 67 69 6E 3A 20                              login: Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 0  Source Port: 2111  Target Port: 23  Seq: 0919F33F  Ack: 7BFD4191 Flags: A  Window: 65404  TCP ChkSum: 27136  UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 1  Source Port: 2111  Target Port: 23  Seq: 0919F33F  Ack: 7BFD4191 Flags: PA  Window: 65404  TCP ChkSum: 2039  UrgPtr: 0  00000000: 62                                                 b Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length:1  SourcePort:23  TargetPort:2111  Seq:7BFD4191  Ack:0919F340? Flags: PA  Window: 32120  TCP ChkSum: 35322  UrgPtr: 0  00000000: 62                                                 b Source IP: 192.168.1.101  Target IP: 192.168.1.100?TCP  Length: 1  Source Port: 2111  Target Port: 23  Seq: 0919F340  Ack: 7BFD4192 Flags: PA  Window: 65403  TCP ChkSum: 64245  UrgPtr: 0  00000000: 6F                                                 o Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length: 1  Source Port: 23  Target Port: 2111  Seq: 7BFD4192  Ack: 0919F341 Flags: PA  Window: 32120  TCP ChkSum: 31992  UrgPtr: 0  00000000: 6F                                                 o Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP  Length: 1  Source Port: 2111  Target Port: 23  Seq: 0919F341  Ack: 7BFD4193 Flags: PA  Window: 65402  TCP ChkSum: 2037  UrgPtr: 0  00000000: 62                                                 b Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP  Length: 1  Source Port: 23  Target Port: 2111  Seq: 7BFD4193  Ack: 0919F342 Flags: PA  Window: 32120  TCP ChkSum: 35318  UrgPtr: 0  00000000: 62                                                 b 

192.168.1.101 was presented with a login prompt. If we focus on the packets coming from source 192.168.1.101 headed to target 192.168.1.100, we see that the user typed b-o-b . Each time 192.168.1.101 sent a character, 192.168.1.100 echoed it back. The telnet server acknowledges receipt of our characters by echoing the keystroke. Otherwise, nothing we typed would be displayed in the client. The telnet protocol immediately sends keystrokes to the server instead of buffering them in the client.

If we look down a little further, we'll find the really useful information:

 SourceIP:192.168.1.100  TargetIP:192.168.1.101 TCP  Length:10  SourcePort:23  TargetPort:2111  Seq:7BFD4196  Ack:0919F344 Flags:PA  Window:32120  TCPChkSum:1056  UrgPtr:0  00000000:50617373776F72643A20                          Password: SourceIP:192.168.1.101  TargetIP:192.168.1.100 TCP  Length:0  SourcePort:2111  TargetPort:23  Seq:0919F344  Ack:7BFD41A0 Flags:A  Window:65389  TCPChkSum:27131  UrgPtr:0 SourceIP:192.168.1.101  TargetIP:192.168.1.100 TCP  Length:1  SourcePort:2111  TargetPort:23  Seq:0919F344  Ack:7BFD41A0 Flags:PA  Window:65389  TCPChkSum:2034  UrgPtr:0  00000000:62                                            b SourceIP:192.168.1.100  TargetIP:192.168.1.101 TCP  Length:0  SourcePort:23  TargetPort:2111  Seq:7BFD41A0  Ack:0919F345 Flags:A  Window:32120  TCPChkSum:60399  UrgPtr:0 SourceIP:192.168.1.101  TargetIP:192.168.1.100 TCP  Length:1  SourcePort:2111  TargetPort:23  Seq:0919F345  Ack:7BFD41A0 Flags:PA  Window:65389  TCPChkSum:64240  UrgPtr:0  00000000:6F                                            o SourceIP:192.168.1.100  TargetIP:192.168.1.101 TCP  Length:0  SourcePort:23  TargetPort:2111  Seq:7BFD41A0  Ack:0919F346 Flags:A  Window:32120  TCPChkSum:60398  UrgPtr:0 SourceIP:192.168.1.101  TargetIP:192.168.1.100 TCP  Length:1  SourcePort:2111  TargetPort:23  Seq:0919F346  Ack:7BFD41A0 Flags:PA  Window:65389  TCPChkSum:2032  UrgPtr:0  00000000:62                                            b SourceIP:192.168.1.100  TargetIP:192.168.1.101 TCP  Length:0  SourcePort:23  TargetPort:2111  Seq:7BFD41A0  Ack:0919F347 Flags:A  Window:32120  TCPChkSum:60397  UrgPtr:0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP Length: 1 Source Port: 2111 Target Port: 23 Seq: 0919F347     Ack: 7BFD41A0 Flags: PA Window: 65389 TCP ChkSum: 14575    UrgPtr: 0  00000000: 31                                               1 Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP Length: 0 Source Port: 23 Target Port: 2111 Seq: 7BFD41A0     Ack: 0919F348 Flags: A Window: 32120 TCP ChkSum: 60396    UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP Length: 1 Source Port: 2111 Target Port: 23 Seq: 0919F348     Ack: 7BFD41A0 Flags: PA Window: 65389 TCP ChkSum: 14318    UrgPtr: 0  00000000: 32                                               2 Source IP: 192.168.1.100  Target IP: 192.168.1.101 TCP Length: 0 Source Port: 23 Target Port: 2111 Seq: 7BFD41A0     Ack: 0919F349 Flags: A Window: 32120 TCP ChkSum: 60395    UrgPtr: 0 Source IP: 192.168.1.101  Target IP: 192.168.1.100 TCP Length: 1 Source Port: 2111 Target Port: 23 Seq: 0919F349     Ack: 7BFD41A0 Flags: PA Window: 65389 TCP ChkSum: 14061    UrgPtr: 0  00000000: 33                                               3 

Looks like we've sniffed bob's attempt at a clever password. Again, by focusing only on the packets coming from source 192.168.1.101 to target 192.168.1.100, we see the user typed b-o-b-1-2-3 . Notice how the acknowledgment packets from the telnet server don't echo the input, as happened with the username. This is expected, because we don't see our password printed on the telnet screen when we type it in.

Just as BUTTSniffer's interactive mode has filters, the disk dump mode has an optional filter file that can be specified at the end of the command line. The file uses the same technique as the interactive menu. An empty filter file tells BUTTSniffer to log everything. If you want to focus on a specific IP or port, you must first exclude everything else.

Here's the syntax of a filter file that sets up the same filter we set up in interactive mode:

 -*.*.*.* +192.168.1.100 --0-65535 +23 +80 

It's pretty straightforward. It says to exclude all IP addresses but 192.168.1.100. It then says to exclude all ports except 23 and 80. Save this text as myfilter.fil or whatever you please , and then run the command buttsniff d 1 sniff.log p myfilter.fil to sniff only telnet and web activity to and from 192.168.1.100.

Tip 

If you don't need to filter on an IP but need to filter a port, you don't need to create a filter file. You can simply replace myfilter.fil in this example with a single port number or a port range, such as buttsniff d l sniff.log p 23 . If you want to specify multiple ports not in a range, you'll still need to use the filter file.