Securebits Blog

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.

Recently, I was trying to do the normal ARP poisoning/spoofing attack to intercept the bi-directional traffic between a Windows Vista machine and the Internet (through a gateway router). To my surprise, I was able to see a unidirectional traffic, which is the traffic coming from outside through the gateway to the Vista machine and I could not see the traffic sent from the Vista machine. I checked the ARP cache of both the gateway router and the Vista machine and found that the poisoning was successful – and by the way, I was using the Ettercap tool. The router cache contains an entry that says the IP address of the Vista machine is located at the MAC address of my (MITM) machine; likewise, the Vista cache contains an entry that says the gateway router IP address is located at the MAC address of my machine (the MITM). However, when I check the sniffer (Wireshark) on the MITM machine, I do not see any traffic from the Vista machine directed to the outside world.

After a little investigation, I discovered that the Vista machine was not using the default gateway IP address to look up its MAC address using normal ARP request, and then use this MAC in all packets destined to the outside world. It was actually sending Proxy-ARP request for every public IP address the system was trying to connect to. In other words, when the system needs to communicate with a public IP address, instead of just using the MAC address associated in the ARP cache with the default gateway IP, the system sends an ARP Request asking for the MAC address of that public IP address. Since this public IP does not fall within the local subnet range, such ARP request is called “Proxy ARP Request” and it will be handled by the default gateway itself. Usually, the gateway will return its own MAC address, and the system will cache a new entry associating this MAC address with the public IP address. The Vista system repeats this process with every public IP address it is trying to communicate with.

For example, let’s say that the default gateway IP is 10.0.0.1 and its MAC AB:CD:EF:12:34:56. Let’s assume that there is already an entry in the ARP cache associating this IP with is MAC. In normal operations, when the system wants to contact a public IP like 65.65.65.65, it simply sends the packet where the destination MAC address is that of the gateway, that is AB:CD:EF:12:34:56. However, in the new Vista operation, the system will simply send a Proxy ARP Request asking for the MAC address of 65.65.65.65, then, the gateway will reply with its own MAC (AB:CD:EF:12:34:56). The Vista system will now cache this new entry associating 65.65.65.65 with AB:CD:EF:12:34:56. When the system wants to communicate with another IP address, e.g. 53.53.53.53, it will cache another entry and so on so forth.

My only impression about this behavior is that Microsoft is trying to minimize the effect of ARP spoofing/poisoning so that normal ARP interception technique may not fully work. Intercepting a unidirectional traffic is not of much interest for an attacker since he/she will miss a lot of important data, besides, many attacks (e.g. SSL Hijacking, RDC Hijacking, etc) implemented after a successful interception may not work properly.

To circumvent this restriction, the attacker needs to poison the ARP cache with fake entries for every IP address the system is trying to connect to. This could be done as follows:

• The attacker sniffs for ARP Requests generated by the target system and asking for MAC address of an IP address that falls outside the local subnet.
• The attacker sends a fake ARP reply saying that the MAC address of such public IP is the MAC address of his/her own machine (MITM).
• The attacker keeps this public IP in a list to keep injecting the fake ARP replies every 1-2 minutes (to keep the cache poisoned)

This process can be automated using a script or a program which will run simultaneously with a tool like Ettercap.