The Resource Public Key Infrastructure (RPKI) was standardized to add cryptographic security to Internet routing. With over 50% of announced BGP prefixes protected with RPKI today, the protocol already impacts significant parts of Internet traffic. In addition to its growing adoption, there is also increasing political interest in RPKI. The White House indicated in its Roadmap to Enhance Internet Routing Security , on September 4, 2024, that RPKI is a mature and readily available technology for securing inter-domain routing. The Roadmap attributes the main obstacles toward wide adoption of RPKI to a lack of understanding, lack of prioritization, and administrative barriers. This article presents the first comprehensive study of the maturity of RPKI as a viable, production-grade technology. We find that current RPKI implementations still lack production-grade resilience and are plagued by software vulnerabilities, inconsistent specifications, and operational challenges, raising significant security concerns. The deployments lack experience with full-fledged, strict RPKI validation in production environments and operate in fail-open mode. We provide recommendations to improve RPKI resilience and guide stakeholders in securing their deployments against current and emerging threats. The numerous issues we have discovered with the current RPKI specifications and implementations inevitably lead to the question: Is RPKI sufficiently stable to align with the expectations outlined in the White House roadmap? Certainly, it is not perfect, but is it good enough? The answer, as we will explore, varies depending on one’s viewpoint.

The Resource Public Key Infrastructure (RPKI) secures the Internet's routing system by defining a complex trust and validation framework for certificates, Route Origin Authorizations (ROAs), manifests, and Certificate Revocation Lists (CRLs). These mechanisms are specified across dozens of RFCs. This paper presents the first comprehensive analysis of the causal link between flaws in RPKI Requests for Comments (RFCs) and vulnerabilities in implementations and real-world deployments. We reveal how vague, conflicting, or underspecified requirements in 50 RPKI RFCs propagate into inconsistent implementation behavior and operational failures. We conduct the first large-scale, impact-driven evaluation of RPKI specifications. Our methodology combines differential fuzzing of major RPKI implementations with Internet-wide crawling and validation log analysis, enabling us to trace practical vulnerabilities back to flawed RFC requirements. We uncover 61 previously undocumented inconsistencies in validation behavior, trace 23 directly to RFC flaws, and identify two novel vulnerabilities that were assigned CVEs. Our findings reveal that these are not isolated coding errors but rather systemic issues inherent in how RPKI standards are written, interpreted, and implemented. To mitigate these threats, we propose concrete recommendations and introduce a novel alerting service that monitors and reports live inconsistencies in RPKI deployments. Our open-source datasets, code, and tools support reproducibility and further research.

The democratization of access has transformed the Internet into the primary platform for social interaction and economic activity. The COVID-19 pansignificantly accelerated the digitalization of services, finance and communication. As critical infrastructure increasingly moves online, routing security is becoming a national security concern. U.S. regulatory bodies were the first to sound the alarm by formally recognizing the urgency of Internet routing security and calling for nationwide adoption of security protocols. The Resource Public Key Infrastructure (RPKI) protocol is already the leading standard for protecting Internet routing from hijacking attacks and route leaks. However, RPKI is not secure by design. Research on its security guarantees has shown that despite the minimal internet-facing interface, the software implementations are not only rife with issues, but the nature of these issues is such that they can be easily triggered to disconnect the RPKI security framework from Internet routing, thus severely downgrading RPKI protection benefits. In this work, we evaluate the security properties of RPKI, analyze its attack surface, the required attacker capabilities to launch them, and their consequences on global routing security. We propose that RPKI requires fundamental changes and improvements to mitigate its vulnerabilities, and become robust enough to withstand the eye of the storm.

Domain Validation (DV) is the primary method used by Certificate Authorities (CAs) to confirm administrative control over a domain before issuing digital certificates. Despite its widespread use, DV is vulnerable to various attacks, prompting the adoption of multiple vantage points to enhance security, such as the state of the art DV mechanism supported by Let's Encrypt. However, even distributed static vantage points remain susceptible to targeted attacks. In this paper we introduce ValidaTor, an HTTP-based domain validation system that leverages the Tor network to create a distributed and unpredictable set of validators. By utilizing Tor's exit nodes, ValidaTor significantly increases the pool of available validators, providing high path diversity and resilience against strong adversaries. Our empirical evaluations demonstrate that ValidaTor can achieve the validation throughput of a commercial CA and has the potential to scale to a validation volume comparable to Let's Encrypt, while using minimal dedicated infrastructure and only a small fraction (similar to 0.1%) of Tor's remaining available bandwidth. While unpredictable selection of validators makes ValidaTor fully resistant to targeted attacks on validators, we also show the use of Tor nodes improves path diversity and thereby the resilience of DV to subversion by well-positioned ASes, reducing the number of Autonomous Systems (ASes) capable of issuing fraudulent certificates by up to 27% compared to Let's Encrypt. Lastly, we show that the chance of subversion by malicious, colluding exit nodes is negligible (<= 1% even with a quarter of existing exit nodes). We make the code of ValidaTor as well as the datasets and measurements publicly available for use, reproduction, and future research.(1)

