[PDF] [PDF] Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos

[PDF] DNS Cache Poisoning Attack

This attack is known as “DNS Cache Poisoning” The attackers (or Cyber- criminals) abused the cached IP address in the DNS server to redirect their web site 

[PDF] Securing Applications in the Cloud - Cloudflare

DDoS attacks, particularly DNS, network, and application layer DDoS Cache poisoning or “spoofing” tricks unsuspecting site visitors to enter sensitive data, 

[PDF] Practical Web Cache Poisoning: Redefining - PortSwigger

Web cache poisoning has long been an elusive vulnerability, a 'theoretical' types of cache, such as client-side browser caches and DNS caches, but they're not Vary header is only used in a rudimentary way, CDNs like Cloudflare ignore it 

[PDF] Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos

Currently, Cloudflare, which is the default trusted resolver when using DoH resolution in Firefox, performs validation with DNSSEC on the queries sent to their 

[PDF] A Cache Poisoning Attack Targeting DNS Forwarding - USENIX

12 août 2020 · DNS cache poisoning attack based on IP defragmentation The attack Cloudflare [2], Google [10], Quad9 [19], OpenDNS [1], Verisign [22] 

[PDF] DNS Cache Poisoning Attack Reloaded: Revolutions - SAD DNS

Google 8 8 8 8 Cloudflare 1 1 1 1 OpenDNS 208 67 222 222 Comodo 8 26 56 26 Dyn 216 146 35 35 Quad9 9 9 9 9 AdGuard 176 103 130 130

[PDF] Adaptive Deterrence of DNS Cache Poisoning - Purdue Computer

years of patching, DNS cache poisoning attacks still plague the DNS infrastruc- CloudFlare Enables Universal DNSSEC for Its Millions of Customers for Free

[PDF] DNS cache poisoning ready for a comeback - Tech Xplore

11 nov 2020 · DNS cache poisoning attacks this week at the CloudFlare's 1 1 1 1 As part of their DNS cache poisoning is a type of attack that injects

[PDF] dns lab

[PDF] dns over https android

[PDF] dns over https chrome

[PDF] dns over https isp

[PDF] dns over https proxy

[PDF] dns over https router

[PDF] dns over https vs vpn

[PDF] dns server recursive query cache poisoning weakness exploit

[PDF] dns server recursive query cache poisoning weakness nmap

[PDF] dns sinkhole

[PDF] dns sinkhole list

[PDF] dns sinkhole software

[PDF] dns sinkhole windows

[PDF] dns spoof script

[PDF] do 2011 jeep grand cherokees have easter eggs

INOM EXAMENSARBETE DATATEKNIK,

GRUNDNIVÅ, 15 HP

, STOCKHOLMSVERIGE2020

Cache Poisoning in DNS over

HTTPS clients

HTTPS klienter

EMILIA BLIDBORG

CAROLINE GUNNARSSON

KTH

SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA

Cache Poisoning

in DNS over HTTPS clients

Emilia Blidborg

Caroline Gunnarsson

Examensarbete inom Datateknik

Grundnivå, 15 hp

Handledare på KTH: Martin Jacobsson

Examinator: Ibrahim Orhan

TRITA-CBH-GRU-2020:047

KTH

141 52 Huddinge, Sverige

Abstract

DNS over HTTPS (DoH) is a protocol used to send traditional DNS traffic over HTTPS. This causes the DNS name resolving traffic to be encrypted and transmitted over the same port as regular HTTPS traffic. This thesis maps a number of previous vulnerabilities in DNS and compares those risks with the DoH protocol and its implementation, mainly focusing on cache poisoning. A number of attacks from a DoH server to a DoH client are applied. The results show that it is possible to inject incorrect data into the DoH client"s cache. The consequences of this can be extensive, an example of this is a redirect to a malicious web page, which when using DoH can be difficult to detect because the DNS traffic is encrypted. Further work is needed to mitigate the security holes discovered, as well as to further identify potential threats.

Keywords

DNS over HTTPS, DoH, cache poisoning, RFC 8484, DNS security, DANE

Sammanfattning

Konsekvenser av detta kan bli omfattande, ett exempel kan vara en omdirigering till en

Nyckelord

Acknowledgements

We want to thank Internetstiftelsen for this opportunity and provision of equipment needed to carry out this study. We want to give an extra thanks to Ulrich Wisser at Internetstif- telsen for all the support and guidance during the study. We also want to thank Martin Jacobsson, who has been our mentor at KTH throughout this study.

Glossary

CACertificate Authority.

DANEDNS-based Authentication of Named Entities.

DDOSDistributed Denial of Service.

DNSDomain Name System.

DNSSECDomain Name System Security Extension.

DoHDNS over HTTPS.

HTTPHypertext Transfer Protocol.

HTTP/2Hyper Transfer Protocol Version 2.

HTTPSHypertext Transfer Protocol Secure.

IDSIntruder Detection System.

