Sniffing and spoofing are security threats that target the lower layers of the Networking infrastructure supporting applications that use the Internet. Users do not interact directly with these lower layers and are typically completely unaware that they exist. Without a deliberate consideration of these threats, it is impossible to build effective security into the higher levels. Sniffing is a passive security attack in which a machine separate from the intended destination reads data on a network. The term “sniffing” comes from the notion of “sniffing the ether” in an Ethernet Network and is a bad pun on the two meanings of the word “ether.” Passive security attack are those that do not alter the normal flow of data on a communication link or inject data into the link.

Spoofing is an active security attack in which one machine on the network masquerades as a different machine. As an active attack, it disrupts the normal flow of data and may involve injecting data into the communications link between other machines. This masquerade aims to fool other machines on the network into accepting the impostor as an original, either to lure the other machines into sending it data or to allow it to alter data. The meaning of “spoof” here is not “a lighthearted parody,” but rather “a deception intended to trick one into accepting as genuine something that is actually false.” Such deception can have grave consequences because notions of trust are central to many networking systems. Sniffing may seem innocuous (depending on just how sensitive and confidential you consider the information on your network), some network security attacks use sniffing as a prelude to spoofing. Sniffing gathers sufficient information to make the deception believable.

Sniffing

Sniffing is the use of a network interface to receive data not intended for the machine in which the interface resides. A variety of types of machines need to have this capability. A token-ring bridge, for example, typically has two network interfaces that normally receive all packets traveling on the media on one interface and retransmit some, but not all, of these packets on the other interface. Another example of a device that incorporates sniffing is one typically marketed as a “network analyzer.” A network analyzer helps network administrators diagnose a variety of obscure problems that may not be visible on any one particular host. These problems can involve unusual interactions between more than just one or two machines and sometimes involve a variety of protocols interacting in strange ways.

Devices that incorporate sniffing are useful and necessary. However, their very existence implies that a malicious person could use such a device or modify an existing machine to snoop on network traffic. Sniffing programs could be used to gather passwords, read inter-machine e-mail, and examine client-server database records in transit. Besides these high-level data, lowlevel information might be used to mount an active attack on data in another computer system.

Sniffing: How It Is Done

In a shared media network, such as Ethernet, all network interfaces on a network segment have access to all of the data that travels on the media. Each network interface has a hardware-layer address that should differ from all hardware-layer addresses of all other network interfaces on the network. Each network also has at least one broadcast address that corresponds not to an individual network interface, but to the set of all network interfaces. Normally, a network interface will only respond to a data frame carrying either its own hardware-layer address in the frame’s destination field or the “broadcast address” in the destination field. It responds to these frames by generating a hardware interrupt to the CPU. This interrupt gets the attention of the operating system, and passes the data in the frame to the operating system for further processing.

Note: The term “broadcast address” is somewhat misleading. When the sender wants to get the attention of the operating systems of all hosts on the network, he or she uses the “broadcast address.” Most network interfaces are capable of being put into a “promiscuous mode.” In promiscuous mode, network interfaces generate a hardware interrupt to the CPU for every frame they encounter, not just the ones with their own address or the “broadcast address.” The term “shared media” indicates to the reader that such networks broadcast all frames—the frames travel on all the physical media that make up the network.

</a>

At times, you may hear network administrators talk about their networking trouble spots— when they observe failures in a localized area. They will say a particular area of the Ethernet is busier than other areas of the Ethernet where there are no problems. All of the packets travel through all parts of the Ethernet segment. Interconnection devices that do not pass all the frames from one side of the device to the other form the boundaries of a segment. Bridges, switches, and routers divide segments from each other, but low-level devices that operate on one bit at a time, such as repeaters and hubs, do not divide segments from each other. If only low-level devices separate two parts of the network, both are part of a single segment. All frames traveling in one part of the segment also travel in the other part.

