In today’s inter-connected world, not a week goes by without learning about another security breach with the loss of untold thousands of data records containing PII (or Personally Identifiable Information). Tools such as Nmap and Ettercap are often used as part of the reconnaissance and execution of the breach. These tools (however maligned) do have a legitimate place in systems and network administration.
As with any tool, there is always a down side to their use. A hammer can be used to frame a house yet it can also be used to break a car window… and even then that can be seen as a positive thing in cases of emergency. These so-called hacking tools often start out as legitimate applications that provide valuable help to network administrators. It is through their misuse that they gain their negative connotations. Corporate policies often ban their use on protected networks yet for network and system administrators very often these tools can make their job so much easier… the right tool for the right job. Ettercap, Nmap and Wireshark are all valuable tools designed to help these administrators troubleshoot various network problems.
Ettercap is described as a suite of tools for man in the middle attacks on LANs. It was originally released on January 25th, 2001 as a public beta. At that time, Ettercap took advantage of the ncurses library which provided programmers the ability to write text-based user interfaces making the application somewhat more user friendly when compared to CLI based applications. Originally Ettercap’s feature set was pretty bare. It allowed for the sniffing of IP based traffic along with MAC and ARP sniffing. Additionally it allowed for the injection of handcrafted packets into an established connection. Today the current version, NG-0.7.3 (released May 29, 2005) has a very robust feature set. Its features allow for the sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols (even ciphered ones) and includes many features for network and host analysis (ettercap.sourceforge.net, 2010). It has an OS fingerprint database and password collector. The application’s usefulness can be expanded through its support of a plug-in based architecture.
More information on Ettercap’s feature set can be found at http://ettercap.sourceforge.net/history.php
Nmap is a service and network exploration tool. In the right hands it can be used to perform security audits checking for open ports and software versions allowing system administrators the opportunity to patch vulnerable services. In the wrongs hands it can be used to scan a network looking for vulnerable services/hosts to take advantage of. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime (nmap.org, 2010). Nmap was first released in September of 1997 and has continued to have strong development support. The current version nmap-5.35DC1 was released on July 16th 2010. Nmap can be used from the command line interface in addition to various GUIs for Linux, OSX and Windows OSs. One of the nice things about Nmap is that it is well documented. Nmap cannot only do port scanning (both TCP & UDP) on a single host… It can perform ping scans of an entire network, which is great for discovering unknown hosts. It has the ability to map out IP filters, firewalls, and routers! It can “see” past NAT’s. Additionally it can do OS detection and well as software version detection.
More information on NMAPS’s feature set can be found at http://nmap.org/changelog.html
So why Ettercap? The focus of this paper is the use of so called hacking tools for legitimate purposes. One needs to look at what the tool does and how it can be used in a constructive way. This application really shines in switched environments because it minimizes the benefits of a switch. I think this needs a little explanation!
In the good old days of non-switched networks, we could attach a network sniffer to a hub and seek out the Ethernet traffic between the two machines without much effort. Why? Because hubs “broadcast” all incoming traffic to all ports on the device. It was then the responsibility of the host to grab the packets intended for itself and then act upon them. While this may seem like a good thing it unfortunately is not. Hubs pass traffic to all of its ports at the same time. Many different machines connected to the hub could then respond to this incoming traffic to at the same exact time. This could lead to packet collision forcing the host to retransmit the packet. This causes network latency and slowness. In an effort to combat this problem, networking vendors came up with switches. Fundamentally speaking… Switches direct traffic between the incoming port and the port that the intended host is connected to. It does this by caching the MAC addresses (Data Link Layer) of all hosts connected to the switch. Additionally, from a logical perspective, in order for machines to communicate via IP (Network Layer), the switch needs to match the MAC address to an IP address. The Address Resolution Protocol (ARP) is used to associate IP addresses with a MAC addresses. Each system maintains a database of previously learned IP to MAC mappings, known as the ARP cache (Norton, 2004). This ARP cache is consulted to pass packets from one host directly to another without having third party hosts “looking” in on the traffic.
Let’s say that we are having a problem between a server and client. The client can’t gain access to the server’s resources. It seems as though authentication is not happening but we need to be sure. Could this be a networking issue? Based on what we already know about switched environments, we need to overcome the benefits of a switched environment by manipulating (poisoning) the ARP cache on various hosts. Enter Ettercap! Ettercap relies heavily on ARP spoofing. By using this technique you can fool target machines into sending data through your attacking machine and then you can sniff it on your attacking machine (Garg, 2005). With it we can execute a Man in the Middle (MITM) attack to sniff the traffic between the two machines. Yes… I know this could be accomplished with port monitoring but that assumes you have a smart switch.
Figure 9: Shows some of the output from Wireshark on the “attacking” machine.
NOTE: We can see the traffic passing between our two selected hosts. Also note the Ethernet II line in the middle pane. We can clearly see that the MAC of the destination host is that of the “attacking” machine.
Getting back to our problem we can see that traffic is passing back and forth between the client and our LDAP server. So clearly it’s not a connectivity issue. The problem must lay somewhere else.
Mapping a network has many benefits. The biggest two are understanding what machines are actually connected to your network and the other being what services/resources are being offering up to client machine. Gordon “Fyodor” Lyon, Nmap’s original developer, once wrote, the idea is to probe as many listeners as possible, and keep track of the ones that are receptive or useful to your particular need (Lyon, 1997). I think that one sentence says it all… receptive or useful to YOUR particular needs! One needs to realize that this software was/is used to find targets of opportunity. A hacker attaches himself or herself to a network and then looks for ways to further penetrate or compromise a host/s and the network they reside on. Testing for compliance can be one of the most important detective security controls you perform in an enterprise infrastructure (Orebaugh, 2008). One of the things to keep in mind is that Nmap does not compromise a host in anyway! It merely looks for and finds machines and the services they are running. When used in conjunction with host vulnerability assessment tools such as Nessus, holes can be discovered and then exploited. This can then be taken a step further and other tools can then be used to compromise the intended victim. Nmap uses many different methods to determine whether a host is active and which ports are open. There are far too many to detail here so I’ll cover only a few.
First up is the ping sweep. This scan really can’t look for open ports on a host… just which IPs are being used on a network.
Next is the TCP connect() scanning. It is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn’t reachable (Lyon, 2008).
Moving on to the TCP SYN… This scan uses a technique to create a half open TCP connection. Using this method we send a SYN segment and, if an ACK is received then we have detected an active port on the target machine, and we sent a RESET to close the connection promptly. If we receive an RST instead of an ACK, then the scanned port is not active (Lujambio, 2001).
Finally there is the TCP FIN scans. There are really helpful when dealing with firewalls. This scan type is accomplished by sending TCP segments with the FIN bit set in the packet header. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response (mitre.org, 2010). There is a downside to this type of scan. Open ports are inferred but the benefit for being able to get past a firewall outweighs the extra work of determining the true status of the host.
So let’s look at a legitimate network need that NMAP can solve fairly quickly. Many network-based devices come with DHCP turned on so that you can start using it right out of the box without having to configure the networking side of things. The problem is finding which IP address the box actually was assigned. This leaves the network administrator guessing as to where on the network their new toy is. In addition to having DHCP turned on by default, most of these devices have a web interface that runs on port 80 and therein lays the key to finding the device on the network.
Let’s take a look at how this works in practice. Let’s say that I’m installing a new printer on my network. We need to make sure that the device has a static IP but out of the box it’s set to up DHCP. We know that configuring the printer is much easier using the web interface rather than the front panel. Knowing this basic information we can craft an Nmap scan to look for all hosts that have port 80 open. We’ll also want to know what OS the device is running so that we can figuring out exactly which device is my HP printer. Lastly we know that the printer is installed on the 10.0.1.0/24 network. Let’s craft a simple nmap command to find our printer.
nmap -sV -T3 -p80 -sT 10.0.1.0/24
Looking at the above command, the
–sV flag will provide the version number of the service that is running of the found device. The
–T3 flag sets the timing of the scan… or in other words how intrusive do we want this scan to be. The
–p80 flag tells nmap to look only for devices that have port 80 open. Next we tell Nmap to use the basic TCP connect scan using the
–sT flag. And lastly we need to tell Nmap what network it should scan (10.0.1.0/24). So let’s run our scan!
endeavour:~ bheese$ nmap -sV -T3 -p80 -sT 10.0.1.0/24
Starting Nmap 4.76 ( http://nmap.org ) at 2010-09-12 11:03 EDT
Interesting ports on (10.0.1.2):
PORT STATE SERVICE VERSION
80/tcp open http 3Com Baseline 2816 switch http config
Service Info: Device: switch
Interesting ports on (10.0.1.15):
PORT STATE SERVICE VERSION
80/tcp closed http
Interesting ports on 10.0.1.24:
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.14 ((Unix) mod_ssl/2.2.14 OpenSSL/0.9.7l DAV/2)
Interesting ports on (10.0.1.40):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.8 ((Ubuntu))
Interesting ports on (10.0.1.65):
PORT STATE SERVICE VERSION
80/tcp open http HP Color LaserJet 2600n http config 188.8.131.52
Service Info: Device: printer
Interesting ports on (10.0.1.254):
PORT STATE SERVICE VERSION
80/tcp open tcpwrapped
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 256 IP addresses (6 hosts up) scanned in 8.21 seconds
It’s pretty easy to see that our printer picked up the IP address of 10.0.1.65. Now all we have left to do is point a web browser at that address and configure the printer the way we want. Granted this is a pretty basic scan but it does illustrate how to use Nmap for legitimate purposed on a corporate network.
Understanding your network and how it’s being used under normal circumstances is extremely important. WHY? Because when something changes one can quickly understand the magnitude of the problem which can range from not knowing that a particular project has started to not knowing that a disgruntled employee is distributing illegal content at the company’s expense (Miessler, 2006). Software like troubleshooting Ettercap and Nmap are important tools in the network/systems administrator arsenal.
Garg, M., (2005, June 13th), Sniffing in a Switched Network, Retrieved on August 9, 2010 from http://articles.manugarg.com/arp_spoofing.pdf
Lujambio, D., (2001-06-29,) Learning with Nmap, Retrieved on August 7, 2010 from http://www.linuxfocus.org/English/July2001/article170.shtml
Lyon, G., (2008), Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Insecure LLC: Sunnyvale, CA
Lyon, G., (1997, September 1st), The Art of Port Scanning, Retrieved on September 7th, 2010 from http://www.phrack.org/issues.html?issue=51&id=11#article
Miessler, D., (2006, July), Housekeeping With Nmap, Retrieved on August 7, 2010 from http://danielmiessler.com/writing/housekeepingwithnmap/
Norton, D., (2004, Aril 14th), An Ettercap Primer, Retrieved on August 8, 2010 from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.154.4282&rep=rep1&type=pdf
Orebaugh, A. & Pinkard, B., (2008), Nmap in the enterprise: your guide to network scanning, Syngress, Burlington, MA
Unknown, (2010, April 10th), CAPEC-302: TCP FIN scan, Retrieved on September 11th, 2010 from http://capec.mitre.org/data/definitions/302.html
Unknown, (2010), Ettercap, Retrieved on September 7th, 2010 from http://ettercap.sourceforge.net/index.php
Unknown, (2010), Nmap – Free Security Scanner For Network Exploration & Security Audits, Retrieved on September 7th, 2010 from http://nmap.org/
Heese, B. (2010), Ettercap Screen Grabs
For a PDF of the above article, please click here!