DNS cache poisoning is a persistent game of attack and defense, posing an enduring challenge for the DNS community. Significant efforts have been made to uncover, detect, and mitigate vulnerabilities that increase the risk of cache poisoning. However, no work has systematically revisited whether the original cache poisoning attack based on the Birthday Paradox remains effective. In this work, we introduce RebirthDay, a novel DNS cache poisoning attack targeting recursive resolvers and forwarders, reviving the classic DNS Birthday attack that no longer works since 2002. RebirthDay exploits newly uncovered, protocol-compliant vulnerabilities in DNS extension implementations to bypass the query aggregation mechanism intended to prevent DNS Birthday attacks that has not been well understood. We uncovered that 18 out of 22 mainstream DNS software are vulnerable due to weaknesses in the processing of a DNS extension (i.e., ECS option), specifically lacking or incorrectly implemented ECS coherence checks when handling DNS queries and responses, demonstrating the widespread susceptibility to RebirthDay. These flaws could be exploited to circumvent the query aggregation mechanism and launch RebirthDay attacks. Through comprehensive evaluation, we showed that RebirthDay attacks are highly practical and can have significant real-world impact, affecting 16 router vendors, 14 public DNS services, and 365K (15%) open DNS resolvers. We have reported the identified vulnerabilities to affected vendors and discussed mitigation solutions with them. To date, we have received acknowledgments from 8 vendors, including BIND, Unbound, PowerDNS, and Quad9, and have been assigned 50 CVE-ids. Our study emphasizes the need for greater attention to the importance of ECS verification and DNS extension implementations, revealing new security risks introduced by them.

The Domain Name System (DNS) is designed to be distributed, which aims to provide services with low latency and great reliability. However, after decades of development and changes in Internet business models, various aspects of the DNS ecosystem have begun to show signs of centralization. To investigate the centralization from the viewpoint of hosting service providers, we develop an automated method based on similarity among NS domains and co-hosting relationship to identify the hosting providers for authoritative name servers, so that we can identify hosting providers in DNS zone file to count the number of domains which a hosting provider host. This tool demonstrates greater accuracy than previous methods and our testing demonstrates the ability to identify hosting service providers for most domains in real-world measurement tasks. Using this tool, we conducted measurements on the dataset combined with .com, .net and .org TLD zones. We find that the top 10 providers collectively host over 54.19% of domains while top 100 providers host over 82.99% domains, which shows a significant level of centralization in hosting service providers within the DNS. Through an analysis of NSone’s NS domains and a statistical examination of top providers’ NS domains, we find that directly identifying the base domain as the provider is inappropriate. Furthermore, we discover relationships among hosting providers and between hosting providers and infrastructure that are more complex than previously anticipated. Finally, based on our research findings, we offer corresponding suggestions to mitigate the continued development of centralization.

Transport Layer Security (TLS) is a cornerstone to secure Internet communications. It requires proper deployment and validation of certificate chains. During validation, clients must first construct the chain from server-provided certificates. However, existing research often integrates chain construction into the broader validation process, lacking independent analysis of this crucial step. This paper presents the first systematic assessment of certificate chain construction, covering server-side deployment compliance and client-side capabilities. On the server side, we summarized structural requirements from RFC standards and evaluated real-world website compliance. We found that approximately 3% of Tranco Top 1M domains have deployed non-compliant chains, with common issues including reversed sequences and incomplete chains. The compliance would be influenced by HTTP server and Certificate Authority checks and guidance during the configuration process. On the client side, we evaluated 9 types of chain-building capabilities across 8 mainstream TLS implementations, uncovering prevalent deficiencies like inadequate backtracking and difficulties with long chains. These deficiencies could compromise TLS security, causing a fallback to insecure HTTP or making the service unavailable. Our findings highlight critical gaps in current certificate chain practices. Based on our findings, we also propose recommendations for improving the deployment and construction of certificate chains.

