Securebits Blog

In this entry, I will sum up the ways to intercept (or hijack) network traffic; also, I’ll categorize these ways based on the scope of the interception method. There are more than 10 ways to intercept network traffic – and the TCP/IP protocols used in these methods are ARP, ICMP, DHCP, HSRP, STP, DNS, and BGP. Based on the TCP/IP layer of operation, the 10 ways can be divided into two categories:

1- Layer2 Interception:
Layer2 Interception works by manipulating (e.g. spoofing or faking) addresses at the Layer 2, i.e. the MAC addresses. The attacker (who is trying intercept traffic) tries to cause abnormal behavior at the Layer 2 of the network. The protocols that fall into this category are ARP and STP.

2- Layer3 Interception:
Layer3 Interception works by manipulating (e.g. spoofing or faking) addresses at the Layer 3, i.e. IP addresses. This can be done through routing protocols, spoofing gateways, IP traffic redirection, and so on.

And based on the scope of the interception, the methods can be divided into another two categories:

1- Local:
The impact of an interception method is said to be “local” when the attacker is able only to intercept traffic within the local subnet. The method in this category cannot be used beyond that subnet. Methods that achieve “local” interception can be either Layer2 or Layer3 method. A layer2 method is like ARP or STP; and a layer3 method is like DHCP.

2- Global:
When the attacker is able to intercept traffic beyond the local subnet, i.e. over a LAN or WAN, the interception is called “global.” Global methods can also work locally within the subnet; however, they are not restricted to that local scope.

Here are the best ways for Traffic Interception:

• ARP Poisoning
The attacker poisons the ARP-Cache of two or more victims; a victim can be a host or a router/gateway. ARP poisoning injects false entries that map the victims’ IP addresses to the MAC address of the attacker. ARP poisoning is a “layer2” method and its scope is “local”

• ICMP Redirect
In the standard TCP/IP implementation, the default gateway can send an ICMP Redirect message to a host in the local subnet instructing it to send future IP packets to a different router. The attacker can exploit this feature by sending a spoofed ICMP Redirect message to the host to send the packets to the attacker’s machine. The attacker would, then, forwards those packets to the legitimate default gateway. This interception method works at “layer3” and its impact is “local.”

• DHCP Spoofing
One of the parameters that the DHCP server passes dynamically to LAN hosts is the default gateway IP address. An attacker can setup a rogue DHCP server in a subnet that responds to DHCP requests. The attacker sets the parameter of the “default gateway” to her machine’s IP address. Local hosts would then all traffic destined beyond the local subnet to the attacker’s machine which in turns forwards such traffic to the legitimate default gateway. This interception attacks works at “layer3” and its impact is “local.”

• HSRP “Active”
Hot Standby Router Protocol (HSRP) is developed by Cisco Systems to provide router redundancy. Two routers would be configured in an active-standby mode using a virtual IP address. These two routers send HSRP packets frequently between them to decide who is active and who is standby. HSRP uses clear-text authentication string. An attacker can sniff the string and inject specially crafted HSRP packets that disrupt the current router state and dictate her system as the active router. By doing so, she will receive all traffic from the local subnet destined to the outside world. This attack works at “layer3” and its impact is “local.”

• STP “Root”
To prevent single-point of failure, administrators may deply redundant switches on the network so that in case one switch fails, traffic is ensured to pass through the network. The protocol that enables switches to decide which “path” is active at a specific time is called Spanning Tree Protocol (STP). It is a layer2 protocol that uses the MAC addresses of the switches. An attacker within a local subnet could become part of the switch topology and can also become the root of the topology. In this case, traffic within the local subnet will be directed to the attacker’s machine. Intercepting traffic by spoofing STP is a layer2 method and its impact is “local.”

• Browser Proxy
Web browsers can be configured to use a proxy server. All web traffic initiated by the browser will be sent to the proxy server. If the attacker can successfully alter the proxy configuration of the victim’s browser, she would receive the web traffic. Altering proxy configuration can be made using a malicious script, for example. This is a layer3 method and its impact is “global.”

