Detecting and Refactoring Operational Smells within the Domain Name System

The Domain Name System (DNS) is one of the most important components of the Internet infrastructure. DNS relies on a delegation-based architecture, where resolution of names to their IP addresses requires resolving the names of the servers responsible for those names. The recursive structures of the inter dependencies that exist between name servers associated with each zone are called dependency graphs. System administrators' operational decisions have far reaching effects on the DNSs qualities. They need to be soundly made to create a balance between the availability, security and resilience of the system. We utilize dependency graphs to identify, detect and catalogue operational bad smells. Our method deals with smells on a high-level of abstraction using a consistent taxonomy and reusable vocabulary, defined by a DNS Operational Model. The method will be used to build a diagnostic advisory tool that will detect configuration changes that might decrease the robustness or security posture of domain names before they become into production.Comment: In Proceedings GaM 2015, arXiv:1504.0244

Understanding the Role of Registrars in DNSSEC Deployment

The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC’s deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed. In this paper, we investigate the underlying reasons why DNSSEC adoption has been remarkably slow. We focus on registrars, as most TLD registries already support DNSSEC and registrars often serve as DNS operators for their customers. Our study uses large-scale, longitudinal DNS measurements to study DNSSEC adoption, coupled with experiences collected by trying to deploy DNSSEC on domains we purchased from leading domain name registrars and resellers. Overall, we find that a select few registrars are responsible for the (small) DNSSEC deployment today, and that many leading registrars do not support DNSSEC at all, or require customers to take cumbersome steps to deploy DNSSEC. Further frustrating deployment, many of the mechanisms for conveying DNSSEC information to registrars are error-prone or present security vulnerabilities. Finally, we find that using DNSSEC with third-party DNS operators such as Cloudflare requires the domain owner to take a number of steps that 40% of domain owners do not complete. Having identified several operational challenges for full DNSSEC deployment, we make recommendations to improve adoption

Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild

The core specifications of electronic mail as used today date back as early as the 1970s. At that time, security did not play a significant role in developing communication protocols. These shortcomings still manifest themselves today in the prevalence of phishing and the reliance on opportunistic encryption. Besides STARTTLS, various mechanisms such as SPF, DKIM, DMARC, DANE, and MTA-STS have been proposed. However, related work has shown that not all providers support them and that misconfigurations are common. In this work, we provide a comprehensive overview of the current state of email confidentiality and integrity measures, as well as the effectiveness of their deployment. On a positive note, support for incoming TLS connections has significantly increased over the years, with over 96% of reachable MXs in the top 10 million domains allowing for explicit TLS. Notably, 30% of presented certificates are invalid, though, with the majority of issues related to the presented hostnames. In light of this, all 47 providers we tested connect to hosts with expired, self-signed, non-matching certificates, making it trivial for attackers to intercept their connections. Our analysis also shows that still only around 40% of sites specify SPF, and even high-ranked providers like t-online.de do not enforce it. Similarly, while DNS lookups are performed for both DKIM and DANE, neither mechanism is validated or enforced by all providers. In addition, we show that MTA-STS is only slowly getting traction (six providers support it) and provide the first large-scale analysis into OPENPGPKEY and SMIMEA records. All in all, this still paints a grim yet slightly improving picture for the state of email security by late 2022

Internet-Wide Evaluations of Security and Vulnerabilities

The Internet significantly impacts the world culture. Since the beginning, it is a multilayered system, which is even gaining more protocols year by year. At its core, remains the Internet protocol suite, where the fundamental protocols such as IPv4, TCP/UDP, DNS are initially introduced. Recently, more and more cross-layer attacks involving features in multiple layers are reported. To better understand these attacks, e.g. how practical they are and how many users are vulnerable, Internet-wide evaluations are essential. In this cumulative thesis, we summarise our findings from various Internet-wide evaluations in recent years, with a main focus on DNS. Our evaluations showed that IP fragmentation poses a practical threat to DNS security, regardless of the transport protocol (TCP or UDP). Defense mechanisms such as DNS Response Rate Limiting could facilitate attacks on DNS, even if they are designed to protect DNS. We also extended the evaluations to a fundamental system which heavily relies on DNS, the web PKI. We found that Certificate Authorities suffered a lot from previous DNS vulnerabilities. We demonstrated that off-path attackers could hijack accounts at major CAs and manipulate resources there, with various DNS cache poisoning attacks. The Domain Validation procedure faces similar vulnerabilities. Even the latest Multiple-Validation-Agent DV could be downgraded and poisoned. On the other side, we also performed Internet-wide evaluations of two important defence mechanisms. One is the cryptographic protocol for DNS security, called DNSSEC. We found that only less than 2% of popular domains were signed, among which about 20% were misconfigured. This is another example showing how poorly deployed defence mechanisms worsen the security. The other is ingress filtering, which stops spoofed traffic from entering a network. We presented the most completed Internet-wide evaluations of ingress filtering, which covered over 90% of all Autonomous Systems. We found that over 80% of them were vulnerable to inbound spoofing