The broadcast nature of shared media networks affects network performance and reliability so greatly that networking professionals use a network analyzer, or sniffer, to troubleshoot problems. A sniffer puts a network interface in promiscuous mode so that the sniffer can monitor each data packet on the network segment. In the hands of an experienced system administrator, a sniffer is an invaluable aid in determining why a network is behaving (or misbehaving) the way it is. With an analyzer, you can determine how much of the traffic is due to which network protocols, which hosts are the source of most of the traffic, and which hosts are the destination of most of the traffic. You can also examine data traveling between a particular pair of hosts and categorize it by protocol and store it for later analysis offline. With a sufficiently powerful CPU, you can also do the analysis in real time.

Most commercial network sniffers are rather expensive, costing thousands of dollars. When you examine these closely, you notice that they are nothing more than a portable computer with an Ethernet card and some special software. The only item that differentiates a sniffer from an ordinary computer is software. It is also easy to download shareware and freeware sniffing software from the Internet or various bulletin board systems.

The ease of access to sniffing software is great for network administrators because this type of software helps them become better network troubleshooters. However, the availability of this software also means that malicious computer users with access to a network can capture all the data flowing through the network. The sniffer can capture all the data for a short period of time or selected portions of the data for a fairly long period of time. Eventually, the malicious user will run out of space to store the data—the network I use often has 1000 packets per second flowing on it. Just capturing the first 64 bytes of data from each packet fills up my system’s local disk space within the hour.

Note: Esniff.c is a simple 300-line C language program that works on SunOS 4.x. When run by the root user on a Sun workstation, Esniff captures the first 300 bytes of each TCP/IP connection on the local network. It is quite effective at capturing all usernames and passwords entered by users for telnet, rlogin, and FTP.

TCPDump 3.0.2 is a common, more sophisticated, and more portable Unix sniffing program written by Van Jacobson, a famous developer of high-quality TCP/IP software. It uses the libpcap library for portably interfacing with promiscuous mode network interfaces. The most recent version is available via anonymous FTP toftp.ee.lbl.gov.

NetMan contains a more sophisticated, portable Unix sniffer in several programs in its network management suite. The latest version of NetMan is available via anonymous FTP to ftp.cs.curtin.edu.au in the directory /pub/netman. EthDump is a sniffer that runs under DOS and can be obtained via anonymous FTP fromftp.eu.germany.net in the directory /pub/networking/inet/ethernet/.

Sniffing: How It Threatens Security

Sniffing data from the network leads to loss of privacy of several kinds of information that should be private for a computer network to be secure. These kinds of information include the following:

Passwords
Financial account numbers
Private data
Low-level protocol information

The following subsections are intended to provide examples of these kinds.

Sniffing Passwords

Perhaps the most common loss of computer privacy is the loss of passwords. Typical users type a password at least once a day. Data is often thought of as secure because access to it requires a password. Users usually are very careful about guarding their password by not sharing it with anyone and not writing it down anywhere.

Passwords are used not only to authenticate users for access to the files they keep in their private accounts but other passwords are often employed within multilevel secure database systems. When the user types any of these passwords, the system does not echo them to the computer screen to ensure that no one will see them. After jealously guarding these passwords and having the computer system reinforce the notion that they are private, a setup that sends each character in a password across the network is extremely easy for any Ethernet sniffer to see. End users do not realize just how easily these passwords can be found by someone using a simple and common piece of software.

Sniffing Financial Account Numbers

Most users are uneasy about sending financial account numbers, such as credit card numbers and checking account numbers, over the Internet. This apprehension may be partly because of the carelessness most retailers display when tearing up or returning carbons of credit card receipts. The privacy of each user’s credit card numbers is important. Although the Internet is by no means bulletproof, the most likely location for the loss of privacy to occur is at the endpoints of the transmission. Presumably, businesses making electronic transactions are as fastidious about security as those that make paper transactions, so the highest risk probably comes from the same local network in which the users are typing passwords.

However, much larger potential losses exist for businesses that conduct electronic funds transfer or electronic document interchange over a computer network. These transactions involve the transmission of account numbers that a sniffer could pick up; the thief could then transfer funds into his or her own account or order goods paid for by a corporate account. Most credit card fraud of this kind involves only a few thousand dollars per incident.

Sniffing Private Data