• IE6 Proxy Auto-Config
Internet Explorer (v6 & v7) can automatically discover “proxy server” on the LAN using Web Proxy Auto-Discovery Protocol (WPAD). If WPAD is enabled, the browser tries to connect to a host with the name “WPAD” (it should be resolvable by either DNS or NetBIOS) and download the JavaScript file wpad.dat. The file instructs the browser which proxy server to use. An attacker who can insert a system with the name “WPAD” in the network would be able to influence the user’s browser to use a proxy server under her control; thus, intercepting network traffic. This is a layer3 attack and its impact is “global”

• DNS Spoofing
DNS Spoofing could be performed in two ways: either the attacker would reply directly to a DNS request issued by a client or he would inject a false entry into a DNS server. The first way can be done only within a local subnet since the attacker has the ability to sniff the request along with its Transaction ID (TXID). The second way can be done over the LAN or Internet; and there are various techniques for that (many of which have been fixed). After a successful DNS spoofing, the attacker can intercept traffic between the client (the victim) and the site/server of which the IP has been spoofed. Intercepting traffic using DNS Spoofing is always a Layer3 method, however the impact can be either “local” or “global.”

• BGP Spoofing
At Defcon 16, Anton Kapela and Alex Pilosov demonstrated a new way to hijack Internet traffic by inserting fake BGP entries. The attack is based on the fact that there is no proper “identification” of the source that is registering new Autonomous Systems and Internet routes. This method works at layer3 and its impact is “global.”

Recently, I was thinking about the current status of DHCP security and whether a new DHCP attack can be created. In fact, I am almost confident that a new extended version of the available exhausting attack is feasible. The current DHCP exhausting attack can only be performed against the DHCP pool assigned to the particular subnet/VLAN where the attacker resides. However, what I call Extended Exhausting Attack can be performed against ALL the address pools configured on a DHCP server. I have not tested this practically; so, the following explanation is merely theoretical – I will do a practical experiment later in the near future.

To understand the traditional exhausting attack and the extended exhausting, we need to understand how DHCP functions in case the DHCP server is located locally within the subnet of the client and in case the DHCP server is located outside the subnet. From the client view, the operation is the same, however, from the server view, it differs.

The DHCP process by which a client gets auto IP-configuration is called the D.O.R.A. process [Discover, Offer, Request, and Acknowledgment.] In short, if the DHCP server is located in the same subnet as the client, the four steps of this process are as follows:

1- DISCOVER: the client sends a DISCOVER message. The source IP is 0.0.0.0 and the destination IP is 255.255.255.255; the source MAC is the MAC address of the client and the destination MAC is FF:FF:FF:FF:FF:FF. The purpose of this message is to declare that the client wants to know the available DHCP server.

2- OFFER: If there is a DHCP server within the same subnet, the server responds with an OFFER message. This is a unicast packet: the source IP is the IP address of the server and the destination IP is the IP address which the server would like to assign to the client. The source MAC is the MAC address of the server and the destination MAC is the MAC address of the client. Also, the OFFER message contains all other IP settings, like subnet mask, default gateway, DNS server, WINS servers, etc.

3- REQUEST: The client then issues a REQUEST message confirming its acceptance of the offered settings. This message contains the same IP and MAC addresses of the DISCOVER message. It is a broadcast message at both Layer 2 and Layer 3.

4- ACKNOWLEDGMENT: Finally, the server sends an ACK message to the client and the client now is eligible to use the offered settings. This message contains the same IP and MAC addresses of the OFFER message.

