Surveillance or Security?: The Risks Posed by New Wiretapping Technologies (11 page)

In 1983 Paul Mockapetris developed the Domain Name Servers (DNS)
system to enable names to be translated to IP addresses (and vice versa).46
Propagating that information through the network, which is necessary if
your machine is to communicate with an arbitrary one on the network,
requires a complex infrastructure to do the translation. DNS introduced
hierarchical domain names and a system for distributing the mappings
between host names and IP addresses.

To manage the mappings between names and IP addresses, DNS allows
the mappings to be divided into contiguous regions called zones. Zones
can be subdivided into smaller zones. This means that zones are a naturally
hierarchical construct.47 When a zone is created, responsibility for the
mappings it holds are delegated to multiple nameservers, which are authoritative for the zone. Servers authoritative for a zone assert that the mappings
that they have for a zone are correct.

Nameservers can store the mappings for multiple zones (some authoritatively, some not), as well as individual mappings that are stored as a
result of earlier lookups. Because of the size of the network, the number
of mappings that exist is extremely large, so it would be impossible for any
one nameserver to hold all such mappings at once. Instead, nameservers
have the ability to traverse the known parts of the hierarchy and find the
parts they need.

At the top of the hierarchy are replicated nameservers for the "dot" or
"." domain. These are called the root nameservers, and they are authoritative
for "top-level domains," such as.com, .gov, org,.jp, and.uk. In turn, there
are top-level DNS nameservers, which are authoritative for their own
zones. Thus, for example, the com nameservers will be authoritative for
the IP addresses for the various.com domains (e.g., amazon.com, cnn.com,
google.com, etc.), while the uk nameserver will be authoritative for the
various uk domains (ac.uk, co.uk, etc.). The google.com nameserver would
be authoritative for the IP addresses for the various google.com domains
(e.g., images.google.com, mail.google.com, maps.google.com, etc.). The
model recurses down.

The model in figure 3.2 is called a "distributed hierarchical database"
because each DNS nameserver holds a database mapping DNS names to
their IP addresses. In 2009 there were, for example, thirteen root servers.
As shown in figure 3.3, ten were in the United States, one in the United
Kingdom, one in Sweden, and one in Japan.48

Figure 3.2

Distributed DNS hierarchy. Illustration by Nancy Snyder.

Figure 3.3

Location of root DNS servers (nonreplicated). Illustration by Nancy Snyder.

The astute reader will have noticed a problem. It cannot be the case that
the root nameservers are consulted each time the DNS nameserver seeks a
numeric IP address for a domain name. Instead, each lookup is cachedstored-for a certain period of time49 and the cached result is used for other
queries that occur during that period.

If the user (or really, the user's application) wants the IP address of maps
.google.com, the query goes to a DNS resolver, a machine that resolves the
URLs into IP addresses, within the user's local system. In the case of a home
user, this would be the ISP; in the case of a user at a large business, it is
likely to be a DNS resolver within the local network. If this DNS resolver
has the IP address cached, the DNS resolver will respond with that address.
Otherwise the resolver has a list of DNS nameservers it can query. It picks
one50 and sends a query to a local DNS nameserver. If the local DNS nameserver has the address for maps.google.com, it will supply the address to
the DNS resolver, which then returns it to the application. Otherwise the
local DNS nameserver will query a DNS nameserver with authoritative
information about "google.com" for the address of "maps.google.com."51
A nameserver that is authoritative for google.com52 will have the IP
addresses for all google.com subzones, including maps.google.com, images
.google.com, mail.google.com, and so on.

The local DNS nameserver may not know how to reach an authoritative
server for the google.com zone. Then the local DNS nameserver will go
"up" one level in the hierarchy and send a query to a DNS nameserver that
is authoritative for the com zone,53 asking for the IP address of google.
com. If the local DNS nameserver somehow did not know how to reach
an authoritative nameserver for the com zone-this is unlikely, but possible-the local DNS nameserver would continue up the hierarchy. It would
go to the authoritative "root" DNS nameserver, called the server for "dot"
or ".", and ask for the IP address of the authoritative ".com" DNS server.54
Finally the DNS nameserver would recurse back through its own unanswered queries, resolving them. First it asks the authoritative.com DNS
nameserver for the IP address of google.com. Then the local nameserver
uses the answer to that query and asks the authoritative nameserver for
google.com for the IP address for maps.google.com. Finally it would return
that IP address to the local DNS resolver, which in turn would provide the
response to the application. Despite the complexity of the algorithm, the
local resolver will typically have the answer in under a few seconds.

Even so, not everything is rosy in this solution. Caching of IP addresses
creates a potential security problem, indeed a very serious one.55 There are
various ways a DNS nameserver can be fooled into accepting a false IP address for a site. A survey reported by David Dagon et al. found that 2.4
percent of the DNS servers they examined responded with incorrect
answers.56 This is surprisingly high, but the number should be viewed in
context. In China, for example, DNS resolution is correct only 81.5 percent
of the times' (this was the largest fraction of incorrect responses; it is clearly
not accidental). Some of the misdirections are to protect the user-for
example, OpenDNS prevents users from going to known phishing sites.58
Regardless of whether the misdirection is actually in the user's interest,
that the user can be secretly misdirected is highly disturbing.

