CHAPTER

Password Replay

7

INFORMATION IN THIS CHAPTER

How Password Replay Works

Dangers of Password Replay

Defending against Password Replay

The Future of Password Replay

It seems that in 2003 (although the exact year differs in different accounts) hackers aimed an antenna at a Marshalls clothing store near St. Paul, Minnesota, in order to capture data from the store’s wireless network. By capturing network traffic and analyzing it, the hackers were able to obtain the wireless network password. Once they were in, they were able to “sniff” for other passwords on the network, eventually obtaining access to the databases of parent company TJX in Framingham, Massachusetts. Ultimately, the hackers downloaded around 94 million credit card numbers.^A They also got personal information, including Social Security numbers, for about 451,000 customers. TJX personnel discovered the intrusion in December 2006, and found files left behind by the hackers. Perhaps ironically, TJX cannot break the encryption the hackers used on the files. The cost for TJX? Aside from significant embarrassment the total cost could top $1 billion over 5 years to pay for security consultants, lawyers, and of course marketing to help reassure customers. Of course, this figure does not include potential liabilities from lawsuits.^B Who will sue? Affected banks, for one, are alleging negligence in TJX security practices. There’s also the Federal Trade Commission (FTC). Sometimes life is tough.

Much of this intrusion was accomplished using the technique of password replay. The security used on the wireless network, wired equivalent privacy (WEP), was cracked using a variant of password replay, and then passwords were captured from the unencrypted network traffic. This allowed the intruders to make their way along the TJX networks and copy out the contents of databases. Even better, they were able to install software at points in the network to “sniff” the unencrypted credit card data traveling the network.

Of course this was all years ago. On January 20, 2009, Heartland Payment Systems (HPS) announced a bigger breach. HPS employees discovered programs on their network to capture traffic. In this case, the thieves compromised an estimated 100 million credit cards. This information isn’t just the credit card numbers, but includes the full data in the magnetic stripe of the card, allowing the thieves easily to create duplicate cards.^C

The good news? It looks like the mastermind of both operations has been caught. Albert Gonzalez has pleaded guilty.^D He leaves behind a record of computer break-ins and $1.1 million in cash discovered wrapped in plastic and buried in a drum in his parents’ backyard.^E Again, sometimes life is tough.

HOW PASSWORD REPLAY WORKS

It’s 1995, and you’re sitting in your office arguing in an online newsgroup about the new show Star Trek: Voyager. Your “friend” Rob stops by and you chat for a while. Before he leaves Rob asks if he can use your terminal to check his e-mail. “Sure,” you tell him. Rob logs in, checks his e-mail, and the logs out. Or so it seems.

After Rob leaves you decide to log in and check out this new online bookstore you’ve heard about. You log in, and you are told your password is incorrect. You’ve mistyped it before, so you type it again, and it is accepted. After visiting the bookstore’s Web site you decide “Hmph. You can’t actually flip through the books, and the Web is too insecure. This will never catch on.”

Not only are you wrong about the bookstore but also Rob now has your password. You’ve just been the victim of a fake login that allowed Rob to capture your password. It’s shockingly easy to do this in most cases. For example, if you are using Ubuntu 9.10 and use console login instead of the graphical login, then the script shown in Figure 7.1 will emulate the log-in prompt, capture the next username and password, report that the password is in error, and then terminate itself. The end result looks just as it should. People happily accept that they have mistyped their password once, and so no suspicion is aroused.

You’d log in on the first text console (named “tty1”) and run this script. The effect is as if you had logged out; but of course, you haven’t. The script prints an official-looking log-in prompt and captures the username and password (character echo is turned off for the password so that things appear correct). The script then claims you have entered the wrong credentials, saves what you did enter, and kills itself and your log-in shell. Presto! You’re logged out and the data is captured. Your victim now gets a real log-in prompt and can log in.

FIGURE 7.1
A Very Simple Fake Login

University computer labs used to be (and some still are) full of UNIX workstations with console logins, and this was a not-too-uncommon occurrence. There are advantages to having a login that is not your own, especially if you are planning to do something dastardly. System administrators would sometimes watch for unoccupied machines with someone still logged in; it could be someone who forgot to log out, or something more nefarious. The “solution” to these watchful eyes is trivial social engineering: wait until the lab is full, start the program, and then kindly hand off the terminal to the next person who is waiting. The script logs you out and then the other person logs in; everything is just as it should be. Well, mostly.