However, if the DHCP server is located in a different subnet/VLAN, there is the introduction of “DHCP Relay Agent”; usually, the router/gateway assumes the functionality of the DHCP Relay Agent in modern LANs. From the client perspective, the D.O.R.A process is exactly the same; however, in the OFFER and ACK messages, the field “Relay Agent IP Address” is filled with the IP address of the router/gateway. Also, the field “Next Server IP Address” in the OFFER message is filled with the IP address of the DHCP server. The role of the Relay Agent is to be a link between the client and the server as follows:

1- When the client sends a broadcast DISCOVER message, the Relay Agent catches it and sends another DISCOVER message to the DHCP server; however, this second DISCOVER message is unicast. The source IP is the IP address of the Relay Agent and the destination IP is the destination IP of the server.

2- The server sends a unicast OFFER message to the Relay agent. Upon receiving it, the Relay Agent forwards the OFFER to the client.

3- The Relay Agent again picks the broadcast REQUEST message sent by the client. Then, it sends another unicast REQUEST message to the server.

4- The server sends a unicast ACK to the Relay Agent which forwards this ACK to the client.

Traditional exhausting attack involves exploiting the D.O.R.A process to get all the IP addresses in the pool. By repeating the D.O.R.A process with different MAC addresses, the server will release all IP addresses configured in the pool. For example, if an attacker is located inside 10.10.10.0/24 subnet, he can exhaust all the IP addresses in the pool designated for that particular subnet. New systems introduced to the 10.10.10.0/24 subnet cannot get their auto IP configuration since the server has run out of IP addresses.

This well-known attack can only target the pool allocated to the subnet in which the attacker resides. Let’s assume this example: a corporate LAN with a DHCP server 10.1.0.74, and multiple subnets/VLANS 10.1.11.0/24, 10.1.12.0/24, 10.1.13.0/24, …, 10.1.20.0/24. Each VLAN has a designated pool in the DHCP server. If the attacker resides in 10.1.13/24 subnet, he can only exhaust the pool associated with that subnet. Other subnets/VLANs are not affected.

In the Extended Exhausting attack I am thinking of, it is possible to exhaust ALL the pools regardless where the attacker resides. This involves spoofing the Relay Agent of every subnet/VLAN. The following steps outline the process:

1- The attacker resides in 10.1.13.0/24 subnet. He wants to exhaust the pool associated with 10.1.15.0/24 subnet. The attacker needs to know in advance the gateway router for that subnet; usually it is going to be 10.1.15.1. The attacker may check his gateway IP address and apply the implemented scheme on other subnets.

2- The attacker sends a DISCOVER message. It is a unicast packet with spoofed source IP; such spoofed IP is the Relay Agent (i.e. gateway) of the other subnet, e.g. 10.1.15.1. Also, this DISCOVER has in its “Relay Agent IP Address” field the IP of that gateway, too.

3- When the server receives this DISCOVER message, it appears as though a client in the subnet 10.1.15.0/24 is requesting a new IP address. The server would also know that the DISCOVER message is being forwarded by a Relay Agent whose IP address is indicated in the source IP as well as in the “Relay Agent IP Address” field. The server checks the pool associated with 10.1.15.0/24 subnet to see if there are available addresses.

4- If there is an available IP in the pool, the server sends an OFFER to the Relay Agent, that is, to the spoofed IP address that was in the DISCOVER message. The OFFER carries an IP address within the 10.1.15.0/24. This packet will not be delivered to the attacker; it will be sent to the router/gateway of the 10.1.15.0/24 subnet. However, since the router/gateway did not issue a DISCOVER message (with the same Transaction ID), the router/gateway will just ignore the OFFER.

5- The server now expects a REQUEST message from the Relay Agent, which is the router/gateway of 10.1.15.0/24.

6- The attacker now has the chance to send the REQUEST message; however, the attacker does not know the IP address offered by the server since the OFFER message never reached the attacker. In this case, the attacker would send around 254, at maximum, REQUEST messages where every message contains an IP address from the subnet 10.1.15.0/24. All of these messages contain the same Transaction ID used initially by the attacker in the DISCOVER message. These messages will be sent with the spoofed IP address of the Relay Agent (i.e. router/gateway)