The Resource Public Key Infrastructure (RPKI) is the most successful routing defense mechanism currently deployed throughout critical Internet infrastructures around the world. According to recent works, RPKI deployment boasts over 55% global prefix resource coverage, and at least 27% global protocol enforcement; all this success over a short period of time. In this work, we investigate for the first time deployment trends of the Relying Party (RP), the RPKI component responsible for collecting and enforcing RPKI on routers. We map RP locations, deployment parameters, vulnerability distributions, and describe the evolution of deployment trends over two measurement periods three years apart. Through this exploratory analysis, we map global patterns and the preferred deployment configurations by network operators. We observe how within three years, RP traffic increased by 45%, while 89% of traffic stems from one software type. Our measurements show a strong preference by operators to self-host, coupled with inadequate rates of RP vulnerability mitigation.

The Resource Public Key Infrastructure (RPKI) is the main mechanism to protect inter-domain routing with BGP from prefix hijacks. It has already been widely deployed by large providers and the adoption rate is getting to a critical point. Almost half of all the global prefixes are now covered by RPKI and measurements show that 27% of networks are already using RPKI to validate BGP announcements. Over the past 10 years, there has been much research effort in RPKI, analyzing different facets of the protocol, such as software vulnerabilities, robustness of the infrastructure or the proliferation of RPKI validation. In this work we compile the first systemic overview of the vulnerabilities and misconfigurations in RPKI and quantify the security landscape of the global RPKI deployments based on our measurements and analysis. Our study discovers that 56% of the global RPKI validators suffer from at least one documented vulnerability. We also do a systematization of knowledge for existing RPKI security research and complement the existing knowledge with novel measurements in which we discover new trends in availability of RPKI repositories, and their communication patterns with the RPKI validators. We weave together the results of existing research and our study, to provide a comprehensive tableau of vulnerabilities, their sources, and to derive future research paths necessary to prepare RPKI for full global deployment.

Availability is a major concern in the design of DNSSEC. To ensure availability, DNSSEC follows Postel's Law [RFC1123]: "Be liberal in what you accept, and conservative in what you send." Hence, nameservers should send not just one matching key for a record set, but all the relevant cryptographic material, e.g., all the keys for all the ciphers that they support and all the corresponding signatures. This ensures that validation succeeds, and hence availability, even if some of the DNSSEC keys are misconfigured, incorrect or correspond to unsupported ciphers. We show that this design of DNSSEC is flawed. Exploiting vulnerable recommendations in the DNSSEC standards, we develop a new class of DNSSEC-based algorithmic complexity attacks on DNS, we dub KeyTrap attacks. All popular DNS implementations and services are vulnerable. With just a single DNS packet, the KeyTrap attacks lead to a 2.000.000x spike in CPU instruction count in vulnerable DNS resolvers, stalling some for as long as 16 hours. This devastating effect prompted major DNS vendors to refer to KeyTrap as the worst attack on DNS ever discovered. Exploiting KeyTrap, an attacker could effectively disable Internet access in any system utilizing a DNSSEC-validating resolver. We disclosed KeyTrap to vendors and operators on November 2, 2023, confidentially reporting the vulnerabilities to a closed group of DNS experts, operators and developers from the industry. Since then we have been working with all major vendors to mitigate KeyTrap, repeatedly discovering and assisting in closing weaknesses in proposed patches. Following our disclosure, the industry-wide umbrella CVE-2023-50387 has been assigned, covering the DNSSEC protocol vulnerabilities we present in this work.

In this work, we present a novel severe buffer-overflow vulnerability in the RPKI validator Fort, that allows an attacker to achieve Remote Code Execution (RCE) on the machine running the software. We discuss the unique impact of this RCE on networks that use RPKI, illustrating that RCE vulnerabilities are especially severe in the context of RPKI. The design of RPKI makes RCE easy to exploit on a large scale, allows compromise of RPKI validation integrity, and enables a powerful vector for additional attacks on other critical components of the network, like the border routers. We analyze the vulnerability exposing to this RCE and identify indications that the discovered vulnerability could constitute an intentional backdoor to compromise systems running the software over a benign coding mistake. We disclosed the vulnerability, which has been assigned a CVE rated 9.8 critical (CVE-2024-45237).

