WEB SECURITY

We have just studied two important areas where security is needed: communications and email. You can think of these as the soup and appetizer. Now it is time for the main course: Web security. The Web is where most of the Trudies hang out nowadays and do their dirty work. In the following sections, we will look at some of the problems and issues relating to Web security.

Web security can be roughly divided into three parts. First, how are objects and resources named securely? Second, how can secure, authenticated connections be established? Third, what happens when a Web site sends a client a piece of executable code? After looking at some threats, we will examine all these issues.

Threats

One reads about Web site security problems in the newspaper almost weekly. The situation is really pretty grim. Let us look at a few examples of what has already happened. First, the home pages of numerous organizations have been attacked and replaced by new home pages of the crackers’ choosing. (The popular press calls people who break into computers ‘‘hackers,’’ but many programmers reserve that term for great programmers. We prefer to call these people ‘‘crackers.’’) Sites that have been cracked include those belonging to Yahoo!, the U.S. Army, the CIA, NASA, and the New York Times. In most cases, the crackers just put up some funny text and the sites were repaired within a few hours.

Now let us look at some much more serious cases. Numerous sites have been brought down by denial-of-service attacks, in which the cracker floods the site with traffic, rendering it unable to respond to legitimate queries. Often, the attack is mounted from a large number of machines that the cracker has already broken into (DDoS attacks). These attacks are so common that they do not even make the news any more, but they can cost the attacked sites thousands of dollars in lost business.

In 1999, a Swedish cracker broke into Microsoft’s Hotmail Web site and created a mirror site that allowed anyone to type in the name of a Hotmail user and then read all of the person’s current and archived email.

In another case, a 19-year-old Russian cracker named Maxim broke into an e-commerce Web site and stole 300,000 credit card numbers. Then he approached the site owners and told them that if they did not pay him $100,000, he would post all the credit card numbers to the Internet. They did not give in to his blackmail, and he indeed posted the credit card numbers, inflicting great damage on many innocent victims.

In a different vein, a 23-year-old California student emailed a press release to a news agency falsely stating that the Emulex Corporation was going to post a large quarterly loss and that the C.E.O. was resigning immediately. Within hours, the company’s stock dropped by 60%, causing stockholders to lose over $2 billion. The perpetrator made a quarter of a million dollars by selling the stock short just before sending the announcement. While this event was not a Web site break-in, it is clear that putting such an announcement on the home page of any big corporation would have a similar effect.

We could (unfortunately) go on like this for many more pages. But it is now time to examine some of the technical issues related to Web security. For more information about security problems of all kinds, see Anderson (2008a); Stuttard and Pinto (2007); and Schneier (2004). Searching the Internet will also turn up vast numbers of specific cases.

Secure Naming

Let us start with something very basic: Alice wants to visit Bob’s Web site. She types Bob’s URL into her browser and a few seconds later, a Web page appears. But is it Bob’s? Maybe yes and maybe no. Trudy might be up to her old tricks again. For example, she might be intercepting all of Alice’s outgoing packets and examining them. When she captures an HTTP GET request headed to Bob’s Web site, she could go to Bob’s Web site herself to get the page, modify it as she wishes, and return the fake page to Alice. Alice would be none the wiser. Worse yet, Trudy could slash the prices at Bob’s e-store to make his goods look very attractive, thereby tricking Alice into sending her credit card number to ‘‘Bob’’ to buy some merchandise.

One disadvantage of this classic man-in-the-middle attack is that Trudy has to be in a position to intercept Alice’s outgoing traffic and forge her incoming traffic. In practice, she has to tap either Alice’s phone line or Bob’s, since tapping the fiber backbone is fairly difficult. While active wiretapping is certainly possible, it is a fair amount of work, and while Trudy is clever, she is also lazy. Besides, there are easier ways to trick Alice.

DNS Spoofing

One way would be for Trudy to crack the DNS system or maybe just the DNS cache at Alice’s ISP, and replace Bob’s IP address (say, 36.1.2.3) with her (Trudy’s) IP address (say, 42.9.9.9). That leads to the following attack. The way it is supposed to work is illustrated in Fig. 8-46(a). Here, Alice (1) asks DNS for Bob’s IP address, (2) gets it, (3) asks Bob for his home page, and (4) gets that, too. After Trudy has modified Bob’s DNS record to contain her own IP address instead of Bob’s, we get the situation in Fig. 8-46(b). Here, when Alice looks up Bob’s IP address, she gets Trudy’s, so all her traffic intended for Bob goes to Trudy. Trudy can now mount a man-in-the-middle attack without having to go to the trouble of tapping any phone lines. Instead, she has to break into a DNS server and change one record, a much easier proposition.