7- One of these REQUEST messages will match the OFFERED IP address and it will be accepted as a legitimate REQUEST. The server sends an ACKNOWLEDGMENT message to the Relay Agent/Gateway. This message will be ignored by gateway/router just like with the OFFER message.

8- The attacker now repeats the cycle again for around 254 times, at maximum, to exhaust the pool for 10.1.15.0/24.

I uploaded a new version (V1.5) of the Dynamic Port Scanner (DPS), a reliable spoofed source IP port scanner. The major addition to this new version is the multi-threading capability which makes the scanning process faster.

Link: The home page of the DPS project
Link: Download dps-v1.5.tar.gz

"The sole idea of the Dynamic Port Scanner (DPS) is to provide a reliable spoofed source IP port scanner. The spoofed source IP is dynamically generated at run time and it varies for every scan packet; every scan packet carries a random spoofed source IP. Traditionally, a port scan with a spoofed source IP has been considered unreliable due to the fact that reply packets would not reach back the scanning system. However, the technique used by DPS ensures the reliability of such spoofed scan. This technique is based on the integration of ARP Poisoning into port scanning to achieve the desired result. The spoofed IP addresses used by DPS during a scanning process fall within the range of the local subnet. Thus, DPS is best suited for internal scanning."

DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks. In their research paper “Protecting Browsers from DNS Rebinding Attacks”, Collin Jackson et al. discuss the DNS Rebinding vulnerabilities, attacks, and defenses.

DNS rebinding attack exploits the web browser same-origin policy. The same-origin policy states that a web browser can run scripts (e.g. Javascript, Flash, etc) that communicate with ‘another’ web site as long as the original website and the second one share the same origin. The same-origin policy defines three conditions: (a) same protocol, (b) same port, and (c) same hostname. For example, the address "http://www.securebits.org" and the address "https://www.securebits.org" do not share the same origin, and thus, cannot script against each other. The web browser does not allow scripts from "http://www.securebits.org" to communicate freely with "https://www.securebits.org". On the other hand, the address "http://www.securebits.org:8080" and the address "http://www.securebits.org:8080/somefolder/" are said to have the same origin because they share the same protocol (http), the same port (8080) and the same hostname (www.securebits.org).

An attacker can exploit this policy by rebinding the hostname of a particular website to an IP address that is different than the original one. Usually, the attacker would build a website that is under his/her control. He/she also controls the DNS server that resolves the DNS queries related to that website. When the victim accesses the website for the first time, the DNS server gives out the correct IP address. However, later on, the attacker rebinds the hostname of the website with a false IP address - usually an IP address that the attacker does not have access to – so that any subsequent link to the website will be directed to that IP address. By doing this, the attacker can script against the IP address – he/she can port scan, bypass firewall, access systems, etc.

To illustrate this with an example, let’s say that the victim’s machine is behind a firewall and has the IP 10.10.10.5. In the same network, there is a printer with the IP 10.10.10.8. The printer can be accessed through a web interface and normally does not prompt for username/password since it is in a private network and is only accessible by trusted systems within the network. The attacker, who is outside in the Internet, would build a website "www.example.com", and also control a DNS server that resolves the hostname "www.example.com" to the IP 65.54.43.32. Through social engineering tricks, the attacker would trick the victim to visit the website "www.example.com". Initially, the browser will send a DNS query to resolve that name and eventually will get the IP 65.54.43.32. When the client visits the website, the contents of the website are downloaded. The attacker sets a script (Javascript or Flash) that initiates a connection to the “hostname” (www.example.com). By the time this script is executed by the browser, the browser needs to query the DNS again to resolve the hostname "www.example.com". At this time, the attacker’s DNS server will reply with the IP address 10.10.10.8, basically rebinding the hostname to a different IP. Now, the script will actually initiate the connection with the local printer and can re-configure it.