The security and availability of DNS are of major concern for many critical Internet services. Recently, KeyTrap algorithmic complexity Denial of Service attacks were demonstrated against DNSSEC-validating DNS resolvers [6]. The attacks exploit the validation complexity in DNSSEC to stall DNS resolvers, some for as long as 16h with just a single DNS response. Although short term patches were immediately implemented by the vendors, the attack can still produce a heavy load in some patched DNS resolvers. This work proposes new protocol-level mitigations for the KeyTrap vulnerabilities, using a new DNSSEC record that outlaws keytag collisions while ensuring backward compatibility. Further, this work raises the question of how much RFCs could and should dictate implementation-level limits to prevent DoS through complex validation routines. With our discussions, we aim to provide a solid foundation to improve the DNSSEC standard, mitigating KeyTrap and providing more robust recommendations for DNS implementations in the future.

NSEC3 is a proof of non-existence in DNSSEC, which provides an authenticated assertion that a queried resource does not exist in the target domain. NSEC3 consists of alphabetically sorted hashed names before and after the queried hostname. To make dictionary attacks harder, the hash function can be applied in multiple iterations, which however also increases the load on the DNS resolver during the computation of the SHA-1 hashes in NSEC3 records. Concerns about the load created by the computation of NSEC3 records on the DNS resolvers were already considered in the NSEC3 specifications RFC5155 and RFC9276. In February 2024, the potential of NSEC3 to exhaust DNS resolvers' resources was assigned a CVE-2023-50868, confirming that extra iterations of NSEC3 created substantial load. However, there is no published evaluation of the attack and the impact of the attack on the resolvers was not clarified. In this work we perform the first evaluation of the NSEC3encloser attack against DNS resolver implementations and find that the NSEC3-encloser attack can still create a 72x increase in CPU instruction count, despite the victim resolver following RFC5155 recommendations in limiting hash iteration counts. The impact of the attack varies across the different DNS resolvers, but we show that with a sufficient volume of DNS packets the attack can increase CPU load and cause packet loss. We find that at a rate of 150 malicious NSEC3 records per second, depending on the DNS implementation, the loss rate of benign DNS requests varies between 2.7% and 30%. We provide a detailed description and implementation of the NSEC3-encloser attack. We also develop the first analysis how each NSEC3 parameter impacts the load inflicted on the victim resolver during NSEC3-encloser attack. We make the code of our NSEC3-encloser attack implementation along with the zonefile and the evaluation data available for public use: https://github.com/Goethe- Universitat- Cybersecurity/NSEC3- Encloser-Attack.

Over recent years, the Resource Public Key Infrastructure (RPKI) has seen increasing adoption, with now 37.8% of the major networks filtering bogus BGP routes. Systems interact with the RPKI over Relying Party (RP) implementations that fetch RPKI objects and feed BGP routers with the validated prefix-ownership data. Consequently, any vulnerabilities or flaws within the RP software can substantially threaten the stability and security of Internet routing. We uncover severe flaws in all popular RP implementations, making them susceptible to path traversal attacks, remotely triggered crashes, and inherent inconsistencies, violating RPKI standards. We report a total of 18 vulnerabilities that canbe exploited to downgrade RPKI validation in border routers or, worse, enable poisoning of the validation process, resulting in malicious prefixes being wrongfully validated and legitimate RPKI-covered prefixes failing validation. Furthermore, our research discloses inconsistencies in the validation process, with two popular implementations leaving 8149 prefixes unprotected from hijacks, 6405 of which belong to Amazon. While these findings are significant in their own right, our principal contribution lies in developing CURE, the first-of-its-kind system to systematically detect bugs, vulnerabilities, and RFC compliance issues in RP implementations via automated test generation. CURE is a powerful RPKI publication point emulator that enables easy and efficient fuzzing of complex RP validation pipelines. It is designed with a set of novel techniques, utilizing differential and stateful fuzzing. We generated over 600 million test cases and tested all popular RPs on them. Following our disclosure, the vendors already assigned CVEs to the vulnerabilities we found.