How might Trudy fool DNS? It turns out to be relatively easy. Briefly summarized, Trudy can trick the DNS server at Alice’s ISP into sending out a query to look up Bob’s address. Unfortunately, since DNS uses UDP, the DNS server has no real way of checking who supplied the answer. Trudy can exploit this property by forging the expected reply and thus injecting a false IP address into the DNS server’s cache. For simplicity, we will assume that Alice’s ISP does not initially have an entry for Bob’s Web site, bob.com. If it does, Trudy can wait until it times out and try later (or use other tricks).

Trudy starts the attack by sending a lookup request to Alice’s ISP asking for the IP address of bob.com. Since there is no entry for this DNS name, the cache server queries the top-level server for the com domain to get one. However, Trudy beats the com server to the punch and sends back a false reply saying: ‘‘bob.com is 42.9.9.9,’’ where that IP address is hers. If her false reply gets back to Alice’s ISP first, that one will be cached and the real reply will be rejected as an unsolicited reply to a query no longer outstanding. Tricking a DNS server into installing a false IP address is called DNS spoofing. A cache that holds an intentionally false IP address like this is called a poisoned cache.

Actually, things are not quite that simple. First, Alice’s ISP checks to see that the reply bears the correct IP source address of the top-level server. But since Trudy can put anything she wants in that IP field, she can defeat that test easily since the IP addresses of the top-level servers have to be public.

Second, to allow DNS servers to tell which reply goes with which request, all requests carry a sequence number. To spoof Alice’s ISP, Trudy has to know its current sequence number. The easiest way to learn the current sequence number is for Trudy to register a domain herself, say, trudy-the-intruder.com. Let us assume its IP address is also 42.9.9.9. She also creates a DNS server for her newly hatched domain, dns.trudy-the-intruder.com. It, too, uses Trudy’s 42.9.9.9 IP address, since Trudy has only one computer. Now she has to make Alice’s ISP aware of her DNS server. That is easy to do. All she has to do is ask Alice’s ISP for foobar.trudy-the-intruder.com, which will cause Alice’s ISP to find out who serves Trudy’s new domain by asking the top-level com server.

With dns.trudy-the-intruder.com safely in the cache at Alice’s ISP, the real attack can start. Trudy now queries Alice’s ISP for www.trudy-the-intruder.com. The ISP naturally sends Trudy’s DNS server a query asking for it. This query bears the sequence number that Trudy is looking for. Quick like a bunny, Trudy asks Alice’s ISP to look up Bob. She immediately answers her own question by sending the ISP a forged reply, allegedly from the top-level com server, saying: ‘‘bob.com is 42.9.9.9’’. This forged reply carries a sequence number one higher than the one she just received. While she is at it, she can also send a second forgery with a sequence number two higher, and maybe a dozen more with increasing sequence numbers. One of them is bound to match. The rest will just be thrown out. When Alice’s forged reply arrives, it is cached; when the real reply comes in later, it is rejected since no query is then outstanding. Now when Alice looks up bob.com, she is told to use 42.9.9.9, Trudy’s address. Trudy has mounted a successful man-in-the-middle attack from the comfort of her own living room. The various steps to this attack are illustrated in Fig. 8-47. This one specific attack can be foiled by having DNS servers use random IDs in their queries rather than just counting, but it seems that every time one hole is plugged, another one turns up. In particular, the IDs are only 16 bits, so working through all of them is easy when it is a computer that is doing the guessing.

Secure DNS

The real problem is that DNS was designed at a time when the Internet was a research facility for a few hundred universities, and neither Alice, nor Bob, nor Trudy was invited to the party. Security was not an issue then; making the Internet work at all was the issue. The environment has changed radically over the years, so in 1994 IETF set up a working group to make DNS fundamentally secure. This (ongoing) project is known as DNSsec (DNS security); its first output was presented in RFC 2535. Unfortunately, DNSsec has not been fully deployed yet, so numerous DNS servers are still vulnerable to spoofing attacks.

DNSsec is conceptually extremely simple. It is based on public-key cryptography. Every DNS zone (in the sense of Fig. 7-5) has a public/private key pair. All information sent by a DNS server is signed with the originating zone’s private key, so the receiver can verify its authenticity.

DNSsec offers three fundamental services:

1. Proof of where the data originated

2. Public key distribution.

3. Transaction and request authentication.