Although this isn’t an example of a network attack, it illustrates an important point about security. Passwords are typically static and trusted. That is, they don’t change (at least, not very often), and they often serve as a single point of authentication that you are who you say you are. They are similar to physical keys or proximity cards (“prox cards” or “key cards”) in this regard. If you have the key or the proximity card (or a duplicate), you have access.

The important distinction between passwords and physical keys or proximity cards is that the latter is intended to prevent physical trespass; you have to go to the location, and there may be guards who do not recognize your face, cameras to take your picture, and suspicious employees. You probably have to get dressed. Life is sometimes tough. Passwords prevent virtual trespass, and you may be able to accomplish this from the (relative) comfort of your parent’s basement while wearing your bathrobe. Another important distinction is that the information you really, really want is likely stored on computers, anyway. Why get off the couch if you don’t have to?

Simple Password Sniffing

One way to capture passwords on a network is to capture and decode network packets. As discussed in Chapter 5, “Spanning Tree Attacks,” Wireshark,^H tcpdump, and libpcap^I can be used to capture packets. If you have access to a node through which the packets will travel, and the passwords are unencrypted, you can capture them very easily. Note that this is a form of the “man in the middle” attack detailed in Chapter 6, “Man-in-the-Middle.”

This method of password capture assumes two things are happening.

1. Static password authentication is required.

2. Passwords are being sent as “clear text,” that is, unencrypted.

Surely nobody would do this, you might say. Well, they do. For example, this might be done if the communication channel is itself encrypted, as with a virtual private network (VPN). This works great to secure traffic between your machine and a remote network; traffic passing through intermediate nodes is encrypted. It does not work so well if someone has access to the remote network or, in some cases, to your machine. Once someone breaks into the remote network by some means (see the rest of this book) then they can sniff packets and look for clear text passwords. This gives them access to other accounts, possibly to other data, and perhaps even to your accounts on other networks. Do you use different passwords for all your accounts? Do you ever reuse old passwords? If somebody has a list of the passwords you used last year they can use these to start guessing your current passwords.

Running a tool like Wireshark on a network node and watching for Post Office Protocol (POP) or Simple Mail Transfer Protocol (SMTP) traffic^K can often reveal interesting data. Of course, combing through all the captured traffic can be burdensome. Can’t someone automate that task for us? Of course they can. EffeTech makes a commercial password sniffer called Ace Password Sniffer,^L and NirSoft SniffPass^M is a freeware utility that captures packets and watches for passwords in commonly used protocols. These are just two; a quick Web search for “password sniffer” can turn up many, many more. These are typically advertised as a way to recover lost passwords or monitor children on the Internet, but as with most tools, they have other uses.

All these depend on your ability to “sniff” the traffic. That is, the traffic has to pass through (or be available to) your machine. There are a variety of ways to get the traffic. The most straightforward is just to install the password sniffer (or a traffic-capture program like tcpdump) on a gateway or proxy server. You can then watch all the traffic passing through the machine on its way to and from the Internet. It may even be possible to modify a network’s topology (see Chapter 5, “Spanning Tree Attacks”) so that your machine receives all traffic. You can only sift through the traffic you actually see, after all.

Of course, sometimes people decide to broadcast all their packets to the world. The mechanism to accomplish this heightened level of insecurity is called “wireless networking,” and you can often find unencrypted wireless networks in coffee and sandwich shops. Although you might not be able to break into some well-secured corporate network, you might discover that the vice-president has an unsecured (or poorly secured) wireless network at home, and he tends to use the same passwords for everything, from his corporate e-mail to protecting his VPN certificates. Using his e-mail account, you might even compose angry e-mails “from him” to the corporate IT department. Who knows what you might accomplish this way?

Password Replay

You’ve got the access to a switch that is carrying your “friend” Rob’s Internet traffic, and you are happily collecting packets. You see that he occasionally connects to a remote site and you are sure he is busy extolling the virtues of Kirk as captain of the Enterprise and running down your recent postings about Picard. You have to know for sure, but you can’t capture any clear-text passwords. The system he is using encrypts his credentials when he sends them, so you can’t just grab them from the network traffic. What can you do?