IPSECInternet Protocol Security.

ISPInternet Service Provider.

MITMMan-in-the-middle.

PKIPublic key infrastructure.

RFCRequest for Comments.

RRResource Record.

SNIServer Name Indication.

TLSTransport Layer Security.

TRRTrusted Recursive Resolver.

Contents

1 Introduction 1

1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Goals of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Scope of the project and delimitations . . . . . . . . . . . . . . . . . . . . 2

2 Theory and background 3

2.1 A brief introduction to DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 DNS flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 DNS message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 The DoH package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Hyper Transfer Protocol Version 2 . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Streams & Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 Server push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.3 Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 DoH and browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Weaknesses of DoH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 User privacy and parental control . . . . . . . . . . . . . . . . . . . 10

2.5.2 Security view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Previous work regarding DoH . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 Previous known attacks and vulnerabilities in DNS . . . . . . . . . . . . . 12

2.7.1 Attacks against resolvers . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.2 Man-in-the-middle attack . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.3 Cache attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.4 Other attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8 DNS-based Authentication of Named Entities . . . . . . . . . . . . . . . . 14

3 Methodology and Results 15

3.1 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Argument for choice of client . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Lab enviroment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1 DoH server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.2 DoH client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.3 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Choice for modification of code . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Injection tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Compilation of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Analysis and discussion 25

4.1 Analysis of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Conclusion of the goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Error margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Economic, social, ethical and environmental aspects . . . . . . . . . . . . . 28

4.6 Other aspects and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Conclusions 31

5.1 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 References 35

INTRODUCTION | 1

1 Introduction

The Domain Name System (DNS) is a vital part of the Internet and a requirement for its full functionality. Almost all services available on the Internet rely on and start with a DNS query, which has the main task of translating domain names into IP addresses. DNS was developed in 1984 by Paul Mockapetris [1]. When building its structure, the security was not the main consideration. Due to that they did not think there would be a matter of integrity. At the same time, the protocol is constantly evolving to make the name translation more efficient and secure. DNS over HTTPS (DoH) [2] is one of the protocols that has been developed to meet these vulnerabilities. The protocol establishes encrypted connections to send DNS queries and responses through. Firefox already supports this technology and their browser will be used as a DoH client for this study.

1.1 Problem statement

DoH is a relatively new technique for managing DNS queries. As popular web browsers have begun to implement the technology, an examination of the protocol is important. The protocol is based on HTTP/2 [3], and the main goal is to achieve integrity by encrypting the communication between client and resolver. This means that the DNS queries are encrypted and not sent in plaintext as previously, and also sent over the well-known port

443 and thus inseparable from regular HTTPS traffic. Is this a problem or is it only an

advantage for privacy? There is a lot of ongoing discussions about the protocol, including privacy and who owns the huge amount of DNS data being transported. This data may contain sensitive information about users, such as IP address and browsing habits. Since queries are only encrypted part of the transport route, these data are also visible to some extent for certain nodes in the chain. Is it possible to apply known DNS vulnerabilities to DoH? Does DoH prevent Internet Service Providers (ISPs) from tracking user data? Or does this only centralize the DNS traffic?

1.2 Goals of the project

As this is such a new area, this study will examine any possible exploits or security vul- nerabilities that the protocol or its implementation may cause users. Both from the user"s expectation of the protocol but also flaws in the design. The main area that will be ex- amined is the possibility to inject false information into a web browser"s cache memory and thus send the wrong IP address to the clients and redirect them to the wrong website. This study will also examine the lack of integrity in the protocol.

2 | INTRODUCTION

The goals of this study were presented by Internetstiftelsen. And three main goals were developed: Examine if there is any unknown vulnerability regarding the protocol DoH, with focus on cache poisoning attacks. Analyze which known DNS vulnerabilities the protocol DoH is able to protect against. Investigate how a typical DoH client handles data that has not been requested. In addition to these main goals, the following sub-goals were formulated:

Study the structure of DoH packages.

Study the DNS name resolve cache of the web browser. Investigate who has access to sensitive user data. Map what users of the protocol expect, and what they actually get. Develop a DoH server that intends to provide client with manipulated DNS data.

1.3 Scope of the project and delimitations

This project only covers the evaluation of the protocol DoH. Other protocols, also designed to make DNS lookup safer, is only taken into consideration when discussing future work. Due to time limitations, only a few of the potential threats found were tested in the lab environment, and others are only discussed in a later chapter.

THEORY AND BACKGROUND | 3

2 Theory and background

This chapter covers the presentation of previous work in the field, as well as the underlying theory. The DNS over HTTPS (DoH) protocol is reviewed and implementations that support the protocol are presented. Previously known vulnerabilities with regular DNS are studied, in order to be able to evaluate the protocol DoH easier later in the study.

2.1 A brief introduction to DNS