The main service is the first one, which verifies that the data being returned has been approved by the zone’s owner. The second one is useful for storing and retrieving public keys securely. The third one is needed to guard against playback and spoofing attacks. Note that secrecy is not an offered service since all the information in DNS is considered public. Since phasing in DNSsec is expected to take several years, the ability for security-aware servers to interwork with security-ignorant servers is essential, which implies that the protocol cannot be changed. Let us now look at some of the details.

DNS records are grouped into sets called RRSets (Resource Record Sets), with all the records having the same name, class, and type being lumped together in a set. An RRSet may contain multiple A records, for example, if a DNS name resolves to a primary IP address and a secondary IP address. The RRSets are extended with several new record types (discussed below). Each RRSet is cryptographically hashed (e.g., using SHA-1). The hash is signed by the zone’s private key (e.g., using RSA). The unit of transmission to clients is the signed RRSet. Upon receipt of a signed RRSet, the client can verify whether it was signed by the private key of the originating zone. If the signature agrees, the data are accepted. Since each RRSet contains its own signature, RRSets can be cached anywhere, even at untrustworthy servers, without endangering the security.

DNSsec introduces several new record types. The first of these is the KEY record. This records holds the public key of a zone, user, host, or other principal, the cryptographic algorithm used for signing, the protocol used for transmission, and a few other bits. The public key is stored naked. X.509 certificates are not used due to their bulk. The algorithm field holds a 1 for MD5/RSA signatures (the preferred choice), and other values for other combinations. The protocol field can indicate the use of IPsec or other security protocols, if any.

The second new record type is the SIG record. It holds the signed hash according to the algorithm specified in the KEY record. The signature applies to all the records in the RRSet, including any KEY records present, but excluding itself. It also holds the times when the signature begins its period of validity and when it expires, as well as the signer’s name and a few other items.

The DNSsec design is such that a zone’s private key can be kept offline. Once or twice a day, the contents of a zone’s database can be manually transported (e.g., on CD-ROM) to a disconnected machine on which the private key is located. All the RRSets can be signed there and the SIG records thus produced can be conveyed back to the zone’s primary server on CD-ROM. In this way, the private key can be stored on a CD-ROM locked in a safe except when it is inserted into the disconnected machine for signing the day’s new RRSets. After signing is completed, all copies of the key are erased from memory and the disk and the CD-ROM are returned to the safe. This procedure reduces electronic security to physical security, something people understand how to deal with.

This method of presigning RRSets greatly speeds up the process of answering queries since no cryptography has to be done on the fly. The trade-off is that a large amount of disk space is needed to store all the keys and signatures in the DNS databases. Some records will increase tenfold in size due to the signature.

When a client process gets a signed RRSet, it must apply the originating zone’s public key to decrypt the hash, compute the hash itself, and compare the two values. If they agree, the data are considered valid. However, this procedure begs the question of how the client gets the zone’s public key. One way is to acquire it from a trusted server, using a secure connection (e.g., using IPsec).

However, in practice, it is expected that clients will be preconfigured with the public keys of all the top-level domains. If Alice now wants to visit Bob’s Web site, she can ask DNS for the RRSet of bob.com, which will contain his IP address and a KEY record containing Bob’s public key. This RRSet will be signed by the top-level com domain, so Alice can easily verify its validity. An example of what this RRSet might contain is shown in Fig. 8-48.

Now armed with a verified copy of Bob’s public key, Alice can ask Bob’s DNS server (run by Bob) for the IP address of www.bob.com. This RRSet will be signed by Bob’s private key, so Alice can verify the signature on the RRSet Bob returns. If Trudy somehow manages to inject a false RRSet into any of the caches, Alice can easily detect its lack of authenticity because the SIG record contained in it will be incorrect.

However, DNSsec also provides a cryptographic mechanism to bind a response to a specific query, to prevent the kind of spoof Trudy managed to pull off in Fig. 8-47. This (optional) antispoofing measure adds to the response a hash of the query message signed with the respondent’s private key. Since Trudy does not know the private key of the top-level com server, she cannot forge a response to a query Alice’s ISP sent there. She can certainly get her response back first, but it will be rejected due to its invalid signature over the hashed query.

DNSsec also supports a few other record types. For example, the CERT record can be used for storing (e.g., X.509) certificates. This record has been provided because some people want to turn DNS into a PKI. Whether this will actually happen remains to be seen. We will stop our discussion of DNSsec here. For more details, please consult RFC 2535.

Frequently Asked Questions