You may be able to replay the packets. Replay attacks work by first recording an authentication session, and then playing that session back at a later time. Using this strategy you may be able to observe Rob’s authentication session, and then replay the recorded packets at a later time to gain access as if you were Rob.

Recording and playing back packets sounds like something that requires programming. Luckily there are ready-made tools such as tcpreplay^N to automate most of this process for you. Actually, “tcpreplay” is a suite of tools for classifying, editing, and replaying network traffic. These tools work from a “pcap” file containing captured traffic, created with another tool like tcpdump. The tools are quite sophisticated.

“Sophisticated” might sound like another word for “hard to use.” All you want to do is get Rob’s password. Do you really have to capture traffic, sift through it to find the kind of packets you want, extract those (you can use tcpdump to refilter an existing pcap file), classify the packets so you get the client (Rob’s) traffic, edit the traffic if necessary to modify the IP addresses, and then replay the traffic? Whew! Stealing—I mean, “recovering” passwords from network traffic must be a common activity. Isn’t there an easier way?

Of course there is. One of the best tools around for this sort of work is a freeware tool called Cain & Abel. This is one of those cases where Windows users have an exceptionally powerful tool that really isn’t available for other operating systems. After you’ve downloaded and installed Cain & Abel (but see the TIP box first!) you are ready to begin capturing passwords, conversations, and other network traffic.

Replay is another exploitation of a static (or at least predictable) authentication system. If the challenge and response depend on a sequence number that is not predictable by the eavesdropper, then password replay will probably fail. In fact, including a cryptographic sequence number is the most common means to prevent password replay attacks. Given this, you might think that practical password replay is a nonstarter—but you’d be wrong. Many systems are susceptible to replay attacks. You may have some of these systems in your infrastructure right now.

What about encrypted traffic and passwords, or protocols using sequence numbers? It might be surprising to know that these can also fall prey to replay attacks for several reasons:

• The protocol might be cryptographically weak.

• The protocol might have a fundamental weakness that exposes credentials.

• It may be possible to use a man-in-the-middle attack to overcome the encryption.

An example of a cryptographically weak protocol is WEP,^O a protocol used to secure wireless networks. Sadly, the protocol is constructed in such a manner that it is possible to quickly break the encryption by capturing special packets called initialization vectors (IV). This attack was used in the TJX break-in described at the start of this chapter.^P Several tools exist that can be used to sniff packets, collect IVs, and then crack the wireless password. Because it can take a while to collect enough packets, these tools commonly support packet injection, where the attacking machine generates traffic to cause the wireless hub to generate new IVs. The Aircrack-ng tools^Q provides wireless network cracking under Windows and Linux for WEP, as well as the more modern wi-fi protected access (WPA). Mac users have the KisMAC tool.^R Figure 7.2 shows KisMAC running and collecting packets for several networks. Once enough packets have been captured, the cleartext WEP password can be cracked.

FIGURE 7.2
KisMAC

Server Message Block (SMB) is a protocol for network communication between network nodes and to shared devices such as printers. SMB is the application-layer network protocol of the Microsoft Windows network and is used throughout the Windows world. NT LAN Manager (NTLM) is an authentication protocol used with SMB in Windows versions earlier to Vista. (It is still present in Vista, but deprecated. Kerberos^S is the new authentication system.) There is a chance that, at the time of writing, your infrastructure may still be using a version of this authentication protocol with a fundamental weakness: it honors remote requests for authentication. Suppose you receive an e-mail from your “friend” Rob inviting you to join a Kirk vs. Picard discussion, and providing you a link. You immediately click on the link to give everyone the benefit of your opinion. When you click the link, you are connected to a server that requests that you (the client) authenticate yourself using NTLM. NTLM responds by happily sending your credentials to the server, which stores them. Later Rob logs into your machine with the stolen credentials and changes your desktop wallpaper to an image of Picard and even goes so far as to delete your fan script. People can be so mean.

EPIC FAIL

