Securebits Blog

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 decided to dedicate this entry to my favorite 10 network security tools. I use them mostly while engaging in a penetration test, while debugging a network application, or during a research development. With the exception of the first tool, Nessus, all the other nine tools are “open-source”; Nessus used to be an open-source application until version 3.0 when it became close-source.

[1] Nessus

According to “Top 100 Network Security Tools”, Nessus occupies the first place. It is a full-blown vulnerability scanner with over 20,000 plugins. Nessus3 stores all hosts, policies, and reports in one *.nesses file which makes organizing reports and policies easier. When I scan a specific subnet (/24 for example), I usually feed Nessus with “live” hosts found by Nmap and group every 10 hosts in one scan. Although Nessues comes with two scan policies: Default Scan Policy and Microsoft Patches Policy, I create additional policies for ease of management; usually these policies are:

Remote Shell/Root Access: This policy comprises plugins for gaining remote shell/root to the target system.

Service Detection/Port Scanning: This policy only finds out the open ports along with the listening services.

Network Devices: This policy is made for testing network devices like routers, switches and printers. It includes plugins related only to these devices.

Windows Systems: This policy tests only windows machines.

UNIX Systems: This policy is made to test UNIX, Linux, *BSD, etc machines.

ALL: This policy includes all the Nessus plugins. It scans a target for everything Nessus has got knowledge of.

The Nessus community has also released useful policies; one of them is “SANS Top 20” policy which scans for SANS Top 20 Security Risks.

[2] Nmap

The Nmap Security Scanner is a general-purpose port scanner, O.S. detector, and service identifier. It features different types of scanning methods (SYN, ACK, XMAS, etc) where a combination of these methods enable the user to detect if the target system is filtered/unfiltered, or perform stealth scan. Nmap also features wide range of Host Discover, typically: (1) Echo Request, (2) TCP ACK -PA, (3) TCP SYN –PS, (4) UDP –PU, (5) ICMP Echo –PE, and (6) ICMP Timestamp -PP. TCP SYN (-PS) is best used against stateful firewalls while TCP ACK (-PA) is best used against stateless firewall. It is recommended to use both types of TCP discovery methods combined with well-known open ports. A sophisticated way to perform host discovery can be done by issuing the following command:

namp –sP –PE –PP –PS 21,22,23,25,80,113,31339 –PA 80,113,443 10.1.0.0/24

The (-sP) instructs Nmap to perform only host discovery. The (-PE) and (-PP) options perform ICMP discovery while the (–PS) and (-PA) options perform TCP host discovery using the specified ports.

Nmap is relatively fast scanner. When I scan an internal host that is one hope away and there is no filtering device/engine, scanning ports 1-65535 takes approximately 6-10 seconds; link speed is 100 Mbps. The command for such scan is usually:

nmap –v –sS –p 1-65535 <ip_address>

However, sometimes Nmap will slow down the rate due to many filtered (or unreachable) ports. If the auditor wants to speed up such scan, Nmap can be forced to send no less than a particular rate using the option (--min-rate); I usually set this to 5000 or 6000, so the command would be:

nmap –v –sS –p 1-65535 –min-rate 5000 <ip_address>

There are situations where scanning large number of ports is not recommended, the auditor may, in this case, scan only the most commonly open TCP and UDP ports which are: 80/tcp, 23/tcp, 22/tcp, 443/tcp, 3389/tcp, 445/tcp, 139/tcp, 21/tcp, 135/tcp, 25/tcp, 137/udp, 161/udp, 1434/udp, 123/udp, 138/udp, 445/udp, 135/udp, 67/udp, 139/udp, and 53/udp.

[3] Xprobe

Xprobe is an accurate Operating System fingerprinting tool. It primarily based on ICMP protocol; however, it also uses a bit of TCP/UDP combination. Xprobe's uniqueness is in sending small number of packets, around 2-3 ICMP packets and 1-2 TCP/UDP packets, to fingerprint the remote OS. The easiest way to run Xprobe is by providing the IP address of the target system:

xprobe2 10.1.10.241

