DOCSLIB.ORG

Cache Poisoning in DNS Over HTTPS Clients Cache-Förgiftning Hos DNS Över HTTPS Klienter

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cache Poisoning in DNS Over HTTPS Clients Cache-Förgiftning Hos DNS Över HTTPS Klienter EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2020 Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos DNS över HTTPS klienter EMILIA BLIDBORG CAROLINE GUNNARSSON KTH SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos DNS över HTTPS klienter Emilia Blidborg Caroline Gunnarsson Examensarbete inom Datateknik Grundnivå, 15 hp Handledare på KTH: Martin Jacobsson Examinator: Ibrahim Orhan TRITA-CBH-GRU-2020:047 KTH Skolan för kemi, bioteknologi och hälsa 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 DNS över HTTPS (DoH) är ett protokoll som används för att skicka traditionell DNS trafik över HTTPS. Detta medför att trafiken blir krypterad och sänds över samma port som vanlig HTTPS trafik. Denna rapport kartlägger ett antal tidigare sårbarheter i DNS och jämför dessa risker med DoH protokollet och dess implementation, främst med fokus på cache-förgiftning. Ett antal attacker från en DoH server till en DoH klient tillämpas. Resultatet visar att det är möjligt att injicera felaktig data i DoH klientens cacheminne. Konsekvenser av detta kan bli omfattande, ett exempel kan vara en omdirigering till en skadlig webbsida, vilket vid användning av DoH kan vara svårupptäckt på grund av att DNS traffiken är krypterad. Vidare arbete krävs för att förmildra de säkerhetshål som upptäcks, samt att ytterligare identifiera potentiella hot. Nyckelord DNS över HTTPs, DoH, cache-förgiftning, RFC 8484, DNS säkerhet, DANE 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 CA Certificate Authority. DANE DNS-based Authentication of Named Entities. DDOS Distributed Denial of Service. DNS Domain Name System. DNSSEC Domain Name System Security Extension. DoH DNS over HTTPS. HTTP Hypertext Transfer Protocol. HTTP/2 Hyper Transfer Protocol Version 2. HTTPS Hypertext Transfer Protocol Secure. IDS Intruder Detection System. IPSEC Internet Protocol Security. ISP Internet Service Provider. MITM Man-in-the-middle. PKI Public key infrastructure. RFC Request for Comments. RR Resource Record. SNI Server Name Indication. TLS Transport Layer Security. TRR Trusted 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.
Load more