SMB has been known to be “broken” since 2001, but changing a network protocol is a nontrivial matter. Lots of devices and network-based applications depend on the protocol implementation, and changing them all at once isn’t really an option. You don’t want your e-mail to quit working, do you? Microsoft kept working on a way to fix the problem, eventually releasing patch MS08-068T in November 2008. So you only had 7 years to exploit this particular vulnerability. Of course, it took until July 2007 to implement the exploit in the Metasploit 3 framework.U At the time of writing, there are other outstanding security issues that Microsoft is currently working on. As you read this, that is probably still true.

Finally, it is possible to use a variant of the man-in-the-middle attack to capture and replay passwords even in the presence of encryption. Precisely how to do that is the subject of the following section.

Address Resolution Protocol Poison Routing

In Figure 7.3, Alice wants to connect to the server out on the Internet. Her traffic flows through the gateway, to which Eve is also connected. We see the Internet Protocol (IP) and media access control (MAC) addresses for the machines. Chapter 5, “Spanning Tree Attacks,” discusses exploiting the Spanning Tree Protocol, a “layer 2” protocol. Another layer 2 protocol is the Address Resolution Protocol (ARP). ARP is used to map between IP addresses and MAC addresses. Although a network card might be assigned any of several IP addresses over the course of its life, it (typically) has a single permanent MAC address.^V

Alice wants to communicate with the server, but it is on a different network. She therefore sends her traffic to the gateway with IP 10.1.2.1. Her machine’s ARP tables indicate that this IP address belongs to the machine with MAC address 00:00:00:A1:B2:C3. The gateway then takes care of forwarding the traffic on to the Internet. Likewise, packets arriving at the gateway for Alice’s machine are mapped to MAC address 00:00:00:01:01:01.

FIGURE 7.3
Preparing to Eavesdrop

Eve wants to listen to the traffic between Alice and the server (or between Alice and the whole Internet, for that matter). To accomplish this, Eve uses ARP “poisoning,” sometimes (confusingly) referred to by the acronym APR for ARP poison routing. Eve sends out an ARP update to Alice’s machine at 00:00:00:01:01:01 pointing the IP address 10.1.2.1 to Eve’s MAC address 00:00:00:11:22:33, and Alice’s machine dutifully stores this in its cache. Eve then sends out an ARP update to the gateway machine at 00:00:00:A1:B2:C3 pointing the IP address 10.1.2.3 to Eve’s MAC address 00:00:00:11:22:33. Eve’s machine can still route traffic to the gateway and to Alice’s machine using the correct MAC addresses. Now Alice’s machine thinks Eve’s machine is the router, and the router thinks Eve’s machine is Alice’s.

Alice wants to log into the server, so she sends a request to the server. The server is on a different network, so her machine determines that it needs to be sent to the gateway at IP 10.1.2.1. Alice’s machine looks in the ARP cache and finds MAC address 00:00:00:11:22:33, and sends the packets to that MAC address. In this case, the gateway is connected to Eve’s machine, but the packets are labeled for 00:00:00:11:22:33, so the gateway sends them on to Eve’s machine. Eve can now modify the packets however she wants and then send them to the gateway at MAC address 00:00:00:A1:B2:C3. The gateway is the destination for these packets, so it examines them, and determines whether they should be sent on to the Internet.

Next the server replies to Alice. Packets arrive at the gateway destined for IP address 10.1.2.3. The gateway looks in its ARP cache and determines that this IP address belongs to the machine with MAC address 00:00:00:11:22:33. It then sends the packets on to Eve’s machine. Eve is now free to modify the packets however she wishes, and then she sends the modified packets on to MAC address 00:00:00:01:01:01. The gateway receives these packets that are not for it, and dutifully forwards them on to Alice’s machine. Eve has successfully become the (wo)man in the middle.

Now, Alice wants to establish a secure communications channel, say with hypertext transfer protocol secure (HTTPS). The following things would typically happen:

1. Alice creates an HTTPS request and sends it to the remote server.

2. The server responds, identifying itself with a cryptographic certificate.

3. Alice’s browser checks that the certificate (a) is valid for the original Web address, and (b) has a chain of trust to some well-known and trusted third party, whose public certificate is stored in the browser.

4. Alice and the server are now ready to communicate using the encrypted HTTPS channel for their traffic.