An analysis on the implementation of secure web-related protocols in portuguese city councils

The services supporting the websites, both public and private entities, may support security protocols such as HTTPS or DNSSEC. Public and private entities have a responsibility to ensure the security of their online platforms. Entities in the public domain such as city councils provide their services through their websites. However, each city council has its systems, configurations, and IT teams, and this means they have different standings regarding the security protocols supported. This paper analyzes the status of security protocols on Portuguese city council websites, specifically HTTPS and DNSSEC. The study evaluated 308 city council websites using a script developed for the research, and data was collected from the website of Direção Geral das Autarquias Locais (DGAL) on December 14, 2022, and the websites were scanned on December 22, 2022. The results of this assessment reveal that around 97% of city council websites use RSA as their encryption algorithm and around 84% use 2048-bit length keys for digital certificate signing. Furthermore, about 53% of the city council websites are still supporting outdated and potentially insecure SSL/TLS versions, and around 95% of the councils are not implementing DNSSEC in their domains. These results highlight potential areas for improvement in cybersecurity measures and can serve as a baseline to track progress toward improving cybersecurity maturity in Portuguese city councils.A41D-7428-BA6C | Jackson Barreto Costa JúniorN/

Dial N for NXDomain: The Scale, Origin, and Security Implications of DNS Queries to Non-Existent Domains

Non-Existent Domain (NXDomain) is one type of the Domain Name System (DNS) error responses, indicating that the queried domain name does not exist and cannot be resolved. Unfortunately, little research has focused on understanding why and how NXDomain responses are generated, utilized, and exploited. In this paper, we conduct the first comprehensive and systematic study on NXDomain by investigating its scale, origin, and security implications. Utilizing a large-scale passive DNS database, we identify 146,363,745,785 NXDomains queried by DNS users between 2014 and 2022. Within these 146 billion NXDomains, 91 million of them hold historic WHOIS records, of which 5.3 million are identified as malicious domains including about 2.4 million blocklisted domains, 2.8 million DGA (Domain Generation Algorithms) based domains, and 90 thousand squatting domains targeting popular domains. To gain more insights into the usage patterns and security risks of NXDomains, we register 19 carefully selected NXDomains in the DNS database, each of which received more than ten thousand DNS queries per month. We then deploy a honeypot for our registered domains and collect 5,925,311 incoming queries for 6 months, from which we discover that 5,186,858 and 505,238 queries are generated from automated processes and web crawlers, respectively. Finally, we perform extensive traffic analysis on our collected data and reveal that NXDomains can be misused for various purposes, including botnet takeover, malicious file injection, and residue trust exploitation

A matter of degree:characterizing the amplification power of open DNS resolvers

Open DNS resolvers are widely misused to bring about reflection and amplification DDoS attacks. Indiscriminate efforts to address the issue and take down all resolvers have not fully resolved the problem, and millions of open resolvers still remain available to date, providing attackers with enough options. This brings forward the question if we should not instead focus on eradicating the most problematic resolvers, rather than all open resolvers indiscriminately. Contrary to existing studies, which focus on quantifying the existence of open resolvers, this paper focuses on infrastructure diversity and aims at characterizing open resolvers in terms of their ability to bring about varying attack strengths. Such a characterization brings nuances to the problem of open resolvers and their role in amplification attacks, as it allows for more problematic resolvers to be identified. Our findings show that the population of open resolvers lies above 2.6M range over our one-year measurement period. On the positive side, we observe that the majority of identified open resolvers cut out when dealing with bulky and DNSSEC-related queries, thereby limiting their potential as amplifiers. We show, for example, that 59% of open resolvers lack DNSSEC support. On the downside, we see that a non-negligible number of open resolvers facilitate large responses to ANY and TXT queries (8.1% and 3.4% on average, respectively), which stands to benefit attackers. Finally we show that by removing around 20% of potent resolvers the global DNS amplification potential can be reduced by up to 80%

{SoK}: {An} Analysis of Protocol Design: Avoiding Traps for Implementation and Deployment

Today's Internet utilizes a multitude of different protocols. While some of these protocols were first implemented and used and later documented, other were first specified and then implemented. Regardless of how protocols came to be, their definitions can contain traps that lead to insecure implementations or deployments. A classical example is insufficiently strict authentication requirements in a protocol specification. The resulting Misconfigurations, i.e., not enabling strong authentication, are common root causes for Internet security incidents. Indeed, Internet protocols have been commonly designed without security in mind which leads to a multitude of misconfiguration traps. While this is slowly changing, to strict security considerations can have a similarly bad effect. Due to complex implementations and insufficient documentation, security features may remain unused, leaving deployments vulnerable. In this paper we provide a systematization of the security traps found in common Internet protocols. By separating protocols in four classes we identify major factors that lead to common security traps. These insights together with observations about end-user centric usability and security by default are then used to derive recommendations for improving existing and designing new protocols---without such security sensitive traps for operators, implementors and users