Xprobe would give a better result if it is told about an open port on the remote host. For example, when I run the tool against Windows XP SP2 box without specifying a port status, the primary guess was “Microsoft Windows 2003 Server Standard Edition”. However after specifying the open port 139/tcp, the primary guess was “Microsoft Windows XP”.

[4] HPing

Hping is a tool for sending customized ICMP, TCP, UDP and Raw IP packets. The tool enables the user to play with the fields of any packet header. The tool is useful for detecting live systems on the network using various methods. Since some systems disable “ping” (ICMP Echo), an auditor may use different types of ICMP (like Timestamp) to detect if the target system is up, or he/she may use a TCP ping by sending a TCP packet with ACK flag set. Also, Hping is useful to test firewalls and IDS/IPSs; the auditor may fine tune those systems by sending unusual customized packets through them. Hping also can fragment packets into tiny pieces – a good method to evade and test IDSs.

An example of testing a firewall is to send a TCP packet with SYN_ACK flags set and check whether the firewall passes such packet even though it is not part of an established connection. The following command sends a TCP packet with source port 80, destination port 54231, and TCP flags SYN_ACK:

hping2 –S –A –s 80 –p 54231 10.10.10.10

[5] Yersinia

This is the tool of trade to perform protocol attacks applicable to the local subnet. It supports many different protocols including DHCP, STP, HSRP, CDP, VTP, ISL, etc. The most common modules I always use are for the protocols DHCP, STP, HSRP, and CDP. The following attacks for these protocols are most useful:

• Spanning Tree Protocol (STP)
1- Claiming Root Role
2- Claiming Root Role dual home (MITM)

• Dynamic Host Configuration Protocol (DHCP)
1- DoS sending RELEASE packet (releasing assigned ip)
2- DoS sending DISCOVER packet (exhausting ip pool)
3- Setting up rogue DHCP server

• Hot Standby Router Protocol (HSRP)
1- Becoming active router with MITM

• Cisco Discovery Protocol (CDP)
1- Setting up a virtual device

After passively sniffing the local subnet for few minutes, if the auditor notices that switches in the local subnet are glued using Spanning Tree Protocol (STP) to maintain redundancy, he/she can mess up the actual topology by sending “fake” STP packets in a special way to declare his/her machine as the root of the logical switching tree. Thus, his/her machine becomes the point where all subnet traffic comes to. Concurrently, he/she should forward the traffic to the destination so that no disconnection or DoS is felt by other users. Yersinia automates this attack smoothly.

Just like the case with STP, if the auditor captures HSRP packets in the local subnet, it is likely that there two routers configured as active-standby with a single virtual IP address. HSRP uses clear-text authentication phrase/word (similar to SNMP community string) which can be sniffed by any one located within the subnet. Sending special HSRP packets can mess up the actual router status and declare a third machine as the “Active” router. In this case, all the traffic destined to the outside world would be sent locally first the machine declared as “Active”. For full traffic interception, the auditor would need to forward the traffic to one of the two routers. The ID of this attack in Yersinia is “2”

Another way to intercept traffic is to give local machines false DHCP information about the default gateway. The best way this can be done is through the following steps:

1. RELEASE all the assigned IP addresses from the DHCP server (Yersinia DHCP attack 3)
2. Exhaust the DHCP pool by acquiring all the IP addresses in that pool (Yersinia DHCP attack 1)
3. Declare your machine as DHCP server – set the default gateway entry to the IP address of your machine (Yersinia DHCP attack 2)
4. Forward all received IP traffic from the local machines to the real gateway and vice versa.

[6] Ettercap

I use this tool for only one thing: Layer 2 ARP traffic interception in a switched LAN. When Ettercap starts, it builds a table of all existing live hosts in the subnet along with their MAC addresses. Traffic interception can be any of the following shapes:

A. Intercepting traffic between two hosts.
B. Intercepting traffic between a specific host and every other host.
C. Intercepting traffic between a specific host and the gateway/router.
D. Intercepting traffic between the gateway/router and all other hosts.