DNS misdirections are possible because messages to DNS servers are not
digitally signed (thus proving they came from a legitimate site). If a user
types in a URL, say www.bankofamerica.com, but encounters a DNS nameserver whose cache has been poisoned, the user could end up not at the
Bank of America website but at a web page that looks as if it is the Bank
of America website, but is in fact a bogus site. Such a fake site could be set
up to collect password and account information.

Of course, the same problem could conceivably happen in the physical
world: a customer could walk into a storefront that looked like a Bank of
America branch, but that was actually a fake banking office. In practice,
the latter situation is highly improbable. The cost of building such an
office, the permits that would be needed, and so on, make such an event
unlikely.59 An extension to the DNS protocol, DNSSEC, eliminates the
problem of spoofing the IP address; a number of implementation issues
have prevented DNSSEC from being widely deployed.

Another problem, not with the Internet protocols themselves, but rather
with the difficulty of transferring human experience to an online world,
arises from the spoofing that can occur when a fake address mimics a wellknown site, such as www.paypal.com for www.paypal.com. Such spoofing
is often the basis of a phishing attack60 in which the user receives an email
with a link purportedly to the genuine site-PayPal-but that is actually a
link to its mimic. The user who clicks on the link is taken to something
that looks like the PayPal site and can thus be fooled into submitting
passwords and other valuable data on the rogue website.

Routers have operating systems, and thus they themselves are vulnerable
to attack. As early as 2000, for example, a number of Cisco routers were
attacked in a way that caused the routers to crash." This can be really disruptive to communications. In 2003, over two thousand Cisco routers whose
passwords were poorly chosen (cisco was a common choice) were attacked.
If a router is taken over, it can be programmed to do many nefarious things.
Fortunately these were low-end routers and there was not much damage.

If a high-end router at a network peering point-a location where networks connect and freely exchange traffic62-were to be so compromised,
it would be in a position to do a great deal of damage. Routers can be
programmed to sniff packets-that is, read the contents of the packets as
they transit the router-or to launch a denial-of-service (DoS) attack, in
which a network resource is bombarded by so many packets attempting to
connect to it that legitimate users cannot, and the resource is inaccessible.
Typically DoS attacks are against a website but even Internet root nameservers have been so targeted. Attacks on routers are serious business
indeed.

The attacks just described are on devices in the Internet "cloud," but
the vulnerabilities inherent in TCP/IP can also directly disrupt Internet
hosts. One such vulnerability arises from the SYN flood attack. Recall that
under TCP, a client and server establish a connection through a "threeway" SYN, SYN ACK, and ACK handshake. If the client is using a spoofed
IP address-and nothing in TCP/IP checks to see that the IP address is
genuine-then the server's message is not acknowledged. The server is
left waiting. If too many of these falsified connections occur at once,
the server is not available for new connections. Thus, purely as a result of
TCP/IP's lack of an authentication requirement, the server is vulnerable to
a denial-of-service attack.

A distributed denial-of-service (DDoS) attack occurs when previously compromised hosts band together to perform a concerted attack on a targeted
system. The attackers are called a botnet or zombies. DDoS attacks can
employ thousands of machines to send messages to a target machine (e.g.,
to establish a connection such as opening a web page stored on the target
machine), saturating the target and preventing it from communicating. A
2007 DDoS attack against Estonia shut down numerous government and
business websites in the Baltic nation for several days. Note that a DDoS
attack combines the insecurities inherent in Internet protocols with the
insecurities of the endpoints, and thus is a combination of the two previous forms of attack.

3.5 Attacks on the Hosts

End hosts face attacks from three types of malicious software, or malware:

• Worms, which are self-replicating programs that spread throughout a
machine or between machines.

• Viruses, which are self-replicating program fragments (rather than complete programs); these must be inserted into a program in order to work.

• Trojan horses, which are programs that hide some malicious behavior
within an attractive functionality; the attractive aspect often tempts the
user to download the program. Trojan horses can be used to deliver viruses
or worms.

Such malware can enter a user's machine in various ways. It may arrive
unbidden via the Internet, as the Morris worm did, or via removable media
such as a floppy disk, which is how the first such virus spread in 1982.63
It may be downloaded as an attachment in an email and then opened;
that is how both the 1999 Melissa and the 2000 ILOVEYOU viruses64
arrived on users' machines.

Commonly users are attacked only by Trojan-horse programs that they
have explicitly downloaded to their machine (typically the user downloads
the program because of some attractive functionality; the user is unaware
of the other functionality-such as random shutdowns, or redirecting the
browser to a pornography site-that might occur once the Trojan horse is
installed). But users can also be threatened by a more insidious form of
Trojan-horse attack, referred to as "drive-by download," which arrives when
the user visits an infected web page. Small pieces of code can be embedded
within the code of vulnerable websites. This code then invisibly and automatically installs malware on any vulnerable machine whose user visits
the infected site. The malware gains control over the compromised system,
perhaps stealing sensitive information (e.g., banking passwords when the
user is visiting a banking website), perhaps sending out spam, and so forth.65