This type of DNS rebinding attack is called “Firewall Circumvention” and it is one of the typical attacks using DNS rebinding technique. The example above mentioned “a printer” as an example; however, any internal device, such as a DSL router, switch, server, etc, can be a target of DNS rebinding attack.

Dnswall is a program that runs on the corporate network DNS server. Its sole purpose is to prevent the resolving of public names to internal IP addresses. According to the authors:

“By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners”

The Dnswall program runs as an intermediary proxy DNS server between the client and the real forwarder server. It intercepts the DNS queries sent by clients, forwards the query with little modification, receives and forwards the reply to the client only when the IP address in the answer payload is public. If the answer IP address is private/multicast, the Dnswall sends NXDOMAIN reply. Particularly, the program checks for IP addresses in the following ranges:

- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x

The program can run with the following arguments:

     ./dnswall -b (bind ip) -B (bind port) 
       -f (forwarder ip) -F (forwarder port)

Where ‘bind ip’ is the listening IP address, ‘bind port’ is the listening port number, ‘forwarder ip’ is the IP of the real DNS server, and ‘forwarder port’ is the port on which the forwarder is listening.

Finally, an important point to mention is that the Dnswall program forwards DNS queries after modifying the TXID of the original query. This is done to map the replies with their original queries. However, the new TXID used is sequentially incremented, starting from 0 to 65536. This opens the door to the opportunity of DNS cache poisoning. An attacker would predict the TXID and inject a false response to poison the DNS cache of the client machine. The code snippet that handles this is:

  // Replace the id with our own query identifier
  *((short *)&msg[0]) = htons(current_query);
  current_query++;
  if (current_query >= 65536)
   current_query = 0;

Administrators who seriously want to deploy Dnswall needs to do a little modification to this code to prevent the poisoning attacks. Mainly, a randomization algorithm should be used to select new TXID, or at least preserve the same original TXID.

IP spoofing is one of the techniques used by attackers to perform different attacks. It could be used while flooding a network, SYN-attacking a server, generating IDS false positives, etc. The rule when spoofing the source IP address is that replies do not matter to the attacker since replies will be sent to the spoofed IP and will not reach the attacker. Implementing an attack that requires an interactive communication between the attacker’s machine and the victim cannot take place with a spoofed IP address.

Port scanning is the technique to discover open ports on a remote system. To discover an open TCP port, the attacker needs to send a TCP SYN packet to a specific port and receive one packet back. If the received packet is a SYN_ACK packet, the port is open. If the received packet is a RST packet, the port is closed. If no reply is received, the port is filtered by a firewall or any other filtering engine. The reply packet, whether it is a SYN_ACK or RST, must reach the attacker’s machine so that it will be examined. This requires that the received packet is destined to the IP address of the attacker’s machine (or at least an IP address that is under control of the attacker) which in turn requires that the scanning packet sent by the attacker contains the actual source IP address of the attacker. So, the basic operation of port scanning cannot be done with a spoofed IP address.

Nmap, the infamous port scanner, can send spoofed scan packets. However, it is not meant as a reliable scan. Meaning, the attacker will not get reliable results of his/her scan. Such spoofed scan can be used to elude the IDS/IPS and generate huge amount of signatures. Also, it could be used as a way to divert the attention of the target corporate organization to another competitor organization; the spoofed scan will appear as if it is coming from the competitor organization.

However, the question is: can we have spoofed port scanning that is reliable? The answer is ‘Yes’ but with the following two constraints:
[1] The port scan should be conducted internally within a LAN; for example, the port scan can be part of an internal security audit or penetration test. The technique used to achieve this reliable spoofed port scan cannot be implemented over a WAN.
[2] The spoofed IP addresses used during the port scan should fall within the range of the local subnet. For example, if the attacker’s machine is in class C (255.255.255.0), he/she can use any of the 253 valid IP addresses within the subnet range; if subnet is a class B (255.255.0.0), the pool of valid spoofed IP addresses is 65533.