What really happens is illustrated in Figure 7.4. Alice’s request goes to Eve’s machine. Eve then forwards it on to the server, which uses its own private certificate C1 to create a reply. Eve’s machine intercepts this, strips out the server’s signature and uses her own private certificate C2 to create a new reply to Alice. Alice receives this and communications are achieved. All traffic from Alice to Eve is encrypted, and all traffic from Eve to the server is encrypted. But Eve now has the ability to decrypt all traffic in either direction, and read information such as passwords.

There is a weakness to this strategy. Eve can construct a certificate C2 that purports to identify the server 10.2.1.43, but it is not likely that she can get it signed by a trusted third party. For example, a company like VeriSign^W or GeoTrust^X might have some questions as to why you want a certificate identifying you as, say, PayPal. When Alice connects, her browser will try to warn her, as shown in Figure 7.5.

FIGURE 7.4
Eavesdropping Achieved

FIGURE 7.5
You Were Warned

FIGURE 7.6
Password Capture with Cain & Abel

The message “intercept any data you send” is a strong hint as to what is happening. Of course, there are many sites out there with “self-signed” certificates, meaning they use certificates that are not signed by a trusted third party. People may be quick to assume that all is well, and just click the continue to this website link. After all, what’s the alternative? Not checking your bank balance? You need to know! And after all, isn’t your bank’s security their job?

If implementing ARP poisoning sounds very hard to you, take heart. Conversely, if you think it is too hard to worry about it—well, many password sniffers, including Cain & Abel, implement ARP poison routing in a convenient manner.^Y For Cain & Abel, this comes down to making sure that the tool is set up correctly and then clicking a single button to enable ARP poisoning. In Figure 7.6, Cain & Abel has been used to capture the password “N.izYi!q6UkB” – a very strong password – from an Internet Explorer 7 session.

DANGERS OF PASSWORD REPLAY

Password capture and replay poses a very serious threat to network security, and can be very difficult to guard against because it requires that people choose good passwords, keep track of them in a secure manner, do not fall prey to social engineering schemes, and are vigilant when using secure communications.

One immediate danger is that capturing a password on an otherwise innocuous site such as a personal Web mail provider could lead to compromise of other accounts because of password reuse. For example, corporate policy might require strong passwords changed relatively frequently. It is unlikely that Rob’s Web mail password is the same as his password to the payroll system because he’s required to change the latter. However, his VPN might use a certificate secured by the same password he uses for his Web mail. This might allow an attacker to get into his secure corporate e-mail, and from there an attacker might be able to get Rob’s payroll password reset. If IT trusts sending passwords in encrypted e-mails that do not pass outside the secure corporate network, this strategy might work.

Replay attacks have dangers of their own because, as with software exploits, you may not know about them as soon as the bad guys do. Worse, if the protocol is itself weak, it may be days, months, or even (as illustrated by the NTLM case described earlier) years before the vulnerability is fixed. Critical infrastructure may depend on the protocol, so just disabling it is not an option.

Many protocols depend on cryptographic hashes for security. As time goes by, these hashes (SHA1, MD5, and so on) are studied and eventually may be cracked. Again, replacing the cryptographic hash at the core of a secure protocol is a nontrivial matter.

DEFENDING AGAINST PASSWORD REPLAY

Several proven technologies exist to avoid password capture and password replay attacks, but one of the most basic ways to resist password theft is to avoid the use of a single, static authentication token whenever possible. Although this is not always possible, it does provide the best means of security.

One method is for the user and the authentication system to augment a shared, static secret like a password with a dynamic, or changing, shared secret. The two must be properly combined in order to gain access. An example of this is the RSA SecurID.^Z This uses a tamper-resistant device containing a clock synchronized to the server’s clock. A shared key is used to generate a sequence of numbers; without the key, the number sequence is nearly impossible to predict from just a few observations. Each number is displayed and is valid for a period of time, and then a new number is generated. When a user wants to log in, they enter a fixed static secret like a password, and combine this with the current number displayed by the SecurID. Someone capturing packets would not be able to replay the authentication later on because the number used would no longer be valid. Even if the attacker got either the user’s password or the SecurID device, they would still need the other piece of information to be able to gain entry. Although this is an excellent approach, it can also fall prey to the man-in-the-middle attack. The credentials cannot be permanently compromised, but the secure session can be hijacked using a technique like ARP poisoning.