The global PKI supports the issuance of Unicerts, which are X.509 certificates that integrate internationalized content such as IDNs and multilingual text. This integration introduces complexity in Unicert issuance and usage. Past incidents showed that poor Unicode handling can cause security risks, including spoofing and remote code execution, yet threats specific to PKI and Unicerts remain underexplored. This paper presents the first large-scale study of Unicerts, examining both issuance and parsing compliance. By analyzing 34.8 million Unicerts from CT logs and 9 mainstream TLS libraries, we found the PKI ecosystem struggles with adopting Unicode. On the issuing side, 373 issuers produced 249.3K (0.72%) noncompliant Unicerts due to weak validation on character ranges, normalization, and formatting, of which 65.3% arise from publicly trusted CAs. These issues arise from overly complex standard requirements. On the parsing side, TLS libraries like GnuTLS and PyOpenSSL exhibited issues in decoding and handling special characters, such as incompatible decoding and improper escaping, which could lead to incorrect entity extraction or subfield forgery. We further empirically identified threat surfaces, including user spoofing, CT monitor misleading, and traffic obfuscation. Finally, we analyzed root causes and proposed recommendations to enhance Unicert compliance in the global PKI ecosystem.

DNS can be compared to a game of chess in that its rules are simple, yet the possibilities it presents are endless. While the fundamental rules of DNS are straightforward, DNS implementations can be extremely complex. In this study, we intend to explore the complexities and vulnerabilities in DNS response pre-processing by systematically analyzing DNS RFCs and DNS software implementations. We present the discovery of three new types of logic vulnerabilities, leading to the proposal of three novel attacks, namely the TuDoor attack. These attacks involve the use of malformed DNS response packets to carry out DNS cache poisoning, denial- of-service, and resource consuming attacks. By performing comprehensive experiments, we demonstrate the attack’s feasibility and significant real-world impacts of TUDOOR. In total, 24 mainstream DNS software, including BIND, PowerDNS, and Microsoft DNS, are affected by TuDoor. Attackers can instigate cache poisoning and denial-of-service attacks against vulnerable resolvers using a handful of crafted packets within 1 second or circumvent the query limit to deplete resolution resources (e.g., CPU). Besides, to determine the vulnerable resolver population in the wild, we collect and evaluate 16 popular Wi-Fi routers, 6 prevalent router OSes, 42 public DNS services, and around 1.8M open DNS resolvers. Our measurement results indicate that TUDOOR could exploit 7 routers (OSes), 18 public DNS services, and 424,652 (23.1%) open DNS resolvers. Following the best practice of responsible disclosure, we have reported these vulnerabilities to all affected vendors, and 18 of them, including BIND, Chrome, Cloudflare, and Microsoft, have acknowledged our findings and discussed mitigation solutions with us. Furthermore, 33 CVE IDs are assigned to our discovered vulnerabilities, and we provide an online detection tool as one of the mitigation measures. Our research highlights the urgent need for standardization of DNS response pre-processing logic to enhance the security of DNS.

The Internet has become a complex distributed network with numerous middle-boxes, where an end-to-end HTTP request is often processed by multiple intermediate servers before it reaches its destination. However, a general problem in this distributed network is the semantic gap attack, which is defined as inconsistent semantic interpretations in the processing chain. While some studies have found individual semantic gap attacks, most of them are based on ad-hoc manual analysis, which is inadequate for fundamentally enhancing the security assurance of a system as complex as the HTTP network.In this work, we propose HDiff, a novel semi-automatic detecting framework, systematically exploring semantic gap attacks in HTTP implementations. We designed a documentation analyzer that employs natural language processing techniques to extract rules from specifications, and utilized differential testing to discover semantic gap attacks. We implemented and evaluated it to find three kinds of semantic gap attacks in 10 popular HTTP implementations. In total, HDiff found 14 vulnerabilities and 29 affected server pairs covering all three types of attacks. In particular, HDiff also discovered three new types of attack vectors. We have already duly reported all identified vulnerabilities to the involved HTTP software vendors and obtained 7 new CVEs from well-known HTTP software, including Apache, Tomcat, Weblogic, and Microsoft IIS Server.

HTTPS is principally designed for secure end-to-end communication, which adds confidentiality and integrity to sensitive data transmission. While several man-in-the-middle attacks (e.g., SSL Stripping) are available to break the secured connections, state-of-the-art security policies (e.g., HSTS) have significantly increased the cost of successful attacks. However, the TLS certificates shared by multiple domains make HTTPS hijacking attacks possible again.

DNS packets are designed to travel in unencrypted form through the Internet based on its initial standard. Recent discoveries show that real-world adversaries are actively exploiting this design vulnerability to compromise Internet users' security and privacy. To mitigate such threats, several protocols have been proposed to encrypt DNS queries between DNS clients and servers, which we jointly term as DNS-over-Encryption. While some proposals have been standardized and are gaining strong support from the industry, little has been done to understand their status from the view of global users.