Recent works showed that it is feasible to hijack resources on cloud platforms. In such hijacks, attackers can take over released resources that belong to legitimate organizations. It was proposed that adversaries could abuse these resources to carry out attacks against customers of the hijacked services, e.g., through malware distribution. However, to date, no research has confirmed the existence of these attacks. We identify, for the first time, real-life hijacks of cloud resources. This yields a number of surprising and important insights. First, contrary to previous assumption that attackers primarily target IP addresses, our findings reveal that the type of resource is not the main consideration in a hijack. Attackers focus on hijacking records that allow them to determine the resource by entering freetext. The costs and overhead of hijacking such records are much lower than those of hijacking IP addresses, which are randomly selected from a large pool. Second, identifying hijacks poses a substantial challenge. Monitoring resource changes, e.g., changes in content, is insufficient, since such changes could also be legitimate. Retrospective analysis of digital assets to identify hijacks is also arduous due to the immense volume of data involved and the absence of indicators to search for. To address this challenge, we develop a novel approach that involves analyzing data from diverse sources to effectively differentiate between malicious and legitimate modifications. Our analysis has revealed 20,904 instances of hijacked resources on popular cloud platforms. While some hijacks are short-lived (up to 15 days), 1/3 persist for more than 65 days. We study how attackers abuse the hijacked resources and find that, in contrast to the threats considered in previous work, the majority of the abuse (75%) is blackhat search engine optimization.

The Resource Public Key Infrastructure (RPKI) protocol was standardized to add cryptographic security to Internet routing. With over 50 resources protected with RPKI today, the protocol already impacts significant parts of Internet traffic. In addition to its growing adoption, there is also increasing political interest in RPKI. The White House indicated in its Roadmap to Enhance Internet Routing Security, on 4 September 2024, that RPKI is a mature and readily available technology for securing inter-domain routing. The Roadmap attributes the main obstacles towards wide adoption of RPKI to a lack of understanding, lack of prioritization, and administrative barriers. This work presents the first comprehensive study of the maturity of RPKI as a viable production-grade technology. We find that current RPKI implementations still lack production-grade resilience and are plagued by software vulnerabilities, inconsistent specifications, and operational challenges, raising significant security concerns. The deployments lack experience with full-fledged strict RPKI-validation in production environments and operate in fail-open test mode. We provide recommendations to improve RPKI resilience and guide stakeholders in securing their deployments against emerging threats. The numerous issues we have discovered with the current RPKI specifications and implementations inevitably lead to the question: Is RPKI sufficiently stable to align with the expectations outlined in the White House roadmap? Certainly, it is not perfect, but is it good enough? The answer, as we will explore, varies depending on one's viewpoint.

To protect against prefix hijacks, Resource Public Key Infrastructure (RPKI) has been standardized. To enjoy the security guarantees of RPKI validation, networks need to install a new component, the relying party validator, which fetches and validates RPKI objects and provides them to border routers. However, recent work shows that relying parties experience failures when retrieving RPKI objects and are vulnerable to attacks, all of which can disable RPKI validation. Therefore even the few adopters are not necessarily secure. We make the first proposal that significantly improves the resilience and security of RPKI. We develop BRP, a Byzantine-Secure relying party implementation. In BRP the relying party nodes redundantly validate RPKI objects and reach a global consensus through voting. BRP provides an RPKI equivalent of public DNS, removing the need for networks to install, operate, and upgrade their own relying party instances while avoiding the need to trust operators of BRP nodes. We show through simulations and experiments that BRP, as an intermediate RPKI service, results in less load on RPKI publication points and a robust output despite RPKI repository failures, jitter, and attacks. We engineer BRP to be fully backward compatible and readily deployable - it does not require any changes to the border routers and the RPKI repositories. We demonstrate that BRP can protect many networks transparently, with either a decentralized or centralized deployment. BRP can be set up as a network of decentralized volunteer deployments, similarly to NTP and TOR, where different operators participate in the peering process with their node, and provide resilient and secure relying party validation to the Internet. BRP can also be hosted by a single operator as a centralized service, e.g., on one cloud or CDN, and provides RPKI validation benefits even when hosted on a single network.

Login pages, including those for processes like sign-up, registration, and password recovery are interfaces that implement access control to company services or functionalities. Insufficient security on these pages could allow malicious individuals to gain access to services and network of an organization and launch attacks. In this work, we perform a comprehensive study of the security of 73.4k login interfaces of the 100-top European companies from the Fortune report, which we call EU100. We find over 9 million vulnerabilities, which we analyze from a technical perspective, and categorize them according to the hosting model. Our work provides details on the most commonly observed vulnerabilities on login pages across different sectors and according to the hosting strategy adopted by each company.