Another authentication technique is to use one-time passwords. In this case, at login the server generates a challenge. The user looks up the challenge, say on a printed card, and enters the correct response. Each challenge/response pair is good for exactly one login. This is a very strong system, and can be combined with a static password so that loss of the card containing the challenge/response pairs would not compromise the system. Again, this can fall prey to a man-in-the-middle attack that hijacks an existing session. A one-time password system that is common on UNIX and Linux systems and is completely software-based is the S/KEY system.^AA

One reason ARP poisoning attacks work is because layer two of the network does not have any built-in security. Fortunately, there are both software and hardware solutions to this problem. ArpON^BB is open-source software for detecting and blocking ARP poisoning and spoofing attacks, and it runs on Linux and UNIX, including Mac OS X. Antidote^CC is another open-source ARP poisoning detection system. Several hardware vendors, including Cisco,^DD have implemented a technique called Dynamic Host Configuration Protocol (DHCP)^EE “snooping” to detect ARP poisoning or spoofing. Finally, Arpwatch^FF attacks the problem by watching for ARP messages that reassign an IP address, and generating notifications if this happens.

ArpON can operate in two different ways to defeat ARP poisoning: static and dynamic. Static ARP inspection works by assuming the ARP cache at program start is valid, and then defending it against modification. This works well if your network consists of machines assigned with static IP addresses. Dynamic ARP inspection works by first clearing the ARP cache, and then carefully monitoring any attempts to modify it and applying rules to prevent ARP poisoning. This works well if your network consists of machines assigned with dynamic IP addresses (DHCP).

THE FUTURE OF PASSWORD REPLAY

In 2004 then Microsoft Chairman Bill Gates, in his keynote address to the RSA Security Conference, predicted the end of traditional passwords.

“There is no doubt that over time, people are going to rely less and less on passwords. People use the same password on different systems, they write them down and they just don’t meet the challenge for anything you really want to secure.”¹

A few years have passed, and we’re all still using traditional passwords. Bill was right; they are fundamentally flawed as a security measure. It also seems they are not going away any time soon.

There are just too many places you need to authenticate on the Internet. Some means is required; whether it is a password, pass phrase, or combination of questions and answers. Your Web designers and your users are all familiar with passwords, and you can’t issue special hardware to everyone who registers on your Web site.

Without careful design, protocols are susceptible to replay attacks. Even in cases where protocols are designed to be resistant to replay attacks, a weakness in the protocol (as with WEP) can render the protocol susceptible. Finally, even if the authentication portion of the protocol is resistant to replay attacks, it may still be the case that a “man in the middle” can hijack a session and use replay within the authenticated session.

Replay attacks are, in some ways, analogous to buffer overflow attacks. They can be eliminated by careful design, and one must keep this in mind when designing an authentication system or protocol. The analogy breaks down, however, when we consider systems with deployed weaknesses. Eliminating a buffer overflow exploit requires shipping a patch. The patch can be tested, and installed on a machine-by-machine basis. For replay vulnerabilities, often the protocol must be redesigned. This makes it tough to eliminate the vulnerability, as both endpoints of any potential communication session must be upgraded to compatible, resistant protocols. It may not even be possible to upgrade some legacy systems, as software is no longer being developed for them. Many network endpoints are embedded devices, and the manufacturer may delay in releasing an update, or never release an update at all.

The problem of legacy protocols is often “solved” by allowing one endpoint to downgrade to the old protocol. This is obviously a serious vulnerability. You might have updated your servers to support the newest resistant protocols, but still they have to support older versions of protocols (such as NTLM and SSH-1) because of legacy hardware and software.

Because protocols that are susceptible to replay attacks continue to be designed and deployed, and because weaknesses continue to be discovered in the cryptographic systems that are used to protect against replay attacks, it is clear that replay attacks will remain a very deadly network attack for the foreseeable future.

SUMMARY

After reading this chapter, you should have a better appreciation for the security risks of password capture and password replay. Password capture and replay is a significant, ongoing threat to the security of networks. Because traditional passwords and protocols that are susceptible to replay attacks are not going to go away any time soon, this represents a significant security risk. Further, designing protocols to resist replay attacks requires careful engineering and analysis…so we can assume that even new protocols may be susceptible to replay attacks. Once a vulnerability has been discovered in a protocol, it can be a long time before a fix is available.