Loss of privacy is also common in e-mail transactions. Many e-mail messages have been publicized without the permission of the sender or receiver. Remember the Iran-Contra affair in which President Reagan’s secretary of defense, Caspar Weinberger, was convicted. A crucial piece of evidence was backup tapes of PROFS e-mail on a National Security Agency computer. The e-mail was not intercepted in transit, but in a typical networked system, it could have been. It is not at all uncommon for e-mail to contain confidential business information or personal information. Even routine memos can be embarrassing when they fall into the wrong hands.

Sniffing Low-Level Protocol Information

Information network protocols send between computers includes hardware addresses of local network interfaces, the IP addresses of remote network interfaces, IP routing information, and sequence numbers assigned to bytes on a TCP connection. Knowledge of any of this information can be misused by someone interested in attacking the security of machines on the network. See the second part of this chapter for more information on how these data can pose risks for the security of a network. A sniffer can obtain any of these data. After an attacker has this kind of information, he or she is in a position to turn a passive attack into an active attack with even greater potential for damage.

NOW THE QUESTION ARISES THAT...................

Why spoofing is the number one security problem on the Internet, and how we should fight it

This article explains the widely underestimated security impact of the current lack of anti-spoofing measures on the Internet.
The Internet Protocol (IP) basically works with small portions of data called datagrams that contain a small header that is used for address information. This header contains two addresses:

The destination address.
The source address.

The first address determines where the datagram should go. The second address tells the destination where the datagram originated. In the handling of this second address there lies a problem.
Part of the merits of the IP protocol come from the fact that it is connection less, and that routers make routing actions based on destination address without any influence by the source address. This works fine on the parts of the Internet that are designed for redundancy, where filtering would in many cases be impossible, but unfortunately this way of working is deadly when used outside of the major backbone networks.
Network administrators have the choice to do source based IP filtering on their routers with so called anti-spoofing filters. Unfortunately much of the network administrators do not. Further, network hardware and OS manufacturers have the choice to make 'anti-spoofing' the default operation for their products, unfortunately non of them seem to take their responsibility on that either. It is this combination of reluctance and ignorance that is the indirect course of the fast majority of security problems on the Internet.
This article I tries to explain the full extend of the spoofing problems on Internet security, and the methods that should be taken by responsible administrators and manufacturers.

(NOTE: In this article the full technical details are kept to a minimum, and do not describe combinations with other techniques that are sometimes needed for successful spoofing. This is done in order not to make this document into a hackers guideline to spoofing. This however also means that the summary of spoofing dangers described here is not fully complete, and for example some of the techniques that are described as being only possible on shared sniffable segments for a part are also possible outside of such a context))

Spoofing combined with Sniffing

One of the best known dangers of spoofing is the use of spoofing in combination with sniffing in order to perform an attack where the sniffed data is used to craft a response that has one of the following results:

Spoof address translation in order for the machine of the spoofer to make the target believe that it is the party that is is trying to contact, examples of this form of spoofing are:

DNS spoofing: This spoofing method will convince the target machine that the machine that it wants to contact (for example www.somecompany.com) is the machine of the attacker, or in an other implementation that the name of the attacker machine is a name with elevated access rights. If for example the machine 'operator.domain.com' is allowed administrator rights on a database, this spoofing method could convince the database that the attacking machine has this name.
ARP spoofing: This spoofing method is simular to the DNS spoofing, but only one layer lower in the TCP/IP stack, and further it will also work on switched networks. With this method the attacker could convince any host or router that it is the host or router on the local network that it should forward its IP datagrams to. This method is now commonly used for sniffing switched networks.

TCP takeover: This method of spoofing will wait for the authentication phase of a TCP session to complete, and will after this insert data into the existing TCP stream.

Spoofing without sniffing

Although the spoofing techniques that are possible when combined with sniffing as described above are the best known, they are not the only dangers, in fact their impact on the overall Internet security is the low when compared with techniques that do not require sniffing.

Spoofing for untraceable DoS

DoS attacks that rely on malformed packets of connection less protocols can use IP spoofing in order to masquerade the true origin of the packets, this means that even if you are able to detect the attack, you will not be able to trace or stop it as the attacker does not need any response from the target. Blocking the IP of the attacker will not work as the attacker has the full Internet address range of IP addresses to choose from, and will only result in a DoS of the service you are trying to protect.

