Securing DNSSEC Against State Level Adversaries

33 Pages·2016·0.13 MB·English

Securing DNSSEC Against State Level
Adversaries
Tyler O’Meara
The University of Texas at Austin
Department of Computer Science
[email protected]
Supervising Instructor
Dr Mohamed G. Gouda
[email protected]
Submitted to the Department of Computer Science
in partial fulfillment of the requirements for the degree of
Bachelor of Science in Computer Science, Turing Scholars Honors
at
The University of Texas at Austin
May 6, 2016
Abstract
The security of data transmitted on the Internet is dependent on the integrity of
the Domain Name System (DNS). A large amount of work has gone into secur-
ingDNS,particularlytheDomainNameSystemSecurityExtensions(DNSSEC),
which protects against traditional off-path and man in the middle attacks. How-
ever, DNSSEC relies on the assumption that all of the name servers used for
resolution are honest. We extend the threat model of DNSSEC to include state
level adversaries which undermine the security of some of these name servers.
As a result, we remove the assumption that the name servers used for resolution
are trustworthy. We discuss the infeasibility of a secure protocol which does not
requiretrustingathirdpartyandinsteadintroduceamechanismforobtainingdis-
tributed trust from a set of mutually untrustworthy agents. We then integrate this
mechanism into DNSSEC in order to use distributed trust to ensure validity of
DNSresponses,evenwhilebeingattackedbystateleveladversaries.
i
1. Introduction
The Domain Name System is an integral part of the Internet. It provides the
mapping from user readable domain names to IP addresses that uniquely identify
machinesontheInternet,andwhichareusedtoroutepacketstotheirdestination.
As such, being able to change the IP address mapped to a domain name can be
incredibly valuable to an attacker, as they are able to redirect all traffic from the
intended recipient to themselves. There are many protections in place to prevent
this from happening, but one type of attack remains viable: TLD Misdirection.
Every domain name has a Top Level Domain (TLD) that is responsible for map-
pingrequestsforthatdomaintotheproperIPaddress. Alloftheexistingsecurity
precautionsinDNSassumethattheoperatoroftheTLDwillactproperly. Unfor-
tunately, this is not a safe assumption, as governments across the world have the
capability to coerce these TLD operators to lie on their behalf. In this thesis, we
proposeamechanismtominimizetrustinTLDoperatorsinordertobetterdefend
againststateleveladversaries.
For instance, suppose a Computer Science researcher at Moscow State Uni-
versity is developing a new security program which will provide Russian citizens
with the ability to communicate privately. The Russian Federal Security Service
(known as the FSB, successor to the Soviet-era KGB), is likely to want to under-
mine the security of this system, in order to retain access to the communications
ofRussiancitizens. OnepossiblewaytheFSBcouldunderminethissystemwith-
outattractingattentionwouldbetoplaceabackdoorinthesecurityprogram,and
ensure that anyone who tries to download the program from the researcher’s web
sitegetsthecompromisedversion. Inordertodothis,theycouldhijackthetraffic
1
intended for the researcher’s website, which we will assume is at ”cs.msu.ru.”1.
This would be relatively trivial for the FSB to accomplish: the operator of the
”ru.” TLD is a Russian organization, which even has ties to the Russian govern-
ment. Thus,alltheFSBneedstodoiscoercetheoperatortochangetheIPaddress
for”cs.msu.ru.” toacomputerunderFSBcontrol,inserttheirbackdooredversion
ofthesoftwareontoafakecopyofthesite,andcontinuetotrackthecommunica-
tions of Russian citizens without the citizens noticing a difference. Although we
use Russia as our example here, there are many countries where the governments
often use security vulnerabilities to undermine the security and privacy of their
citizens. These governments also often have the power to coerce any organiza-
tionwithintheircountrytodoasthegovernmentpleases. Wethereforeproposea
waytopreventnation-statelevelattackersfrominsertingfalsedataintheDomain
NameSystem;primarilybydefendingagainstTLDmisdirection.
2. Basics
In this section we briefly describe the Domain Name System and the Domain
Name System Security Extensions. These are the two protocols we build on in
this paper, and as a result, familiarity with these protocols is required to fully
understand the contributions of this paper. For a more detailed explanation of the
goalsanddesignoftheDomainNameSystem,pleaseseeRFC1034[24]andRFC
1035[25]. For a more comprehensive explanation of the Domain Name System
SecurityExtensions,pleaseseeRFCs4033,4034,and4035[1,3,2].
1Note:WeuseFullyQualifiedDomainNames(suchasinRFC1035[25])toremoveanyambi-
guityaboutthedomainnameswe’rereferringto.FQDNstypicallyonlydifferfromwhatisknown
asadomainnameincommonparlancebytheadditionofaterminatingfullstop, whichdenotes
thattherightmostlabelofthedomainnameistherootzone.
2
2.1. DomainNameSystem(DNS)
The namespace of the Domain Name System (DNS) is a directed rooted tree.
Each node in the tree is called a zone, and has a label. The label of a zone is a
string of characters, and the label of the root zone is the empty string. Figure 1
shows part of the namespace of DNS. Note that the root zone of the namespace
in Figure 1 is labelled with the empty string. The root zone in Figure 1 has 3
children zones, labeled ”us”, ”edu”, and ”ru”. In the namespace in Figure 1 the
zones labeled ”us”, ”edu”, and ”ru” have the same parent zone, so they are called
sibling zones. In the namespace of DNS, sibling zones have distinct labels, but
zones that are not siblings can have the same label. For example, two zones that
arenotsiblingsinthenamespaceinFigure1havethesamelabel”cs”.
3
us edu ru
r40 mit utexas msu
ns1 csail mail cs cs phys
apps
Figure 1
AnexampleoftheDNSnamespace. Thepathtothezone”cs.msu.ru.” is
highlighted
Inadditiontohavingalabel,eachzonealsohasanamecalledadomainname.
The domain name of a zone is the specific traversal through the DNS namespace,
starting at the root node (at the far right of the domain name), and proceeding
to the left as you descend the tree. For instance, in Figure 1, the domain name
”cs.msu.ru.” corresponds to the traversal through the namespace that starts at the
root node, follows the edge to the child node labeled ”ru”, on to that node’s child
named”msu”,andfinallytothechildnodeof”msu”named”cs”. Ascanbeseen,
4
thelabelsofthezonesinadomainnameareseparatedbyfullstops. Itisimportant
tonotethatalthoughzoneshavenon-uniquelabels,thedomainnameofeachzone
is unique. For example, the zones ”cs.msu.ru.” and ”cs.utexas.edu.” both have
the same label ”cs”, but have distinct domain names. Note that there is a one to
onemappingbetweenzonesanddomainnames. Thereforeweusethetermszone
anddomainnameinterchangeablyintherestofthispaper.
Zone IPAddress
<emptystring> 198.41.0.4
”us.” 156.154.124.70
”edu.” 192.5.6.30
”ru.” 193.232.128.6
”r40.us.” 70.114.202.42
”mit.edu.” 23.206.249.192
”utexas.edu.” 128.83.40.144
”msu.ru.” 188.44.50.103
”ns1.r40.us.” 70.114.202.42
”csail.mit.edu.” 128.30.2.121
”mail.utexas.edu.” 128.83.126.1
”cs.utexas.edu.” 128.83.120.11
”cs.msu.ru.” 188.44.50.110
”phys.msu.ru.” 93.180.53.207
”apps.cs.utexas.edu.” 128.83.120.48
Table1
Each zone also has an IP address. Table 1 shows the IP address of each zone
in the DNS namespace in Figure 1. The purpose of the Domain Name System is
5
to execute a procedure called name resolution. This procedure takes as an input
the domain name of a zone and returns the IP address of that zone. For example,
this procedure can take as an input the domain name ”cs.msu.ru.” and returns
the IP address 188.44.50.110. The different steps for resolving ”cs.msu.ru.” into
188.44.50.110areasfollows,andareshowninFigure2.
Step1: The client software called the resolver sends the name to be resolved,
”cs.msu.ru.”, to the root zone whose IP address is 198.41.0.4. The root
zone returns to the resolver the domain name and IP address of the ”ru.”
zone.
Step2: Theresolversendsthenametoberesolved,”cs.msu.ru.”,tothezone”ru.”
whose IP address is 193.232.128.6 (from Step 1). The zone ”ru.” returns
totheresolverthedomainnameandtheIPaddressofthe”msu.ru.” zone
(fromTable1).
Step3: The resolver sends the name to be resolved, ”cs.msu.ru.”, to the zone
”msu.ru.” whose IP address is 188.44.50.103 (from Step 2). The zone
”msu.ru.” returns to the resolver the domain name and the IP address of
the”cs.msu.ru.” zone(fromTable1).
Step4: The resolver observes that the response it obtained in step 3 was for the
name that needs to be resolved, so it stops and returns the IP address it
obtainedinstep3,188.44.50.110.
In this instance, the sequence of zones that the resolver queries is identical to
the path from the root node of the DNS namespace tree to the ”cs.msu.ru.” zone.
ThisisshowninFigure2. Thisdoesnotneedtobethecase,anyofthezonesprior
6
to”msu.ru.” couldhaverespondedwiththeIPaddressof”cs.msu.ru.” iftheyhad
knownit. Asaresulttheresolutionsequenceisasubsetofthenamespacepath.
ru
msu
cs
Figure 2
ThesequenceofzoneswhichtheresolvercontactsinordertodeterminetheIP
addressof”cs.msu.ru.”
2.2. DNSSEC
DNS, being one of the earliest Internet protocols, was not built with security
in mind. DNS has minimal authentication of messages at the application pro-
tocol level[25]. For instance, in Step 1, a network eavesdropper that observed
the resolver’s request to the root zone would have all of the necessary informa-
tion required to forge a response to the resolver. The resolver can not verify that
responses came from the proper zone, as such the resolver just accepts the first
7
response to a query that it receives as valid. Thus a network eavesdropper can
provide a false IP address for the domain name to be resolved to a resolver. In
fact, the US National Security Agency has exploited vulnerabilities in DNS to at-
tackHTTP[4]. AttacksofthisnatureresultedintheintroductionofDNSSecurity
Extensions(DNSSEC).
DNSSECusespublickeycryptographytoallowauthenticationofresponses:
1. Each zone has a public key and its corresponding private key which is
knownonlytothatzone.
2. Thepublickeyoftherootzoneisknowntoallresolvers.
3. Eachresponsefromazoneissignedbythatzone’sprivatekey.
4. Whenazonereferstheresolvertoanotherzoneitincludesthatchildzone’s
publickeyinits(signed)response.
Sinceallzoneshavetherootzoneastheirancestor,allDNSSECresponsescanbe
validatedashavingcomefromtheappropriatezone[3,2].
Inthisway,notonlyareallresponsesfromtherootzoneverified,buttheroot
zone can extend the verification by providing the public keys of its children, and
that child zone can do the same thing, and so on until the target zone. This chain
of authentication, starting at the root public key, and extended whenever a node
respondswiththepublickeyofachildzone,isformallyknownastheAuthentica-
tionChain. WeobservethatthezonesthatconstitutetheAuthenticationChainare
identical to the sequence of zones used for resolution. Thus, the Authentication
Chainforanyqueryisalsoasubsetofthenamespacepathforthatquery. Theuse
of the Authentication Chain ensures that only those zones who have the authority
8