Recommended publications
  • Adopting Encrypted DNS in Enterprise Environments
    National Security Agency | Cybersecurity Information Adopting Encrypted DNS in Enterprise Environments Executive summary Use of the Internet relies on translating domain names (like “nsa.gov”) to Internet Protocol addresses. This is the job of the Domain Name System (DNS). In the past, DNS lookups were generally unencrypted, since they have to be handled by the network to direct traffic to the right locations. DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS (DoH), encrypts DNS requests by using HTTPS to provide privacy, integrity, and “last mile” source authentication with a client’s DNS resolver. It is useful to prevent eavesdropping and manipulation of DNS traffic. While DoH can help protect the privacy of DNS requests and the integrity of responses, enterprises that use DoH will lose some of the control needed to govern DNS usage within their networks unless they allow only their chosen DoH resolver to be used. Enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration. Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls. For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information. The enterprise DNS resolver may be either an enterprise-operated DNS server or an externally hosted service. Either way, the enterprise resolver should support encrypted DNS requests, such as DoH, for local privacy and integrity protections, but all other encrypted DNS resolvers should be disabled and blocked.
    [Show full text]
  • Webproxy, DNS Hijacking, Layer Seven Level Security Approach: to Protect SAAS from Web Based DDOS and Web Service Based DDOS Attacks in Cloud
    International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 2 Issue 2, February- 2013 Webproxy, DNS Hijacking, Layer Seven Level Security Approach: To Protect SAAS From Web based DDOS and Web Service Based DDOS Attacks In Cloud S.Tamilselvi1, Dr.S.Tamilarasi2,S.Loganathan3 1. M. tech , ISCF, Dr.mgr educational and research institute, chennai 2. Associate Professor, CSE, Dr.mgr educational and research institute, chennai 3.Assistant Professor, ECE, Paavai Engineering College , Namakkal, Tamil Nadu ABSTRACT Cloud services offers platform services, software services, infrastructure services via web services. Cloud computing is an emerging trend in business these type of services increases vulnerability which world. Provide services to its customers on demand, invite attackers. common vulnerabilities are services like Infrastructure services , Platform services , Software services , Network services so Security level attacks: on. Resources are maintained in the virtualIJERT IJERT datacenters for both private and public clouds. Saas 1. Dictionary attacks contains web application services, windows 2. Brute force attacks application services, tools services, console 3. Spoofing application services, third party software services so 4. Credential theft on. In web application services web based distributed 5. Password cracking denial and web services based distributed denial of attack is easily implemented hacker because web Management level attacks: application transmitted through hypertext transfer protocol and web services through XML, WSDL .In 1. Credential theft 2. Elevation of privileges this paper we introduce DNS hijacking security, Web 3. luring proxy implementation, application level security to resolve web based and web services based distributed Infrastructure layer security attacks: denial of service attacks. 1.
    [Show full text]
  • DNS Spoofing 2
    Professor Vahab COMP 424 13 November 2016 DNS Spoofing DNS spoofing, also known as DNS Cache Poisoning, is one of the most widely used man-in-the-middle attacks that capitalizes on vulnerabilities in the domain name system that returns a false IP address and routes the user to a malicious domain. Whenever a machine contacts a domain name such as www.bankofamerica.com, it must first contact its DNS server which responds with multiple IP addresses where your machine can reach the website. Your computer is then able to connect directly to one of the IP addresses and the DNS is able to convert the IP addresses into a human-readable domain name. If an attacker is able to gain control of a DNS server and change some of its properties such as routing Bank of America’s website to an attacker’s IP address. At that location, the attacker is then able to unsuspectingly steal the user’s credentials and account information. Attackers use spam and other forms of attack to deliver malware that changes DNS settings and installs a rogue Certificate Authority. The DNS changes point to the hacker's secret DNS name server so that when the users access the web they are directed to proxy servers instead of authorized sites. They can also start to blacklist domains and frustrate the user with their day to day activities. All blacklisted domains would have their traffic dropped instead of forwarded to their intended destination. Based on the rogue Certificate Authority the system has no sign that an attack is taking place or ever took place.
    [Show full text]
  • Secure Shell- Its Significance in Networking (Ssh)
    International Journal of Application or Innovation in Engineering & Management (IJAIEM) Web Site: www.ijaiem.org Email: [email protected] Volume 4, Issue 3, March 2015 ISSN 2319 - 4847 SECURE SHELL- ITS SIGNIFICANCE IN NETWORKING (SSH) ANOOSHA GARIMELLA , D.RAKESH KUMAR 1. B. TECH, COMPUTER SCIENCE AND ENGINEERING Student, 3rd year-2nd Semester GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India 2.Assistant Professor Computer Science and Engineering GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India ABSTRACT This paper is focused on the evolution of SSH, the need for SSH, working of SSH, its major components and features of SSH. As the number of users over the Internet is increasing, there is a greater threat of your data being vulnerable. Secure Shell (SSH) Protocol provides a secure method for remote login and other secure network services over an insecure network. The SSH protocol has been designed to support many features along with proper security. This architecture with the help of its inbuilt layers which are independent of each other provides user authentication, integrity, and confidentiality, connection- oriented end to end delivery, multiplexes encrypted tunnel into several logical channels, provides datagram delivery across multiple networks and may optionally provide compression. Here, we have also described in detail what every layer of the architecture does along with the connection establishment. Some of the threats which Ssh can encounter, applications, advantages and disadvantages have also been mentioned in this document. Keywords: SSH, Cryptography, Port Forwarding, Secure SSH Tunnel, Key Exchange, IP spoofing, Connection- Hijacking. 1. INTRODUCTION SSH Secure Shell was first created in 1995 by Tatu Ylonen with the release of version 1.0 of SSH Secure Shell and the Internet Draft “The SSH Secure Shell Remote Login Protocol”.
    [Show full text]
  • Technical Impacts of DNS Privacy and Security on Network Service Scenarios
    - Technical Impacts of DNS Privacy and Security on Network Service Scenarios ATIS-I-0000079 | April 2020 Abstract The domain name system (DNS) is a key network function used to resolve domain names (e.g., atis.org) into routable addresses and other data. Most DNS signalling today is sent using protocols that do not support security provisions (e.g., cryptographic confidentiality protection and integrity protection). This may create privacy and security risks for users due to on-path nodes being able to read or modify DNS signalling. In response to these concerns, particularly for DNS privacy, new protocols have been specified that implement cryptographic DNS security. Support for these protocols is being rapidly introduced in client software (particularly web browsers) and in some DNS servers. The implementation of DNS security protocols can have a range of positive benefits, but it can also conflict with important network services that are currently widely implemented based on DNS. These services include techniques to mitigate malware and to fulfill legal obligations placed on network operators. This report describes the technical impacts of DNS security protocols in a range of network scenarios. This analysis is used to derive recommendations for deploying DNS security protocols and for further industry collaboration. The aim of these recommendations is to maximize the benefits of DNS security support while reducing problem areas. Foreword As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industry’s business priorities. ATIS’ 150 member companies are currently working to address network reliability, 5G, robocall mitigation, smart cities, artificial intelligence-enabled networks, distributed ledger/blockchain technology, cybersecurity, IoT, emergency services, quality of service, billing support, operations and much more.
    [Show full text]
  • Threat Modeling and Circumvention of Internet Censorship by David Fifield
    Threat modeling and circumvention of Internet censorship By David Fifield A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor J.D. Tygar, Chair Professor Deirdre Mulligan Professor Vern Paxson Fall 2017 1 Abstract Threat modeling and circumvention of Internet censorship by David Fifield Doctor of Philosophy in Computer Science University of California, Berkeley Professor J.D. Tygar, Chair Research on Internet censorship is hampered by poor models of censor behavior. Censor models guide the development of circumvention systems, so it is important to get them right. A censor model should be understood not just as a set of capabilities|such as the ability to monitor network traffic—but as a set of priorities constrained by resource limitations. My research addresses the twin themes of modeling and circumvention. With a grounding in empirical research, I build up an abstract model of the circumvention problem and examine how to adapt it to concrete censorship challenges. I describe the results of experiments on censors that probe their strengths and weaknesses; specifically, on the subject of active probing to discover proxy servers, and on delays in their reaction to changes in circumvention. I present two circumvention designs: domain fronting, which derives its resistance to blocking from the censor's reluctance to block other useful services; and Snowflake, based on quickly changing peer-to-peer proxy servers. I hope to change the perception that the circumvention problem is a cat-and-mouse game that affords only incremental and temporary advancements.
    [Show full text]
  • Infoblox White Paper
    Enterprise Strategy Group | Getting to the bigger truth.™ White Paper Enterprise DNS Security By Jon Oltsik, Senior Principal Analyst March 2018 This ESG White Paper was commissioned by Infoblox and is distributed under license from ESG. © 2018 by The Enterprise Strategy Group, Inc. All Rights Reserved. White Paper: Enterprise DNS Security 2 Contents Executive Summary ................................................................................................................................................................. 3 The State of Cybersecurity in 2018 ......................................................................................................................................... 3 DNS and Cybersecurity ............................................................................................................................................................ 5 DNS for Cybersecurity Advantage ....................................................................................................................................... 5 Enterprise-Class Secure DNS ................................................................................................................................................... 6 Enter Infoblox ActiveTrust Suite (Cloud and On-premises) ................................................................................................ 7 The Bigger Truth .....................................................................................................................................................................
    [Show full text]
  • The ISP Column Diving Into The
    The ISP Column A column on various things Internet October 2018 Geoff Huston Diving into the DNS DNS OARC organizes two meetings a year. They are two-day meetings with a concentrated dose of DNS esoterica. Here’s what I took away from the recent 29th meeting of OARC, held in Amsterdam in mid-October 2018. Cloudflare's 1.1.1.1 service Cloudflare have been running an open public DNS resolver service on 1.1.1.1 for more than six months now. The service, based on the Knot resolver engine, is certainly fast (http://bit.ly/2PBfoSh), and Cloudflare's attention to scale and speed is probably appreciated by users of this service. However, in a broader Internet environment that is now very aware of personal privacy it’s not enough to be fast and accurate. You have to be clear that as an operator of a public DNS resolution service you may be privy to clients’ activities and interests, and you need to clearly demonstrate that you are paying attention to privacy. Not only does this include appropriate undertakings regarding the way you handle and dispose of the logs of the resolvers' query streams, but also in being mindful of the way that users can pass queries to the service. The 1.1.1.1 service supports DNS over TLS 1.3 and 1.2 using the GnuTLS system. This supports long-lived connection with client systems and also supports session resumption. There are a number of DNS tools that can use the DNS over a TLS connection including kdig (http://bit.ly/2A9f9rX, http://bit.ly/2OoLu7a), GetDNS (https://getdnsapi.net/), Unbound (http://bit.ly/2CIKEf0), Android P and the Tenta browser (https://tenta.com/).
    [Show full text]
  • Ikev2 Configuration for Encrypted DNS
    IKEv2 Configuration for Encrypted DNS draft-btw-add-ipsecme-ike Mohamed Boucadair (Orange) Tirumaleswar Reddy (McAfee, Inc.) Dan Wing (Citrix Systems, Inc.) Valery Smyslov (ELVIS-PLUS) July 2020, IETF#108 Agenda • Context • A Sample Use Case • IKE Configuration Attribute for Encrypted DNS • Next Steps 2 Problem Description • Several schemes to encrypt DNS have been specified – DNS over TLS (RFC 7858) – DNS over DTLS (RFC 8094) – DNS over HTTPS (RFC 8484) • …And others are being specified: – DNS over QUIC (draft-ietf-dprive-dnsoquic) • How to securely provision clients to use Encrypted DNS? This use can be within or outside the IPsec tunnel 3 A Sample Use Case: DNS Offload • VPN service providers can offer publicly accessible Encrypted DNS – the split-tunnel VPN configuration allows the client to access the DoH/DoT servers hosted by the VPN provider without traversing the tunnel 4 A Sample Use Case: Protecting Internal DNS Traffic • DoH/DoT ensures DNS traffic is not susceptible to internal attacks – see draft-arkko-farrell-arch-model-t-03#section-3.2.1 • encrypted DNS can benefit to Roaming Enterprise users to enhance privacy – With DoH/DoT the visibility of DNS traffic is limited to only the parties authorized to act on the traffic (“Zero Trust Architecture”) 5 Using IKE to Configure Encrypted DNS on Clients • New configuration attribute INTERNAL_ENC_DNS is defined to convey encrypted DNS information to clients: – Encrypted DNS type (e.g., DoH/DoT) – Scope of encrypted DNS use – One or more encrypted DNS server IPv6 addresses • For IPv4
    [Show full text]
  • Paper, We Note That Work Is with Help from Volunteer OONI Probe Users
    Measuring DoT/DoH Blocking Using OONI Probe: a Preliminary Study Simone Basso Open Observatory of Network Interference [email protected] Abstract—We designed DNSCheck, an active network exper- delivery networks (CDN). This fact raises concerns regarding iment to detect the blocking of DoT/DoH services. We imple- performance [25], competition, and privacy [14]. mented DNSCheck into OONI Probe, the network-interference (While DoH’s centralization and the resulting privacy con- measurement tool we develop since 2012. We compiled a list of popular DoT/DoH services and ran DNSCheck measurements cerns are not the focus of this paper, we note that work is with help from volunteer OONI Probe users. We present pre- underway to mitigate them [38] [24].) liminary results from measurements in Kazakhstan (AS48716), Simultaneously, the rollout of DoT and DoH does not Iran (AS197207), and China (AS45090). We tested 123 DoT/DoH fully solve the surveillance and censorship issues posed by services, corresponding to 461 TCP/QUIC endpoints. We found a cleartext internet. There are at least two remaining fields endpoints to fail or succeed consistently. In AS197207 (Iran), 50% of the DoT endpoints seem blocked. Otherwise, we found that could reveal the precise target of otherwise encrypted that more than 80% of the tested endpoints were always reach- communications. They are the Server Name Indication [19] able. The most frequently blocked services are Cloudflare’s and (SNI) extension inside the TLS ClientHello and the destination Google’s. In most cases, attempting to reach blocked endpoints IP address. However, in a landscape increasingly dominated by failed with a timeout.
    [Show full text]
  • A Cybersecurity Terminarch: Use It Before We Lose It
    SYSTEMS ATTACKS AND DEFENSES Editors: Davide Balzarotti, [email protected] | William Enck, [email protected] | Samuel King, [email protected] | Angelos Stavrou, [email protected] A Cybersecurity Terminarch: Use It Before We Lose It Eric Osterweil | George Mason University term · in · arch e /’ t re m , närk/ noun an individual that is the last of its species or subspecies. Once the terminarch dies, the species becomes extinct. hy can’t we send encrypt- in the Internet have a long history W ed email (secure, private of failure. correspondence that even our mail To date, there has only been one providers can’t read)? Why do our success story, and, fortunately, it is health-care providers require us to still operating. Today, almost ev- use secure portals to correspond erything we do online begins with a with us instead of directly emailing query to a single-rooted hierarchical us? Why are messaging apps the global database, whose namespace only way to send encrypted messag- is collision-free, and which we have es directly to friends, and why can’t relied on for more than 30 years: we send private messages without the Domain Name System (DNS). user-facing) layer(s). This has left the agreeing to using a single platform Moreover, although the DNS pro- potential to extend DNSSEC’s verifi- (WhatsApp, Signal, and so on)? Our tocol did not initially have verifica- cation protections largely untapped. cybersecurity tools have not evolved tion protections, it does now: the Moreover, the model we are using to offer these services, but why? DNS Security Extensions (DNS- exposes systemic vulnerabilities.
    [Show full text]
  • Godaddy – Domain Hijacking
    Domain Hijacking Matthew C. Stith, Spamhaus Eddy Winstead, ISC April 29th, 2020 https://www.isc.org What we’re going to covering • What why and how of domain hijacking • Examples of various hijacking methods • High profile stories about hijacked domains • What can be done to protect domains and networks • Q&A 2 What is Domain Hijacking? • Malicious actors gaining access to the DNS records of a legitimate domains (which they do not own): • In some cases only the root domain’s DNS is changed. This is reflected in the WHOIS. • In other cases a new host (subdomain) is created with new DNS settings. This practice is called domain shadowing. This is not visible at the WHOIS level. 3 Why is it exploited? These following two factors lead to a positive reputation: • The age of the domain • The legitimacy of the domain Meaning many of these domains could be able to send email or serve content without much scrutiny from content or reputation filters. 4 How is it happening? Phishing Social Compromised Exploiting Malware engineering DNS weaknesses in applications 5 Investigating domain hijacking • Passive DNS data is collected with special Client queries local DNS resolver Passive DNS Data probes activated on a DNS Resolver. Domain not included in cache • The probes record anonymized cache Data from Query external root server recursive miss. segment is recorded • Data is collected through DNS recursive Domain not found servers. Query top level domain server • Simple and extensive search functionalities make this data easy to Domain not found Client
    [Show full text]