Spoofing as DoS weapon

The spoofing of IP can itself be used as a DoS weapon. A host that server state-full protocols will in a network without spoofing possibilities be able to set a limit the amount of state objects it maintains for a single IP address. If however the attacker is able to spoof a large amount of IP addresses, than this attacker can have the host create a large amount of state objects in order to DoS this system.

Spoofing as stealth scan method

Before an attacker will attack a specific server he will in most cases want to scan the system in order to find out as much as possible about the system. In many cases this scan could alert fire-walls, IDS systems and their administrators of a forthcoming attack, and could point the administrator to the originator of a following (basic) DDOS attack. By hiding the actual scan in a large amount of spoofed scanning datagrams from a wide range of IP addresses, the attacker will be able to hide the real scan from the administrators.

Spoofing as IDS DoS

In order to detect and stop hack attacks many companies now implement so called Intrusion Detection Systems. These systems when combined with fire-walls that support them will in the ideal case stop a hack that is in progress ones specific or generic hacking fingerprints are detected.
A problem however with IDS systems is that they have to do a wide range of CPU intensive and state-full protocol analysis. Datagrams can be crafted to use a maximum amount of IDS resources (state objects and cpu) per byte of datagram. By using again a large amount of spoofed IP addresses, and by again using this to create as much as possible state objects on the IDS system, combined with large strains on the IDS to do the full set of protocol analysis it will in many cases be possible to heighten the latency of the IDS detection to such an extend that the full attack can be implemented before the IDS has been able to detect it.

Spoofing and DoS of fire-walls

In many cases IDS and firewall systems will be able to early detect attacks. A firewall might take action on this by blocking the specific suspect IP address for a period of time. However the problem of spoofing will make this solution one that not many administrators will choose to implement. This point is the point that makes me conclude that spoofing is 'the' number one problem in Internet security.

"When you implement strict fire-walling, than spoofing possibilities will make these strict rules become DoS vulnerabilities themselves.

If a firewall would block any IP that initiates an attack, an attacker that would spoof a large range of IP addresses will be able to let the firewall become a DoS tool.
In fact this means in the current 'highly spoofable' Internet you have a difficult choice between two possibilities:

Being potentially penetratable
Being highly DoS-able

Taking this into account, and taking into account that most ISP's and manufacturers don't take anti-spoofing measures so serious as to warrant them to implement them, the only thing to conclude is that there is a large underestimation of the spoofing problem both with system administrators and with router and OS manufacturers.

Anti spoofing measures

Spoofing is nothing new, spoofing measures are also nothing new, however the major growth of the Internet has resulted in a large amount of office network administrators, that never had to worry about spoofing moving to a internetwork administration. This combined with the fact that many of the anti-spoofing rules that could be implemented implicitly by routers and hosts are not accounts for the fact that an extreme large portion of the Internet is at this moment a possible source of spoofed datagrams.
When looking at the security implementations the available simple anti-spoofing measures could have if implemented globally, it is essential that the responsible people are educated about their responsibility and possibilities

Border router filter rules

Much of the anti-spoofing rules could reside on the border routers of ISP's. The principle is simple, the ISP knows its own networks, in general all the ISP has to do on the border routers is put in the following rules:

Don't let anything out with a source IP address not belonging to the ISP
Don't let anything in with a source IP address belonging to the ISP

The first one is basically the most important, it is also described in rfc2827as 'the' way to fight DoS attacks, but as this article shows its implementation has a much wider impact. rfc3013 describes these measures also in a somewhat broader perspective, unfortunately not many ISP's seem to be aware of these RFC's.

Access router filter rules

Next to the border routers the access routers could also be used in order to prevent IP spoofing at its most common source, these filters however can be sometimes tricky when combined with some dynamic IP and 'multi-POP' static IP routing. If implemented well however these filters can completely prevent IP spoofing that originates from an access network.

Tools for auditing router spoofing filters

In order to test and educate I have created a simple set of perl scripts that can test the anti-spoofing filters between two test points.

