| Penetration
Testing with dsniff What is dsniff? The ability to access the raw packets on a network interface (known as network sniffing), has long been an important tool for system and network administrators. For debugging purposes it is often helpful to look at the network traffic down to the wire level to see exactly what is being transmitted. Dsniff, as the name implies, is a network sniffer - but designed for testing of a different sort. Written by hacker Dug Song, dsniff is a package of utilities that includes code to parse many different application protocols and extract interesting information, such as usernames and passwords, web pages being visited, contents of email, and more. Additionally, it can be used to defeat the normal behaviour of switched networks and cause network traffic from other hosts on the same network segment to be visible, not just traffic involving the host dsniff is running on. These capabilities alone are enough to attract interest, but in its latest version (2.3 as of this writing, released late December 2000), it includes new programs to launch man-in-the-middle attacks on the SSH and HTTPS protocols, which would allow viewing of the traffic unencrypted, and even the possibility of taking over interactive SSH sessions. These new abilities have caused some uproar in the security community, however this document is not an ethical or technical debate; I only hope to show dsniff in action to help people understand its capabilities and therefore be better able to see weaknesses in their own network. The dsniff Package To give you an idea of exactly what dsniff can be used for, here is a list of tools included in the dsniff package, and a brief description of their function, partially taken from the dsniff README:
Penetration Testing Dsniff’s author refers to it as "a collection of tools for network auditing and penetration testing", and it is from this perspective that I’ll demonstrate putting it to use. Penetration testing is a form of security auditing, where you attempt to break in to a network - with the consent of those in charge of the network – trying to find weaknesses and vulnerabilities you were not aware of before, which hopefully leads to fixing those security holes. In my tests with dsniff, I used my own private home LAN. Unfortunately I do not have a switch at my disposal, so some of the switch-defeating mechanisms were not tested. However, I have seen some of these techniques used successfully for other purposes (such as clustering) and I have no doubt they work unless extraordinary precautions and limitations are enforced in the design of the network architecture. WARNING: If you plan on testing dsniff on a network you do not own, be sure you have written permission from appropriate authorities, as password and message capture are extremely sensitive topics and probably illegal without precise guidelines. In the following sections, we will see how dsniff can be used in several different attack scenarios. It is worth noting that although most of the techniques used by dsniff are not new, the fact that they are contained in a single easy-to-use package increases concern since it brings previously complex and difficult attack scenarios within the capability of the average script kid. Attack Preliminaries: Accessing the Target Network Traffic Before dsniff can be used on a LAN, naturally you first need root or administrator access to a host connected to the LAN. The dsniff toolkit is known to run on Linux, OpenBSD, FreeBSD, and Solaris. It is likely to be possible to port it to other UNIX platforms as well. There is even a version of dsniff for Windows NT, although it is older and lacks some of the features in version 2.3. Once dsniff is compiled and ready on the attacking host within the LAN, there are three different possibilities for accessing the network traffic: 1. The LAN uses a hub: In this case, nothing extra needs to be done, all network traffic going to any host on the LAN is visible to all other hosts on the LAN. 2. The LAN uses a switch: In the switched architecture, all hosts are connected to the switch on their own isolated port, and the switch keeps track of which host is on which port, and then only sends traffic intended for that host to its port. However, this is mainly intended to increase performance (since each host gets a dedicated connection instead of being shared like with a hub), and the security benefit is mostly a side effect. Therefore, it is easy to defeat by simply confusing the switch so it cannot be sure which host is on which port. Most switches respond to this condition by "failing-open", which means it begins to act like a hub and send all traffic to all ports. This will also cause network performance to suffer greatly, which might be noticed by others on the network. To accomplish this:
Note: Most switches can be configured to allow only one, fixed, MAC address per port – In that case, macof would have no effect, but it is a difficult arrangement to manage. 3. The LAN uses a switch and you wish to target a specific host: If you do not want to sniff all the traffic on the LAN but only wish to target a specific host on it, you can leave the switch alone and just confuse that specific host into thinking you are the gateway/router. Therefore any traffic that host wishes to send to outside the LAN will go to your host first. This is the most clandestine form of sniffing, since it only affects the target host, and only in the way you specify, therefore it is not likely to be noticed by others. To implement this:
Attack One: Password Sniffing Once the network traffic from the target host, or the entire LAN, has been made available to the sniffing host using the techniques above, it is a simple matter to start the dsniff program, which will then automatically detect and capture interesting information from the traffic. In fact, even a normal sniffer will capture the traffic just as well, but normal sniffers do not have the built-in knowledge of various application protocols that dsniff has. Attack Two: Message and File Capture Using msgsnarf and filesnarf, capturing email messages and files transferred via NFS are just as easy as capturing passwords. Both these programs do the work of interpreting the relevant network traffic to get results. msgsnarf saves the captured email in an mbox-format file for standard UNIX mail-readers to use. filesnarf saves the captured files in the directory it is run from. Attack Three: URL capture urlsnarf is similar to the other tools mentioned so far, but specifically written to capture HTTP requests and log the URL being referenced. webspy is along the same lines, but instead of logging the URL, it actually commands your local Netscape web browser to follow the URLs as they are sniffed, allowing you to surf along with the target in real-time. As the README says, this is "a fun party trick." Attack Four: Man-in-the-Middle All the previous attacks are considered to be passive since they do not involve altering the behaviour of the systems being targeted (causing the switch to fail-open can be seen as an active attack on the switch, but the network traffic is merely observed, not intercepted or modified en route). On the other hand, a Man-in-the-Middle attack is an active attack since the attacking host plays an important role managing the network traffic between the source and destination targets. A MITM attack is when the target host is fooled into thinking it is connecting to a desired destination host when in fact it is connecting to the attacker host, which then handles the connection to the desired destination host and proxies traffic between the two from that point on. In this way, the attacker host now completely controls the connection and can view and/or modify information passing between the connection it has forged with the source and destination hosts. This type of attack is particularly effective when dealing with connections encrypted with public-key cryptography. If you are not familiar with this subject, one good overview is at the Netscape developer site. Public-key cryptography is an extremely effective encryption concept, but it does require that connecting host have a copy of the public key from the host being connected to. If the connecting host does not already have the public key from a previous connection with that host then it will have to get it from somewhere – with protocols such as SSH, the destination host will supply its public key itself. MITM attacks take advantage of this by intercepting the initial connection attempt and substituting their own "forged" public key (which they have the private key for and can therefore decrypt the data). If the user at the connecting end has never seen the correct public key before, it is likely the forgery will not be noticed and the attack will be a success. Even in the case where the user does have the correct public key to compare with it, often it just results in a small warning being printed saying the key has changed and if they want to continue connecting. Most users will simply click OK without another thought. This is not the fault of the protocol. This is a problem with user education and also with implementations that print simple warnings when an event as serious as a key change occurs. Setting up the Attack Executing the MITM attack is more complex than the others, but dsniff’s tools make it almost as easy. In this scenario there are three systems (plus the gateway) involved in our sample network:
1. We have to fool the client (target) host into thinking the MITM host is the gateway. This is done using arpspoof. At the start, you can see the client has the correct ARP entry for the gateway: [Client] C:\WINDOWS>arp -a Interface: 192.168.1.77 on Interface 0x2000003 Internet Address Physical Address Type 192.168.1.1 08-00-de-ad-be-ef dynamic Running arpspoof on the MITM host will change that. We must remember to enable ip-forwarding so the MITM host will hand off the packets to the real gateway. To minimize the visibility of this attack, we will specifically target the client system: [MITM Host] % Arpspoof –t 192.168.1.77 192.168.1.1 Now we can check the client’s ARP table again to see if it worked: [Client] C:\WINDOWS>arp -a Interface: 192.168.1.77 on Interface 0x2000003 Internet Address Physical Address Type 192.168.1.1 08-00-ba-dd-fe-ed dynamic You can see that this is the MAC address of the MITM host and all traffic destined for the gateway from the client will go to the MITM host instead. This phase of the attack is complete.
[MITM Host] % dnsspoof Now to check that it is working on the client: [Client] C:\WINDOWS>ping external.host.com Pinging external.host.com [192.168.1.210] with 32 bytes of data: … It is working, external.host.com is reported to have the IP of the MITM host.
Summary It is hard to study dsniff without being at least slightly troubled by the ease at which you can gather passwords, emails, files, and eavesdrop on encrypted connections, even on switched networks. This paper has demonstrated some of these cases and hopefully provides some of the perspective on these problems that real penetration testing provides. Of course, these vulnerabilities are not the fault of dsniff or its author and if dsniff causes a greater concern for the basic security of network architectures, application protocol design, and public-key infrastructure then it will have done a service for us all. References: Drury, Jason. "Sniffers: What they are and How to Protect From Them." 11 November 2000. http://www.sans.org/infosecFAQ/switchednet/sniffers.htm Song, Dug. "dsniff." Seifreid, Kurt. "The End of SSH and SSL?
Follow-up." 22 December 2000. Song, Dug. "dsniff Frequently Asked Questions." Saso. "Re: Cisco Catalyst switches." 13 June
2000. Netscape Communications, Inc. "Introduction to
Public-Key Cryptography." Tatham, Simon. "PuTTY: A Free Win32 Telnet/SSH
Client." |
|||||||||||||||||||||||||||||||||