NEMESIS: PACKET-WEAVING 101
| | ||
Nemesis is a tool for creating custom IP packets. Unlike isic and iptest, which automatically generate good and bad packets, nemesis can alter any portion of the packet. It is based on libnet, but it's easier to use than libnet or libpcap because it does not require any socket-level manipulation. Instead of writing and debugging C programs, you can quickly whip up a shell script. You only need to specify the data content on the command line; nemesis creates and sends the packet.
Nemesis has experienced quite a positive change in the last year with new development efforts. The primary developer has changed from Mark Grimes to Jeff Nathan. The code and command-line interface have changed as well. Another benefit is that Windows users can compile the source and execute nemesis. You can obtain the source tarball from the Source Forge project page at http://nemesis. sourceforge .net/.
Implementation
The only catch to using the newer nemesis is that its updated code has not tracked the updated versions of libnet. Most modern Linux distributions include the libnet-1.1 series, but nemesis adamantly requires libnet-1.0.2a (for Unix and Windows). You can get around this by compiling libnet-1.0.2a in a separate location and passing the correct configure directives when you compile nemesis. For example,
$ ./configure \ --with-libnet-includes=/usr/local/src/Libnet-1.0.2a/include \ --with-libnet-libraries=/usr/local/src/Libnet-1.0.2a/lib
If you take this approach, make sure that the libnet-config defines command in your path reports the following:
$ libnet-config --defines -D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD --DHAVE_NET_ETHERNET_H --DLIBNET_LIL_ENDIAN
If LIBNET_LIL_ENDIAN or LIBNET_BIG_ENDIAN does not appear, make sure the libnet-config script from the libnet-1.0.2a directory is in your path. After completing these steps, the install process is simple and you will be able to execute the binary:
$ nemesis NEMESIS -=- The NEMESIS Project Version 1.4 (Build 26) NEMESIS Usage: nemesis [mode] [options]
The nemesis package generates packets and packet data for ARP, DNS, Ethernet, ICMP, IGMP, IP, RIP, TCP, and UDP (OSPF remains out of commission). Each protocol is accessed by supplying the appropriate protocol name for [mode]. For example, nemesis dns handles packet creation for DNS packets whereas nemesis tcp handles packet creation for TCP traffic. You can perform general network debugging and testing with the TCP and UDP modes. The other tools are tailored for more specific protocol or service tests.
It takes awhile to get started crafting packets with nemesis, but once you have the framework down, making small changes is simple. Each of the nemesis tools requires the basic IP options. Each of the tools supports the options listed in Tables 19-5 and 19-6.
| IP Mode Option | Description |
|---|---|
| -S | Source IP address. |
| -D | Destination IP address. |
| -I | IP ID value. |
| p | Protocol number. |
| -T | TTL value. |
| -t | Type of service flag. |
| -F<offset> | Fragmentation option flags: |
| -O | Options file. Use a file to make it easier to reuse option values. |
| -P | Payload file. Use a file to make it easier to include binary data. |
| Data Link Option | Description |
|---|---|
| -d | Ethernet device to use for packet transmission. This is the human-friendly name such as eth0 or de0. |
| -H | Source MAC hardware address with which to create the packet. |
| -M | Destination MAC hardware address with which to create the packet. |
| -Z | Use this to determine the local interfaces available on the system. |
TCP mode can be particularly useful when putting together replay attacks based on packets you have sniffed from the network. For example, to spoof a TCP session you need to know not only the peer IP addresses and port numbers, but also the sequence (SEQ) and acknowledgment (ACK) numbers . Thus, you can craft any part of the TCP three-way handshake. Nemesis tcp supports these TCP-specific options:
TCP options: [-x <Source Port>] [-y <Destination Port>] -f <TCP flags> -fS (SYN), -fA (ACK), -fR (RST), -fP (PSH), -fF (FIN), -fU (URG), -fE (ECE), -fC (CWR) -w <Window Size> -s <SEQ Number> -a <ACK Number> -u <Urgent pointer offset> -o <TCP options file> -P <Payload File>
| Tip | Place TCP flag options ( -f ) before port options ( -x , -y ). Otherwise, the flags may not be honored properly. |
UDP mode understandably supports fewer options. Notice that UDP, as a connectionless and stateless protocol, does not provide as many options as TCP. Some uses could be smart port scanning for UDP services, such as SNMP, by using the P option to craft a particular packet.
UDP options: [-x <Source Port>] [-y <Destination Port>] -P <Payload File>
| Note | Check out the Case Study at the end of this section for an example of generating an SNMP packet. |
It is probably overkill to use nemesis icmp to create Ping packets, but any type of ICMP packet can be made quite easily:
ICMP options: -i <ICMP type> -c <ICMP code> -s <ICMP sequence number> -m <IP address mask for ICMP address mask> -G <Preferred gateway IP address for ICMP redirect> -e <ICMP ID> -P <Payload file> -q <ICMP injection mode> -qE echo, -qM mask, -qU unreach, -qX time exceeded, -qR redirect, -qT timestamp ICMP timestamp options: -o <Time ICMP timestamp request was sent> -r <Time ICMP timestamp request was received (for reply)> -a <Time ICMP timestamp request reply was transmitted> ICMP original datagram options: -B <Original source IP address> -b <Original destination IP address> -p <Original IP protocol> -f <Original IP fragmentation offset> -j <Original IP TOS> -J <Original IP TTL> -l <Original IP options file>
The multitude of ICMP mode options makes this part of the tool more useful for verifying that a firewall blocks all ICMP traffic, not just echo-request and echo-reply packets.
One useful way to use nemesis to test firewall configurations with the UDP and TCP modes is to precraft packets as part of a shell script. This attack computer injects packets into one side of the firewall. A computer running tcpdump on the other side of the firewall would monitor the packets that pass through. One way to keep track of the type of packets sent (bad headers, overlapping fragments, and so on) is to use unique IPID field numbers.
One of a good firewall's features is the ability to open and close ports dynamically for single TCP connectionsalso known as stateful inspection in marketing lingo. You can use nemesis to test the statefulness of your firewall's ruleset. This can be an important test to prevent packet-spoofing attacks. For example, you can test a rule that permits NetBIOS traffic (TCP port 139) only between two hosts : 10.0.0.27 and 192.168.0.90.
When the connection begins, 192.168.0.90 sends a TCP SYN packet from port 1066 to 10.0.0.27 on port 139. Here's a partial tcpdump capture of the initial traffic:
19:34:48.663980 192.168.0.90.1066 > 10.0.0.27.139: S 847815674:847815674(0) win 16384 <mss1460,nop,nop,sackOK> (DF) 19:34:48.664567 10.0.0.27.139 > 192.168.0.90.1066: S 4141875831:4141875831(0) ack 847815675 win 17520 <mss 1460,nop,nop,sackOK> (DF) 19:34:48.665586 192.168.0.90.1066 > 10.0.0.27.139: . ack 1 win 17520 (DF)
At this point, the firewall permits traffic using the IP address and port combination used to establish the connection. Subsequent TCP packets carry the ACK ( acknowledge ) flag until the connection is closed by a FIN (finish) or RST (reset) flag. This is where you test the firewall with nemesis tcp.
The first test is to determine whether the firewall allows an arbitrary packet carrying a FIN or RST flag:
# nemesis tcp -S 192.168.0.90 -D 10.0.0.27 -fF -x 1066 -y 139 # nemesis tcp -S 192.168.0.90 -D 10.0.0.27 -fR -x 1066 -y 139
Of course, you'll need to be running tcpdump on the other side of the firewall (on the 10. x network) to see whether the packets pass through the ruleset. The firewall should block these packets because the TCP sequence numbers are incorrect (nemesis assigns them randomly ). If these packets were permitted by the firewall, a DoS attack could be performed against 10.0.0.27 by flooding it with RST packetsno valid connections would ever be maintained !
Next, you'll see how the firewall handles ACK packets. Some hacker backdoor tools tunnel communication entirely over these packets (check out AckCmd from http://ntsecurity.nu or the stcpshell covert communication tool in Chapter 10).
# nemesis tcp -S 192.168.0.90 -D 10.0.0.27 -fA -x 1066 -y 139
The same could be done for UDP connections. Because of the unreliable nature of UDP, firewalls tend to apply time limits on inactivity once a UDP connection has been established. You can verify the firewall's time limit with the nemesis udp tool. You'll use the same scenario you used earlier, but test UDP port 135 (also used for NetBIOS traffic). First, establish a connection between 192.168.0.90 and 10.0.0.27; Netcat works fine. Then run the following command to test a five-minute timeout. The sleep command takes a number of seconds as an argument; 300 seconds equals five minutes.
# sleep 300; nemesis udp -S 192.168.0.90 -D 10.0.0.27 -x 1066 -y 135
Now run a tcpdump on the other side of the firewall. If your tcpdump session catches the UDP traffic, the traffic from nemesis udp has crossed the firewall. This implies that the firewall's timeout period is probably longer than five minutes.
Finally, you can also test to see how the firewall might react to ICMP tunneling programs such as Loki (see Chapter 10). For example, a firewall should never allow an ICMP reply when an ICMP request (generated by the Ping tool, for example) did not originate from an internal IP address:
# nemesis icmp -S 192.168.0.90 -D 10.0.0.27 -i 0 -c 0
You could also test all potential 255 ICMP types (although only about 40 actually exist) to see whether the firewall knows how to handle certain values. Hope-fully, it blocks the packet by default, rather than permitting it to enter the 10. x network.
#!/bin/sh TYPE=0 while [ $TYPE -le 255 ] ; do nemesis icmp -S 192.168.0.90 -D 10.0.0.27 -i $TYPE -c 0 TYPE=`expr $TYPE + 1 ` done
Finally, you could try a final test to monitor how the firewall handles SNMP GET requests . The following technique would also be handy for a more accurate method of port scanning for SNMP services. A normal UDP scan sends a blank packet to port 161 and waits for the SNMP service to respondwhich it may not do since the packet was incorrect. In this case, you actually send a complete SNMP request. First, you need to create the payload file that contains the UDP data. Use a network sniffer to capture SNMP traffic to have reference packets (see Chapter 16). Our Perl script has the SNMP GET request for the "public" community string. The numbers in bold represent the string public in hexadecimal notation:
#!/usr/bin/perl # snmp.pl # mps - Generate data for an SNMP GET "public" $snmp = "302c02010004067075626c6963a01f020426805d1e0201" . "000201003011300f060b2a8648ce340301020102010500"; print pack("H*", $snmp); Next, create a payload file and run nemesis udp:
$ ./snmp.pl > snmp.payload $ nemesis udp -S 192.168.0.179 -D 192.168.0.241 -x 2001 -y 161 -P snmp.payload
This sends an SNMP GET request from port 2001 on 192.168.0.179 to port 161 on 192.168.0.241. We'll need to use tcpdump to watch for the answer:
$ tcpdump -n udp
This technique for "nudging" SNMP services can be applied to many binary protocols that respond only to specific triggers. However, instead of going through a series of services and manually crafting all of the triggers, first check out the THC-Amap utility from http://www.thc.org/releases.php (also in Chapter 4). You can either use Amap, or simply take the triggers from its appdefs.trig file and use them as payload options for UDP and TCP modes of nemesis. For example, you can find Microsoft Remote Desktop servers with this nudge string:
0x03 00 00 0b 06 e0 00 00 00 00 00
Store these as raw hexadecimal values in a file, and you have a simple RDP scanner.
#!/usr/bin/perl # rdp.pl # mps -- Generate data for an RDP handshake print pack("H*", "0300000b06e00000000000"); Then use nemesis to search for RDP servers:
$ nemesis tcp -S 192.168.0.179 -D 192.168.0.241 -x 2001 -y 3389 \ -P rdp.payload
Once again, you will need tcpdump to watch for responses from the server. Nemesis is designed only to inject packets, not monitor for them. You could even reverse the process and craft a custom packet with nemesis, and then capture the binary data with tcpdump to obtain an "egg" or payload to use in vulnerability checking programs.
| | ||
EAN: 2147483647
Pages: 175