Domain validation is the primary method used by Certificate Authorities for affirming administrative control over a domain for issuing TLS certificates. Prior work has repeatedly shown its vulnerability to hijacking, prompting the use of multiple vantage points for validation. However, the use of static vantage points, as in Let's Encrypt's MultiVA system, is still subject to targeted attacks. Validators should therefore be both distributed and selected in an unpredictable fashion, which is expensive to achieve with dedicated infrastructure. We take a novel approach to tackle the limitations imposed by dedicated infrastructure on domain validation. We develop a system, dubbed ADDVent, that leverages advertisement networks (adnets) to recruit and orchestrate web clients as a massively distributed and unpredictably arranged set of validators, resistant to targeted hijacking. We experimentally demonstrate that, at lower cost than with dedicated infrastructure, ADDVent achieves performance comparable to Let's Encrypt. We characterize the effects of key parameters to control cost and throughput and we show that the system achieves less exposure to interception than the MultiVA deployment, through better distribution of validators. Since ADDVent uses an untrusted pool of web clients, we discuss a variety of countermeasures to address possible manipulation through Sybil attacks, including methods based on the coordination of secrets between adnet and orchestration server for separating legitimate and malicious clients.

Die Voraussetzungen für Innovationen in der Cybersicherheit sind, weltweit betrachtet, hervorragend. Der Bedarf ist hoch, es gibt viel Forschung und Entwicklung. Der Cybersicherheitsmarkt wächst mit über 13 gut aufgestellt, im internationalen Cybersicherheitsmarkt spielt Deutschland aber keine vergleichbar führende Rolle. Was hindert uns daran, zu den Innovationsführern USA und Israel aufzuschließen?

Navigating the maze of contemporary organizational attack surfaces is paramount in fortifying our defenses against the relentless tide of cyber incidents. However, existing network reconnaissance and security measurements, which enumerate IP addresses or scan popular domains searching for vulnerabilities, capture only a fragmented view of the risk landscape, neglecting the nuanced reality of modern organizational assets. We experimentally show that such scans miss out on most assets of large organizations since they do not consider the increasingly complex IT architectures. We perform the first security analysis of the external attack surface of the 100-top enterprises in Europe. We discover the digital assets belonging to the enterprises and analyze the security of the services per 3 attack surface areas: (1) self-hosted on on-premises, (2) the services hosted on cloud, and (3) the services outsourced to external providers. The last one is usually shadowed under the traditional on-premises and the modern Cloud and has not been studied or compared to them. Our analysis shows that it is a large and significant part of the digital footprint of enterprises. In general, our analysis shows that organizations in different sectors have distinct IT architectures and are built differently, as a result, the security issues vary across the sectors. More importantly, for each sector, the security issues in each of the 3 areas differ from each other. This demonstrates the need for a more granular approach when analyzing organizations. Based on our findings, we provide recommendations per sector per area. We also initiated a disclosure campaign notifying the enterprises of the identified vulnerabilities.

Kryptoagilität gewährleistet die langfristige Sicherheit von Kryptografie, denn kryptoagile Systeme sind offen für Innovationen in der Kryptografie und verbessern die Widerstandsfähigkeit bei Angriffen auf einzelne Verfahren. Dieser Impulsbeitrag gibt auf unterschiedlichen Ebenen und an verschiedene Stakeholder Empfehlungen zur Berücksichtigung, Umsetzung und Weiterentwicklung von Kryptoagilität.

Resource Public Key Infrastructure (RPKI), designed to protect Internet routing from hijacks, is gaining traction: over 50% of prefixes have digital certificates, at least 27% of Autonomous Systems actively validate certificates against BGP announcements, and filter invalid routing announcements. In this study, we present the first security analysis of Krill, the only public and open-source RPKI publication point software. Publication points are hosted by the five Regional Internet Registries across the globe, or by independent Internet operators that wish to manage their own RPKI repositories. Through a detailed investigation of Krill, involving API, command line, configuration parsings, and static code analysis, we identify significant vulnerabilities such as transient dependencies and Denial-of-Service (DoS) exploits. Our key findings reveal Krill's susceptibility to path traversal attacks in case of misconfigured Nginx proxies, and a DoS vulnerability stemming from the h2 rust library. We develop an attack vector that exploits the rust library vulnerability, which leads to a 350x performance degradation. Our results indicate that RPKI is not yet production-grade ready as its main component, the publication points - which host the RPKI objects, are vulnerable to information leaks and DoS attacks.