When the two sides of the intercepted traffic have been decided, Ettercap poisons each side with fake ARP entry/entries about the other side; this is done by sending first a false ICMP packet followed by another false ARP reply packet. The poisoning packets are sent regularly at a periodic basis. When this is done, Ettercap performs all the necessary traffic forwarding so that both sides do not feel any disturbance in their traffic activities.

[7] Netcat

Netcas has been described as the network Swiss-army knife, a no-hacker-should-be-without tool. It is a multi-purpose tool providing TCP connections, TCP listener, file transfer, process-to-connection attachment, etc. It can be use as a substitute to “telnet” especially when connecting to HTTP, SMTP, or POP3 servers. Practically, I use “netcat” to do the following:

A. Connecting to HTTP, SMTP, or POP3 servers while pen-testing or diagnosing a network:

nc <server_ip> [80|25|110]

B. Sending a specially-crafted TCP payload to a listening service:

nc <server_ip> <port> < payload_file

C. Listening on a particular TCP port:

nc –l –p <port>

D. Attaching a process (mainly a shell) to a particular port:

nc –l –p <port> -e /bin/sh

[8] Ngrep

Ngrep is network tool that functions similar to the infamous UNIX grep command. It applies regular expressions on network traffic and shows packets that match such regular expressions. It is best suited to search ASCII-based protocols, like SMTP, POP3, HTTP, FTP, etc. From the man page:

ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular or hexadecimal expressions to match against data payloads of packets. It currently recognizes IPv4/6, TCP, UDP, ICMPv4/6, IGMP and Raw across Ethernet, PPP, SLIP, FDDI, Token Ring and null interfaces, and understands BPF filter logic in the same fashion as more common packet sniffing tools, such as tcpdump and snoop.

Examples of ngrep usage:

ngrep –d 2 cisco

ngrep –d 2 administrator

[9] Wireshark

Wireshark is an all-in-one network sniffer and packet analyzer. It can decode and inspect hundreds of protocols. It has an interactive GUI displaying the packet headers, the current decoded packet, HEX dump, and ASCII dump. Wirshark is compatible with Tcpdump – both of them can save packets to *.pcap files and read/analyze the files off-line. Also, Wireshark has a very nice colorful scheme making distinction between different protocol packets (tcp, udp, icmp, http, ftp, ntp, etc) easier and quicker.

A recently-added feature allows the decryption of SSL/TLS traffic provided that the private key is supplied and that Wireshark captures the whole of transaction. This is useful when doing a white-box pent-testing against a web application that runs over SSL/TLS; since in a white-box test, the auditor has access to the web server along with the application source code, he/she may extract the private key and install on Wireshark running on his/her client machine. The auditor can then analyze the application by inspecting the decrypted network traffic between the client and the server.

Wireshark supports two packet filtering modes: the first is capture filtering, and the second is display filtering. The capture filter string is applied to capturing engine and only packets matching the string will be captured; the rest are discarded. The display filter string specifies which packets the user wants to see. Captured packets not matching the string will not be shown; however, they are still saved and the user can view them later by changing the display filter again. The capture filtering uses the Berkeley Packet Filter (BPF) syntax. Examples of such filtering strings are:

dst host 10.10.10.10 and dst port 80

src host 10.10.10.10 or src host 10.10.10.20 and dst port 21

Examples of display filtering strings are:

http

ip.src == 10.10.10.10 and tcp.dstport == 53

[10] Firewalk

This tool is meant for finding the Access Lists configured on a filtering device (e.g. Router, Firewall, etc). Given a known filtering device and a known system behind that device, Firewalk will attempt to figure out what TCP/UDP ports are allowed to pass through that filtering device and what ports are denied.

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."

On the 30th of October, 2008, I have presented my latest network security research titled “Next Generation Reverse Shell” at Hack-In-The-Box Security Conference in Kuala Lumpur, Malaysia.

The presentation and the whitepaper can be downloaded from the following links:

1. Presentation (pptx version)
2. Presentation (ppt version)
3. Whitepaper (pdf)
4. Giant-Reverse (GR) Tool - Beta Version 0.9.5

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.