Sniffing Financial Account Numbers

Many 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. Some users simply don’t know enough to be afraid. Others knowledgeably assume the risks with the existing liability limits. Still another set of users feel secure as they place their trust in the magic of cryptography.

Despite the fact that the vast majority of systems and protocols supporting the Internet were not designed with security in mind, the most likely location for confidentiality to be compromised 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 their names, passwords, credit card numbers, expiration dates, account numbers, and Personal Identification Numbers (PINs).

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 Confidential or Sensitive Data

Loss of confidentiality is also common in e-mail transactions. Many e-mail messages have been publicized without the permission of the sender or receiver. 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. Most incidents are attributed to the lack of a clearly defined e-mail policy, user error, unstable software, administrator curiosity, and subpoenaed message backups or archives. The fact that most e-mail programs and protocols take no precautions whatsoever against sniffing is commonly overlooked.

Sniffing Low-Level Protocol Information

Information network protocols sent 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 net-work. 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.

Protocol Sniffing: A Case Study

At one point in time, all user access to computing facilities in the organization under study (the university at which the author is employed) was done via terminals. It was not practical to hardwire each terminal to the host, and users needed to use more than one host. To solve these two problems, Central Computing used a switch (an AT&T ISN switch) between the terminals and the hosts. The terminals connected to the switch so that the user had a choice of hosts. When the user chose a host the switch connected the terminal to the chosen host via a very real, physical connection. The switch had several thousand ports and was, in theory, capable of setting up connections between any pair of ports. In practice, however, some ports attached to terminals and other ports attached to hosts. Figure 5.1 illustrates this setup.

Figure 5.1  Case study system before networking.

To make the system more flexible, the central computing facility was changed to a new system that uses a set of (DEC 550) Ethernet terminal servers with ports connected to the switch, rather than the old system, which used a fixed number of switch ports connected to each host. The new terminal servers are on an Ethernet segment shared by the hosts in the central machine room.

Offices have a cable running from a wall plate to a wiring closet punchdown block. The punchdown block has cables running to multiplexers, which in turn connect to the switch. The multiplexers serve to decrease the number of cables that need to be long. With this arrangement sniffing or other forms of security problems are not an issue. No two offices share any media. The switch mediates all interaction between computers, isolating the flow of data away from the physical location of the end users (see fig. 5.2).

Figure 5.2  Case study system after networking of machine room but before net-working of user areas.

Rather than using simple terminals, however, most computer users have a computer on their desktop that they use in addition to the Central Computing computers. The switch services these computers as well as simple terminals. The number of computer users, however, has grown rapidly over the past decade and the switch is no longer adequate. Terminal ports are in short supply, host ports are in even shorter supply, and the switch does not supply particularly high-speed connections.

To phase out the switch, Central Computing installed an Ethernet hub in the basement of each building next to the punchdown block used to support both the switch multiplexor and the telephone lines. The hubs in the basements connect to the central facility using fiber-optic cables to prevent signal degradation over long distances. Hubs also were placed in the wiring closets on each floor of each building that connected to the basement hub. Now the cables leading to the wall plates in the offices are being moved from the punchdown block that leads to the multiplexor to a punchdown block that leads to one of these hubs. The new wiring scheme neatly parallels the old and was changed relatively inexpensively. Figure 5.3 illustrates the system after the networking of user areas. Figure 5.4 shows the user area networking detail.

Figure 5.3  Case study system after networking of user areas.

Figure 5.4  Case study user area networking detail.