The technique to achieve this reliable spoofed port scan is based on integrating ARP poisoning with port scanning. ARP poisoning refers to the ability of the attacker to insert a fake entry in the ARP cache of the victim machine. This fake entry links an IP address, which is within the same subnet range of the victim’s machine, with a false MAC address. The entry will cause any traffic destined to that particular IP address to be destined, at layer 2, to the machine with the MAC address associated with the IP address. An attacker will typically insert fake entries that link different IP addresses to the MAC address of his/her machine; thus, all local traffic will be delivered to his/her machine. A typical use of ARP poisoning is to achieve layer 2 traffic interception between two machines (either of them could be even a router or gateway.)

The process of doing a reliable spoofed port scanning works by poisoning the ARP cache of the remote machine with a false entry that links the spoofed source IP address used in the scanning with the MAC address of the attacker’s machine. For every spoofed source IP used, the attacker needs to inject a fake ARP entry for it. It is also important to note that there is a difference between scanning a system that is located within the local subnet and a system that is in a different subnet. When scanning a system located locally, the ARP cache of this machine needs to be poisoned; however, when scanning a system located outside the local subnet, the ARP cache of the router/gateway is what needs to be poisoned. This is because the ARP protocol functions at layer 2 which cannot be routed externally to other networks.

To effectively poison an ARP cache of a remote machine, two ARP packets at maximum are needed or one ICMP packet and one ARP packet. In the case of two ARP packets, the first one is an ARP request while the second is an ARP reply. Both packets contain the following arguments: the destination MAC address is the victim MAC address, the source MAC address is the attacker’s MAC address, the destination IP address is the victim’s IP address, and the source IP address is the spoofed IP address which the attacker wants to inject. For example, let’s assume the following scenario:
a. The victim’s IP address is 10.10.10.10
b. The victim’s MAC address is aa:aa:aa:bb:bb:bb
c. The attacker’s IP address is 10.10.10.3
d. The attacker’s MAC address is bb:bb:bb:cc:cc:cc
e. The attacker wants to intercept traffic going from the victim to 10.10.10.50

The attacker, then, sends two ARP packets (the first is ‘Query’ and the second is ‘Reply’) to the victim with the following arguments:
a. Source IP is 10.10.10.50
b. Destination IP is 10.10.10.10
c. Source MAC is bb:bb:bb:cc:cc:cc
d. Destination MAC is aa:aa:aa:bb:bb:bb

These two packets will inject the following spoofed entry in the ARP cache of the remote machine:
10.10.10.50 is at bb:bb:bb:cc:cc:cc

This will cause any packet sent by the victim machine (10.10.10.10) to 10.10.10.50 to be switched at layer 2 to the attacker’s machine.

By integrating the technique of “ARP Poisoning” into “Port Scanning”, we can have a reliable spoofed source IP port scanning. What is needed is to poison the remote machine (or the gateway) with a fake entry that links every used spoofed source IP with the attacker’s MAC address. Such will cause any scan reply to be delivered to the scanning machine. The algorithm for the whole process of spoofed scanning would be as follows:
1. Check whether the scan target is within the local subnet or outside.
2. If it is within the local subnet, the “poisoning target” is the same as the “scan target”. If the “scan target” is outside the local subnet, then the “poisoning target” is the “gateway”
3. Generate a random spoofed source IP that falls within the local subnet.
4. ARP-poison the “poisoning target” with a fake entry that directs all traffic destined to the spoofed IP to the attacker’s machine.
5. Send the scan packet to the “scan target”
6. Wait for a reply with the same MAC address as the attacker’s MAC address.

Generating different spoofed IP with every scanning packet (one packet for one port) would make the scan appear as if it is distributed between multiple (fake) systems. H.K. has generated a live image with Etherapp tool representing the distribution of the spoofed port scanning: