4
ADVANCED APPLICATION TRAFFIC CAPTURE
Usually, the network traffic-capturing techniques you learned in Chapter 2 should suffice, but occasionally you’ll encounter tricky situations that require more advanced ways to capture network traffic. Sometimes, the challenge is an embedded platform that can only be configured with the Dynamic Host Configuration Protocol (DHCP); other times, there may be a network that offers you little control unless you’re directly connected to it.
Most of the advanced traffic-capturing techniques discussed in this chapter use existing network infrastructure and protocols to redirect traffic. None of the techniques require specialty hardware; all you’ll need are software packages commonly found on various operating systems.
Rerouting Traffic
IP is a routed protocol; that is, none of the nodes on the network need to know the exact location of any other nodes. Instead, when one node wants to send traffic to another node that it isn’t directly connected to, it sends the traffic to a gateway node, which forwards the traffic to the destination. A gateway is also commonly called a router, a device that routes traffic from one location to another.
For example, in Figure 4-1, the client 192.168.56.10 is trying to send traffic to the server 10.1.1.10, but the client doesn’t have a direct connection to the server. It first sends traffic destined for the server to Router A. In turn, Router A sends the traffic to Router B, which has a direct connection to the target server; Router B passes the traffic on to its final destination.
As with all nodes, the gateway node doesn’t know the traffic’s exact destination, so it looks up the appropriate next gateway to send to. In this case, Routers A and B only know about the two networks they are directly connected to. To get from the client to the server, the traffic must be routed.
Figure 4-1: An example of routed traffic
Using Traceroute
When tracing a route, you attempt to map the route that the IP traffic will take to a particular destination. Most operating systems have built-in tools to perform a trace, such as traceroute on most Unix-like platforms and tracert on Windows.
Listing 4-1 shows the result of tracing the route to www.google.com from a home internet connection.
C:Usersuser>tracert www.google.com
Tracing route to www.google.com [173.194.34.176]
over a maximum of 30 hops:
1 2 ms 2 ms 2 ms home.local [192.168.1.254]
2 15 ms 15 ms 15 ms 217.32.146.64
3 88 ms 15 ms 15 ms 217.32.146.110
4 16 ms 16 ms 15 ms 217.32.147.194
5 26 ms 15 ms 15 ms 217.41.168.79
6 16 ms 26 ms 16 ms 217.41.168.107
7 26 ms 15 ms 15 ms 109.159.249.94
8 18 ms 16 ms 15 ms 109.159.249.17
9 17 ms 28 ms 16 ms 62.6.201.173
10 17 ms 16 ms 16 ms 195.99.126.105
11 17 ms 17 ms 16 ms 209.85.252.188
12 17 ms 17 ms 17 ms 209.85.253.175
13 27 ms 17 ms 17 ms lhr14s22-in-f16.1e100.net [173.194.34.176]
Listing 4-1: Traceroute to www.google.com using the tracert tool
Each numbered line of output (1, 2, and so on) represents a unique gateway routing traffic to the ultimate destination. The output refers to a maximum number of hops. A single hop represents the network between each gateway in the entire route. For example, there’s a hop between your machine and the first router, another between that router and the next, and hops all the way to the final destination. If the maximum hop count is exceeded, the traceroute process will stop probing for more routers. The maximum hop can be specified to the trace route tool command line; specify -h NUM on Windows and -m NUM on Unix-style systems.(The output also shows the round-trip time from the machine performing the traceroute and the discovered node.)
Routing Tables
The OS uses routing tables to figure out which gateways to send traffic to. A routing table contains a list of destination networks and the gateway to route traffic to. If a network is directly connected to the node sending the network traffic, no gateway is required, and the network traffic can be transmitted directly on the local network.
You can view your computer’s routing table by entering the command netstat -r on most Unix-like systems or route print on Windows. Listing 4-2 shows the output from Windows when you execute this command.
> route print
IPv4 Route Table
=============================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
➊ 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.72 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.72 266
192.168.1.72 255.255.255.255 On-link 192.168.1.72 266
192.168.1.255 255.255.255.255 On-link 192.168.1.72 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.56.1 276
224.0.0.0 240.0.0.0 On-link 192.168.1.72 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.56.1 276
255.255.255.255 255.255.255.255 On-link 192.168.1.72 266
=============================================================================
Listing 4-2: Example routing table output
As mentioned earlier, one reason routing is used is so that nodes don’t need to know the location of all other nodes on the network. But what happens to traffic when the gateway responsible for communicating with the destination network isn’t known? In that case, it’s common for the routing table to forward all unknown traffic to a default gateway. You can see the default gateway at ➊, where the network destination is 0.0.0.0. This destination is a placeholder for the default gateway, which simplifies the management of the routing table. By using a placeholder, the table doesn’t need to be changed if the network configuration changes, such as through a DHCP configuration. Traffic sent to any destination that has no known matching route will be sent to the gateway registered for the 0.0.0.0 placeholder address.
How can you use routing to your advantage? Let’s consider an embedded system in which the operating system and hardware come as one single device. You might not be able to influence the network configuration in an embedded system as you might not even have access to the underlying operating system, but if you can present your capturing device as a gateway between the system generating the traffic and its ultimate destination, you can capture the traffic on that system.
The following sections discuss ways to configure an OS to act as a gateway to facilitate traffic capture.
Configuring a Router
By default, most operating systems do not route traffic directly between network interfaces. This is mainly to prevent someone on one side of the route from communicating directly with the network addresses on the other side. If routing is not enabled in the OS configuration, any traffic sent to one of the machine’s network interfaces that needs to be routed is instead dropped or an error message is sent to the sender. The default configuration is very important for security: imagine the implications if the router controlling your connection to the internet routed traffic from the internet directly to your private network.
Therefore, to enable an OS to perform routing, you need to make some configuration changes as an administrator. Although each OS has different ways of enabling routing, one aspect remains constant: you’ll need at least two separate network interfaces installed in your computer to act as a router. In addition, you’ll need routes on both sides of the gateway for routing to function correctly. If the destination doesn’t have a corresponding route back to the source device, communication might not work as expected. Once routing is enabled, you can configure the network devices to forward traffic via your new router. By running a tool such as Wireshark on the router, you can capture traffic as it’s forwarded between the two network interfaces you configured.
Enabling Routing on Windows
By default, Windows does not enable routing between network interfaces. To enable routing on Windows, you need to modify the system registry. You can do this by using a GUI registry editor, but the easiest way is to run the following command as an administrator from the command prompt:
C> reg add HKLMSystemCurrentControlSetServicesTcpipParameters ^
/v IPEnableRouter /t REG_DWORD /d 1
To turn off routing after you’ve finished capturing traffic, enter the following command:
C> reg add HKLMSystemCurrentControlSetServicesTcpipParameters ^
/v IPEnableRouter /t REG_DWORD /d 0
You’ll also need to reboot between command changes.
WARNING
Be very careful when you’re modifying the Windows registry. Incorrect changes could completely break Windows and prevent it from booting! Be sure to make a system backup using a utility like the built-in Windows backup tool before performing any dangerous changes.
Enabling Routing on *nix
To enable routing on Unix-like operating systems, you simply change the IP routing system setting using the sysctl command. (Note that the instructions for doing so aren’t necessarily consistent between systems, but you should be able to easily find specific instructions.)
To enable routing on Linux for IPv4, enter the following command as root (no need to reboot; the change is immediate):
# sysctl net.ipv4.conf.all.forwarding=1
To enable IPv6 routing on Linux, enter this:
# sysctl net.ipv6.conf.all.forwarding=1
You can revert the routing configuration by changing 1 to 0 in the previous commands.
To enable routing on macOS, enter the following:
> sysctl -w net.inet.ip.forwarding=1
Network Address Translation
When trying to capture traffic, you may find that you can capture outbound traffic but not returning traffic. The reason is that an upstream router doesn’t know the route to the original source network; therefore, it either drops the traffic entirely or forwards it to an unrelated network. You can mitigate this situation by using Network Address Translation (NAT), a technique that modifies the source and destination address information of IP and higher-layer protocols, such as TCP. NAT is used extensively to extend the limited IPv4 address space by hiding multiple devices behind a single public IP address.
NAT can make network configuration and security easier, too. When NAT is turned on, you can run as many devices behind a single NAT IP address as you like and manage only that public IP address.
Two types of NAT are common today: Source NAT (SNAT) and Destination NAT (DNAT). The differences between the two relate to which address is modified during the NAT processing of the network traffic. SNAT (also called masquerading) changes the IP source address information; DNAT changes the destination address.
Enabling SNAT
When you want a router to hide multiple machines behind a single IP address, you use SNAT. When SNAT is turned on, as traffic is routed across the external network interface, the source IP address in the packets is rewritten to match the single IP address made available by SNAT.
It can be useful to implement SNAT when you want to route traffic to a network that you don’t control because, as you’ll recall, both nodes on the network must have appropriate routing information for network traffic to be sent between the nodes. In the worst case, if the routing information is incorrect, traffic will flow in only one direction. Even in the best case, it’s likely that you would be able to capture traffic only in one direction; the other direction would be routed through an alternative path.
SNAT addresses this potential problem by changing the source address of the traffic to an IP address that the destination node can route to—typically, the one assigned to the external interface of the router. Thus, the destination node can send traffic back in the direction of the router. Figure 4-2 shows a simple example of SNAT.
Figure 4-2: An example of SNAT from a client to a server
When the client wants to send a packet to a server on a different network, it sends it to the router that has been configured with SNAT. When the router receives the packet from the client, the source address is the client’s (10.0.0.1) and the destination is the server (the resolved address of domain.com). It’s at this point that SNAT is used: the router modifies the source address of the packet to its own (1.1.1.1) and then forwards the packet to the server.
When the server receives this packet, it assumes the packet came from the router; so, when it wants to send a packet back, it sends the packet to 1.1.1.1. The router receives the packet, determines it came from an existing NAT connection (based on destination address and port numbers), and reverts the address change, converting 1.1.1.1 back to the original client address of 10.0.0.1. Finally, the packet can be forwarded back to the original client without the server needing to know about the client or how to route to its network.
Configuring SNAT on Linux
Although you can configure SNAT on Windows and macOS using Internet Connection Sharing, I’ll only provide details on how to configure SNAT on Linux because it’s the easiest platform to describe and the most flexible when it comes to network configuration.
Before configuring SNAT, you need to do the following:
• Enable IP routing as described earlier in this chapter.
• Find the name of the outbound network interface on which you want to configure SNAT. You can do so by using the ifconfig command. The outbound interface might be named something like eth0.
• Note the IP address associated with the outbound interface when you use ifconfig.
Now you can configure the NAT rules using the iptables. (The iptables command is most likely already installed on your Linux distribution.) But first, flush any existing NAT rules in iptables by entering the following command as the root user:
# iptables -t nat -F
If the outbound network interface has a fixed address, run the following commands as root to enable SNAT. Replace INTNAME with the name of your outbound interface and INTIP with the IP address assigned to that interface.
# iptables -t nat -A POSTROUTING -o INTNAME -j SNAT --to INTIP
However, if the IP address is configured dynamically (perhaps using DHCP or a dial-up connection), use the following command to automatically determine the outbound IP address:
# iptables -t nat -A POSTROUTING -o INTNAME -j MASQUERADE
Enabling DNAT
DNAT is useful if you want to redirect traffic to a proxy or other service to terminate it, or before forwarding the traffic to its original destination. DNAT rewrites the destination IP address, and optionally, the destination port. You can use DNAT to redirect specific traffic to a different destination, as shown in Figure 4-3, which illustrates traffic being redirected from both the router and the server to a proxy at 192.168.0.10 to perform a man-in-the-middle analysis.
Figure 4-3: An example of DNAT to a proxy
Figure 4-3 shows a client application sending traffic through a router that is destined for domain.com on port 1234. When a packet is received at the router, that router would normally just forward the packet to the original destination. But because DNAT is used to change the packet’s destination address and port to 192.168.0.10:8888, the router will apply its forwarding rules and send the packet to a proxy machine that can capture the traffic. The proxy then establishes a new connection to the server and forwards any packets sent from the client to the server. All traffic between the original client and the server can be captured and manipulated.
Configuring DNAT depends on the OS the router is running. (If your router is running Windows, you’re probably out of luck because the functionality required to support it isn’t exposed to the user.) Setup varies considerably between different versions of Unix-like operating systems and macOS, so I’ll only show you how to configure DNAT on Linux. First, flush any existing NAT rules by entering the following command:
# iptables -t nat -F
Next, run the following command as the root user, replacing ORIGIP (originating IP) with the IP address to match traffic to and NEWIP with the new destination IP address you want that traffic to go to.
# iptables -t nat -A PREROUTING -d ORIGIP -j DNAT --to-destination NEWIP
The new NAT rule will redirect any packet routed to ORIGIP to NEWIP. (Because the DNAT occurs prior to the normal routing rules on Linux, it’s safe to choose a local network address; the DNAT rule will not affect traffic sent directly from Linux.) To apply the rule only to a specific TCP or UDP, change the command:
iptables -t nat -A PREROUTING -p PROTO -d ORIGIP --dport ORIGPORT -j DNAT
--to-destination NEWIP:NEWPORT
The placeholder PROTO (for protocol) should be either tcp or udp depending on the IP protocol being redirected using the DNAT rule. The values for ORIGIP (original IP) and NEWIP are the same as earlier.
You can also configure ORIGPORT (the original port) and NEWPORT if you want to change the destination port. If NEWPORT is not specified, only the IP address will be changed.
Forwarding Traffic to a Gateway
You’ve set up your gateway device to capture and modify traffic. Everything appears to be working properly, but there’s a problem: you can’t easily change the network configuration of the device you want to capture. Also, you have limited ability to change the network configuration the device is connected to. You need some way to reconfigure or trick the sending device into forwarding traffic through your gateway. You could accomplish this by exploiting the local network by spoofing packets for either DHCP or Address Resolution Protocol (ARP).
DHCP Spoofing
DHCP is designed to run on IP networks to distribute network configuration information to nodes automatically. Therefore, if we can spoof DHCP traffic, we can change a node’s network configuration remotely. When DHCP is used, the network configuration pushed to a node can include an IP address as well as the default gateway, routing tables, the default DNS servers, and even additional custom parameters. If the device you want to test uses DHCP to configure its network interface, this flexibility makes it very easy to supply a custom configuration that will allow easy network traffic capture.
DHCP uses the UDP protocol to send requests to and from a DHCP service on the local network. Four types of DHCP packets are sent when negotiating the network configuration:
Discover Sent to all nodes on the IP network to discover a DHCP server
Offer Sent by the DHCP server to the node that sent the discovery packet to offer a network configuration
Request Sent by the originating node to confirm its acceptance of the offer
Acknowledgment Sent by the server to confirm completion of the configuration
The interesting aspect of DHCP is that it uses an unauthenticated, connectionless protocol to perform configuration. Even if an existing DHCP server is on a network, you may be able to spoof the configuration process and change the node’s network configuration, including the default gateway address, to one you control. This is called DHCP spoofing.
To perform DHCP spoofing, we’ll use Ettercap, a free tool that’s available on most operating systems (although Windows isn’t officially supported).
On Linux, start Ettercap in graphical mode as the root user:
# ettercap -G
You should see the Ettercap GUI, as shown in Figure 4-4.
Configure Ettercap’s sniffing mode by selecting Sniff ▸ Unified Sniffing.
The dialog shown in Figure 4-5 should prompt you to select the network interface you want to sniff on. Select the interface connected to the network you want to perform DHCP spoofing on. (Make sure the network interface’s network is configured correctly because Ettercap will automatically send the interface’s configured IP address as the DHCP default gateway.)
Enable DHCP spoofing by choosing Mitm ▸ Dhcp spoofing. The dialog shown in Figure 4-6 should appear, allowing you to configure the DHCP spoofing options.
The IP Pool field sets the range of IP addresses to hand out for spoofing DHCP requests. Supply a range of IP addresses that you configured for the network interface that is capturing traffic. For example, in Figure 4-6, the IP Pool value is set to 10.0.0.10-50 (the dash indicates all addresses inclusive of each value), so we’ll hand out IPs from 10.0.0.10 to 10.0.0.50 inclusive. Configure the Netmask to match your network interface’s netmask to prevent conflicts. Specify a DNS server IP of your choice.
Start sniffing by choosing Start ▸ Start sniffing. If DHCP spoofing is successful on the device, the Ettercap log window should look like Figure 4-7. The crucial line is fake ACK sent by Ettercap in response to the DHCP request.
Figure 4-7: Successful DHCP spoofing
That’s all there is to DHCP spoofing with Ettercap. It can be very powerful if you don’t have any other option and a DHCP server is already on the network you’re trying to attack.
ARP Poisoning
ARP is critical to the operation of IP networks running on Ethernet because ARP finds the Ethernet address for a given IP address. Without ARP, it would be very difficult to communicate IP traffic efficiently over Ethernet. Here’s how ARP works: when one node wants to communicate with another on the same Ethernet network, it must be able to map the IP address to an Ethernet MAC address (which is how Ethernet knows the destination node to send traffic to). The node generates an ARP request packet (see Figure 4-8) containing the node’s 6-byte Ethernet MAC address, its current IP address, and the target node’s IP address. The packet is transmitted on the Ethernet network with a destination MAC address of ff:ff:ff:ff:ff:ff, which is the defined broadcast address. Normally, an Ethernet device only processes packets with a destination address that matches its address, but if it receives a packet with the destination MAC address set to the broadcast address, it will process it, too.
If one of the recipients of this broadcasted message has been assigned the target IP address, it can now return an ARP response, as shown in Figure 4-9. This response is almost exactly the same as the request except the sender and target fields are reversed. Because the sender’s IP address should correspond to the original requested target IP address, the original requestor can now extract the sender’s MAC address and remember it for future network communication without having to resend the ARP request.
Figure 4-8: An example ARP request packet
Figure 4-9: An example ARP response
How can you use ARP poisoning to your advantage? As with DHCP, there’s no authentication on ARP packets, which are intentionally sent to all nodes on the Ethernet network. Therefore, you can inform the target node you own an IP address and ensure the node forwards traffic to your rogue gateway by sending spoofed ARP packets to poison the target node’s ARP cache. You can use Ettercap to spoof the packets, as shown in Figure 4-10.
In Figure 4-10, Ettercap sends spoofed ARP packets to the client and the router on the local network. If spoofing succeeds, these ARP packets will change the cached ARP entries for both devices to point to your proxy.
WARNING
Be sure to spoof ARP packets to both the client and the router to ensure that you get both sides of the communication. Of course, if all you want is one side of the communication, you only need to poison one or the other node.
To start ARP poisoning, follow these steps:
Start Ettercap, and enter Unified Sniffing mode as you did with DHCP spoofing.
Select the network interface to poison (the one connected to the network with the nodes you want to poison).
Configure a list of hosts to ARP poison. The easiest way to get a list of hosts is to let Ettercap scan for you by choosing Hosts ▸ Scan For Hosts. Depending on the size of the network, scanning can take from a few seconds to hours. When the scan is complete, choose Hosts ▸ Host List; a dialog like the one in Figure 4-11 should appear.
Figure 4-11: A list of discovered hosts
As you can see in Figure 4-11, we’ve found two hosts. In this case, one is the client node that you want to capture, which is on IP address 192.168.100.1 with a MAC address of 08:00:27:33:81:6d. The other node is the gateway to the internet on IP address 192.168.100.10 with a MAC address of 08:00:27:68:95:c3. Most likely, you’ll already know the IP addresses configured for each network device, so you can determine which is the local machine and which is the remote machine.
Choose your targets. Select one of the hosts from the list and click Add to Target 1; select the other host you want to poison and click Add to Target 2. (Target 1 and Target 2 differentiate between the client and the gateway.) This should enable one-way ARP poisoning in which only data sent from Target 1 to Target 2 is rerouted.
Start ARP poisoning by choosing Mitm ▸ ARP poisoning. A dialog should appear. Accept the defaults and click OK. Ettercap should attempt to poison the ARP cache of your chosen targets. ARP poisoning may not work immediately because the ARP cache has to refresh. If poisoning is successful, the client node should look similar to Figure 4-12.
Figure 4-12 shows the router was poisoned at IP 192.168.100.10, which has had its MAC Hardware address modified to the proxy’s MAC address of 08:00:27:08:dc:e6. (For comparison, see the corresponding entry in Figure 4-11.) Now any traffic that is sent from the client to the router will instead be sent to the proxy (shown by the MAC address of 192.168.100.5). The proxy can forward the traffic to the correct destination after capturing or modifying it.
One advantage that ARP poisoning has over DHCP spoofing is that you can redirect nodes on the local network to communicate with your gateway even if the destination is on the local network. ARP poisoning doesn’t have to poison the connection between the node and the external gateway if you don’t want it to.
Final Words
In this chapter, you’ve learned a few additional ways to capture and modify traffic between a client and server. I began by describing how to configure your OS as an IP gateway, because if you can forward traffic through your own gateway, you have a number of techniques available to you.
Of course, just getting a device to send traffic to your network capture device isn’t always easy, so employing techniques such as DHCP spoofing or ARP poisoning is important to ensure that traffic is sent to your device rather than directly to the internet. Fortunately, as you’ve seen, you don’t need custom tools to do so; all the tools you need are either already included in your operating system (especially if you’re running Linux) or easily downloadable.