Fortunately, there are technologies to help secure against these attacks. The use of one-time passwords, hard-to-guess sequence numbers, and tools like SecurID can block the usual methods of password capture and replay. Sadly, these can still fall prey to man-in-the-middle attacks, made ever easier by well-designed and maintained automated tools. The fundamental message is to evaluate how and when users can authenticate, to establish reasonable policies, and to implement network security auditing. ARP poisoning can be detected on the network using readily available tools. Even so we can expect this network attack to remain deadly for a long time to come.

Endnote

1. See Kotadia M. Gates Predicts Death of the Password, CNET News, February 25th, 2004. Available online at http://news.cnet.com/2100-1029_3-5164733.html; (accessed 2/28/2010).

^AFor the 94 million figure, see Ross Kerber, “Court Filing In TJX Breach Doubles Toll,” Boston Globe, October 24, 2007.

^BThere are many articles on the TJX break-in. In particular, see “How Credit-Card Data Went Out Wireless Door,” The Wall Street Journal, May 4, 2007.

^CRachael King, “Lessons From the Data Breach at Heartland,” BusinessWeek, July 6, 2009.

^D“Man Accused of Stealing Stores’ Data Pleads Guilty,” (REUTERS), The New York Times, August 28, 2009.

^EScott Hiaasen, Rob Barry, Nirvi Shah, and Michael Sallah, “From Snitch to Cyberthief of the Century,” The Miami Herald, August 22, 2009.

^FSee http://sourceforge.net/projects/pgina/.

^GA fake Google mail (Gmail) login is described at http://www.trap17.com/index.php/fake-gmail-interface_t57079.html (retrieved on December 1st, 2009). The interesting thing about this fake login is just how similar it is to the UNIX command-line attack described previously in this section. After the fake login captures your credentials, it forwards you to the real Gmail site. Note that the fake login has long since been taken down.

^HSee http://www.wireshark.org/. Note that this tool was previously named Ethereal.

^ISee http://www.tcpdump.org/ for tcpdump (a command line tool) and libpcap (a library).

^JSee http://www.oxid.it/cain.html. Users of non-Windows operating systems should have a look at dsniff: http://www.monkey.org/~dugsong/dsniff/.

^KPOP is a very common protocol for mail delivery (getting the mail from the server to you), while SMTP is a very common protocol for sending mail (getting the mail from you to the server).

^LSee http://www.effetech.com/aps/.

^MSee http://www.nirsoft.net/utils/password_sniffer.html.

^NSee http://tcpreplay.synfin.net/trac/.

^OSee IEEE standard 802.11-1997.

^PSee Larry Greenemeier, “T.J. Maxx Data Theft Likely Due to Wireless ‘Wardriving,’” EE Times, May 9^th, 2007. http://www.eetimes.com/.

^QSee http://www.aircrack-ng.org/.

^RSee http://kismac-ng.org/.

^SKerberos is a very common authentication protocol under Windows, Linux, and UNIX, including OS X. See http://web.mit.edu/Kerberos/.

^TSee http://www.microsoft.com/technet/security/Bulletin/MS08-068.mspx.

^USee http://www.metasploit.com/. Metasploit was created in 2003, so it only took four years to get around to writing that particular exploit.

^VOf course, “permanent” here takes on its computer science meaning of “not really permanent.” That is, it is possible to assign the card a different MAC address. This is called MAC “spoofing,” and it has a variety of benevolent and malevolent uses.

^WSee https://www.verisign.com/index.html.

^XSee http://www.geotrust.com/.

^YAnd dsniff does, too. See the arpspoof tool that is part of the dsniff package. Likewise, Ettercap supports ARP poisoning, as do many other tools.

^ZSee http://www.rsa.com/.

^AAThe S/KEY One-Time Password System is described in RFC 1760. A free implementation for the Mac is available from http://www.orange-carb.org/SkeyCalc/.

^BBSee http://arpon.sourceforge.net/.

^CCSee http://antidote.sourceforge.net/.

^DDSee http://www.cisco.com/.

^EEDHCP provides a means to dynamically reserve an IP address for a host, based on the host’s MAC address.

^FFSee http://ee.lbl.gov/.