The purpose of this section is to introduce DNS and its functions on the internet and is aimed for readers who do not have enough knowledge in the field. With the help of DNS, the user does not need to remember the IP address of the web server to which the connection is to be made, the user can instead remember an alias name. The Domain Name System (DNS) is a distributed system [1], it is hierarchical and structured as a tree to facilitate the search. Part of the domain namespace represents a zone, this zone can be managed by, for example, a person or an organization. Each zone includes one zone file, also called a "master file" [4] which includes a number of entries specific for that zone. A resource record (RR), like an IPv4 or IPv6 address, that is included in the domain can take 2 different forms:

OWNER-NAME TTL class type RDATA

OWNER-NAME class TTL type RDATA

OWNER-NAME: Specifies the name of the resource record. TTL: "time-to-live", an integer indicating how long the resource record should be cached before it should be fetched again. class: Class code for the resource record, the by far most common is IN that represents "the Internet". type: Specifies the type of RDATA in the record, such as IPv4 address. RDATA: Contains the values of the resource record, the format of this field varies depending on TYPE and CLASS, for example if TYPE = A and CLASS = IN, the RDATA field is a "4 octet ARPA Internet address" [4], i.e. an IPv4 address. A set of Resource Records with the same owner name, class, and type are grouped together and are referred to as an RRset [5, see section 5].

2.1.1 DNS flags

To understand the DNS responses in the execution of the study, relevant DNS flags are presented below [1].

4 | THEORY AND BACKGROUND

AD: Authenticated Data. If the AD bit is set, it means that the answer is validated. Allows resolvers that cannot verify DNSSEC themselves to instead study the AD flag in the received response from the name server. The resolver should then only trust the AD bit if the communication channel is secured, like for example Internet Protocol Security (IPSEC). Which is the case for DNS over HTTPS, as the channel is encrypted. AA: Authoritative Answer. If the query goes to an authoritative server, the AA flag is set in the response. RD: Recursion Desired. It indicates that the client wants the nameserver to act resolver if possible. RA: Recursion Available. It is set in the response if the server was able to perform recursion. QR: If set, the package is a response, otherwise a query.

2.1.2 DNS message

For the domain protocol, the standard format is called a message. The message contains

5 sections.Figure 1: Example of a DNS Message [4].

2.1.3 DNSSEC

Domain Name System Security Extensions (DNSSEC) is a mechanism for verifying records in DNS [6]. The "Authentication Chain", is built on public-key cryptography and can prove the authenticity of a DNS response. Cryptographic signatures of DNS records are stored in RRSIG records. A private key is used to create the signature, and its public key is stored in DNSKEY records, which can be used for validation. DS records are used to create a

THEORY AND BACKGROUND | 5

chain of trust between the zone and its parent zone. The Delegation Signer (DS) RRset includes a hash of a particular DNSKEY. Each DNSSEC signed zone can be associated with an key pair [1]. The RRset Signature (RRSIG) records stores the digital signature for an RRsets private key and is used to sign that particular RRset. DNSSEC also provides a guarantee that the content had not been modified along the way. DNSSEC does not encrypt DNS-packages in the sense of maintaining the confiden- tiality of the content.

2.2 DNS over HTTPS

DNS over HTTPS (DoH) is a protocol for handling DNS queries over HTTPS. The main goal when developing DoH was to increase integrity. This could be done by encrypting the data transported between the client and the server. The protocol is published as a proposed standard in RFC 8484 [2]. There are different ways to apply DoH to the client in need of resolving. For example: DoH support can be implemented in the web browser, like the Mozilla firefox web browser [7]. DoH support can be implemented in the operating system, like Microsoft Windows [8]. RFC 8484 defines a proposed standard for DNS queries over HTTPS. The protocol is only defined for HTTPS, which denotes that DNS queries always are encrypted and resolvers are always authenticated. HTTP/2 is the minimum recommended version of HTTP to utilize together with DoH, this protocol is presented in section 2.3. A client and a server that support this protocol are called a "DoH client" and a "DoH server" respectively. The DoH server is separated from the DNS servers and must im- plement both POST and GET methods. Section 2.2.1 describes the structure of the two packages. A DoH client must configure which DoH server to use for resolution, this is done by specifying the URI of the DoH server.

2.2.1 The DoH package

The DoH package is a standard DNS wire format inside an HTTPS payload [2]. One HTTP exchange consists of a request-response pair mapped to it. The protocol defines an HTTP request and an HTTP response layout. The following is an example of a request which uses POST to requestwww.example.com:

6 | THEORY AND BACKGROUND

Figure 2: DNS query using POST [2, see section 4.1]. The DNS query is inside the message body, and the "content-type" field indicates that the

media type of the message is DNS. The same request which uses GET would look like:Figure 3: DNS query using GET [2, see section 4.1].

The data payload must be encoded with base64url for GET methods, this does not apply to POST methods. The DNS query is in a GET parameter. From the HTTP cache pointquotesdbs_dbs17.pdfusesText_23