SPOOFAUDIT

Anti spoofing for shared-segments

Next to cross-network spoofing, any network that uses shared-segment technologies is vulnerable to L2 spoofing specific to these types of networks.

Static ARP tables

The ARP protocol is a protocol that is used on shared segments in order to 'map' IP addresses to MAC addresses. This protocol is particular vulnerable due to the fact that it makes use of broadcasts, and has not a single form of authentication in the protocol. Basically when a system needs to send a IP datagram, it will look to see if the IP address is in its current ARP table. If it is not it will broadcast an ARP request on the shared segment, and will bind the IP address to the MAC address mentioned in the ARP response it receives on this.
The use of spoofed ARP responses makes it possible for an attacker to disrupt the network, but more than that makes it possible for the attacker to implement a simple man-in-the middle attack, or in its simplest form to sniff a switched network that would otherwise be non-sniffable.
If hosts and routers implement Static ARP tables this problem can be prevented.

ARP table based MAC/IP filtering

The use of static ARP tables takes away much of the impact of the shared-segment spoofing, but one important point still remains. Most operating systems do not (at least not by default) check if a received IP datagram originated from a MAC address that makes any sense.
The use of the (static) ARP table in combination with the routing table could prevent most of the shared-segment spoofing possibilities. For this the following rules should be followed:

Local IP datagram IP source addresses should match the MAC addresses in the static ARP table.
Non-local IP datagrams should match the MAC address of one of the 'known routers' that has a valid route entry in the routing table.

The use of these filters is unfortunately not possible in the majority of operating systems, it is however crucial to the security of insecure shared-segment networks that this solution is implemented.

MAC locking

Next to the spoofing of ARP in order to remap an IP to an existing MAC address end the spoofing of only the IP address, it is also possible for an attacker to spoof both the IP and the MAC address.
Most modern shared-segment switches fortunately have a security feature called 'MAC locking'. This feature makes it possible to lock a MAC address to a specific physical port of the switch. This combined with static ARP and MAC/IP filters could totally eradicate the spoofing possibilities on a shared-segment.

Implicit anti-spoofing rules

One of the major reasons why most of the above anti-spoofing measures are not taken on a large portion of the Internet is the fact that the OSses that implement them all require 'explicit' configuration of the filters. It is however very good possible to implement a large portion of the anti-spoofing filters to be implemented implicitly by the operating system as a result of other configuration actions.
This will not completely close all the spoofing gaps, it will however close the most influential part of them, without any security competence required from the end users.

Implicit ingress/egress router filters

For a router the most simple rule for anti-spoofing would be:

If there is no route in one direction, assume there is no route in the  other direction.

Although this rule will not always be completely trough, the number of components where it is not true is much and much smaller than the number of routing components where this is a valid assumption.
If router manufacturers would implement this rule as default it would prevent most of the spoofing on the Internet.

Implicit partial static ARP tables

Although full static ARP tables may not be possible as implicit configuration, a partial implementation will also improve the security of shared-segment networks. based on the assumption that:

Routers are rather statical components in a network infrastructure

It will be valid for any host to assume the MAC address of the system configured as router will remain valid for a very large period of time, in particular on networks that only have one or two 'default gateways' and no further routers. Taking this into account it should be considered valid if the operating system would store the ARP table entries of the IP addresses that have routing table entries, and implicitly bind the system configuration of routing table entries to the maintenance of a partial static ARP table.

Implicit MAC/IP filtering

The implementation of the partial static ARP tables can be combined with the assumption from the Implicit ingress/egress router filters that:

If there is no route in one direction, assume there is no route in the  other direction.

This would mean that any external IP should originate from one of the MAC addresses that belongs to an entry in the routing table that has got a matching route to the originating IP address.
Further when combined with the (dynamic or static) ARP table, any 'local' IP address that does have an entry in the ARP table should not be accepted from any other MAC address.

Packet Sniffing and Spoofing

Overview

Packet sniffing and spoofing are the two important concepts in network security; they are two major threats

in network communication. Being able to understand these two threats is essential for understanding security

measures in networking. There are many packet sniffing and spoofing tools, such as Wireshark,

Tcpdump, Netwox, etc. Some of these tools are widely used by security experts, as well as by attackers.

Being able to use these tools is important for students, but what is more important for students in a

network security course is to understand how these tools work, i.e., how packet sniffing and spoofing are

implemented in software.

The objective of this lab is for students to master the technologies underlying most of the sniffing and

spoofing tools. Students will play with some simple sniffer and spoofing programs, read their source code,

modify them, and eventually gain an in-depth understanding on the technical aspects of these programs. At

the end of this lab, students should be able to write their own sniffing and spoofing programs.

Task 1: Writing Packet Sniffing Program

Sniffer programs can be easily written using the pcap library. With pcap, the task of sniffers becomes

invoking a simple sequence of procedures in the pcap library. At the end of the sequence, packets will

be put in buffer for further processing as soon as they are captured. All the details of packet capturing are

handled by the pcap library. Tim Carstens has written a tutorial on how to use pcap library to write a

sniffer program. The tutorial is available at http://www.tcpdump.org/pcap.htm. In this task, you

need to read the tutorial, play with the program sniffex included in the tutorial, read the source code

sniffex.c, and solve the following problems:

Problem 1: Please use your own words to describe the sequence of the library calls that are essential for

sniffer programs. This is meant to be a summary, not detailed explanation like the one in the tutorial.

Problem 2: Why do you need the root privilege to run sniffex? Where does the program fail if

executed without the root privilege?

Problem 3: Please turn on and turn off the promiscuous mode in the sniffer program. Can you demonstrate

the difference when this mode is on and off? Please describe how you demonstrate this.

Problem 4: Please write filter expressions to capture each of the followings. In your lab reports, you

need to include screendumps to show the results of applying each of these filters.

Capture the ICMP packets between two specific hosts.

Capture the TCP packets that have a destination port range from to port 10 - 100.

Problem 5: Please show how you can use sniffex to capture the password when somebody is using

telnet on the network that you are monitoring. You may need to modify the sniffex.c a little bit if

needed. You also need to start the telnetd server on your VM. If you are using our pre-built VM, the

telnetd server is already installed; just type the following command to start it.

Task 2: Spoofing

When a normal user sends out a packet, operating systems usually do not allow the user to set all the fields

in the protocol headers (such as TCP, UDP, and IP headers). OSes will set most of the fields, while only

allowing users to set a few fields, such as the destination IP address, and the destination port number, etc.

However, if the user has the root privilege, he/she can set any arbitary field in the packet headers. This is

essentially packet spoofing, and it can be done through raw sockets.

Raw sockets give programmers the absolute control over the packet construction, allowing programmers

to construct any arbitrary packet, including setting the header fields and the payload. Using raw sockets is

quite straightforward; it involves four steps: (1) create a raw socket, (2) set socket option, (3) construct the

packet, and (4) send out the packet through the raw socket. There are many online tutorials that can teach

you how to use raw sockets in C programming. In this task, we will not focus on any specific tutorial. Your

task is to read some of these tutorials, then either write your own packet spoofing program or download a

program from other places. After playing with these programs, please solve the following problems:

Problem 6: Please use your own words to describe the sequence of the library calls that are essential for

packet spoofing. This is meant to be a summary.

Problem 7: Why do you need the root privilege to run the programs that use raw sockets? Where does

the program fail if executed without the root privilege?

Problem 8: Please combine your sniffing and the spoofing programs to implement a sniff-and-thenspoof

program. This program monitors its local network; whenever it sees an ICMP echo request packet,

it spoofs an ICMP echo reply packet. Therefore, even if the victim machine pings a non-existing machine,

it will always see that the machine is alive. Please include screendump in your report to show that your

program works. Please also attach the code in your report.

Submission

You need to submit a detailed lab report to describe what you have done and what you have observed; you

also need to provide explanation to the observations that are interesting or surprising. Please also list the

important code snippets followed by explanation. Simply attaching code without any explanation will not

receive credits.

sniffing & spoofing

Tuesday, 30 August 2011

sniffing and spoofing