The Internet consists of networks called Autonomous Systems (ASes), which are connected via the Border Gateway Protocol (BGP). Routers in each AS send BGP announcements to exchange information about their reachability. Based on this information, BGP calculates the best routes to Internet destinations, over which data packets are delivered. Since any AS can announce any prefix, malicious ASes can exploit this to claim prefixes they do not own, and as a result, hijack the traffic destined to those victim prefixes. Such hijacks are even more often caused by benign misconfigurations and errors. IP prefix hijacks allow adversaries to intercept, manipulate or blackhole communication.
RPKI to filter bogus BGP announcements
To protect inter-domain routing against prefix hijacks, the IETF-standardized Resource Public Key Infrastructure (RPKI): The ASes can sign the prefixes assigned to them, creating Route Origin Authorizations (ROAs) and store them in repositories at RPKI publication points. These ROAs indicate which ASes are authorized to originate a given prefix in BGP.
To filter bogus BGP announcements, ASes should enforce Route Origin Validation (ROV), which uses the information in ROAs to make routing decisions in BGP. The ROAs are retrieved from the publication points using one of the relying party implementations. The relying party processes the ROAs and caches the results. The BGP routers retrieve the validated ROAs from the relying parties to perform ROV to check the BGP announcements against the ROAs. If the information in the BGP announcement matches the ROA, the relying party validation results in a valid status. If the information in the BGP announcement does not match the ROA for that prefix, the result is invalid. When no ROA can be found for a prefix, the result of the RPKI validation is unknown.
On the risk of misbehaving publication points
In our recent research, we at the National Research Center for Applied Cybersecurity ATHENE, Fraunhofer SIT, Goethe-Universität Frankfurt, and Technische Universität Darmstadt considered the impact of malicious publication points on the resilience of RPKI.
To understand the attack surface introduced by misbehaving or malicious publication points, we briefly list some of the components and protocols involved during the retrieval of the RPKI objects (primarily ROAs) by the relying parties.
The process starts when the refresh interval is reached with a lookup query to find the publication point; the stub DNS resolver sends the query to the recursive DNS resolver and so on, until the relying party receives the IP address of the publication point.
The relying party establishes a TCP connection and retrieves the RPKI objects over rsync or RRDP (HTTPS based protocol) from the publication point. This process is repeated until all the publication points are traversed and all the objects are retrieved.
The multiple components involved offer a myriad of possibilities to attempt to attack the protocols and systems in different layers, from attacks against the DNS components, to HTTP specific attacks in the application layer, and all the way to attacks against fragmentation in the network layer. The attacks can exploit the rate limiting or the server selection mechanism in DNS servers or increase the retrieval time by returning slow responses like in a Slowloris attack or target the parsing by forging malformed RPKI objects. These are known attacks, whose outcomes range from Denial of Service to crashing the target victim system. To prevent these attacks, the systems should be patched to support best security practices.
Stalling relying parties
In our research, we explored the threat of stalling the relying party implementations and its impact on RPKI validation. The idea behind our attack is to develop a complex chain of delegations that cause the victim relying party to stall.
To do that the adversary sets up an RPKI publication point, which delegates part of the resources to publication points of the children, which in turn, delegate to their children and so on, creating long delegation chains. When the relying parties traverse those delegations, they get stalled and cannot retrieve the ROAs.
After the locally cached RPKI objects expire, the RPKI validation cannot be performed, resulting in status ‘unknown’ for prefixes with missing objects. As a result, the routing decisions by the BGP routers are made without filtering bogus BGP announcements with ROV — downgrading RPKI validation.
Requirements and hurdles for launching Stalloris attack
The requirements for executing the Stalloris attack are modest. Since the relying parties are supposed to traverse all the publication points in the Internet, the adversary only needs to set up a malicious publication point and a certificate authority, with a delegation from the parent, for example, APNIC. Since these are standard steps for deploying RPKI, owners of ASes can easily fulfill these requirements. Hence, these are realistic attacks for most BGP prefix hijacking adversaries.
The other challenges are technical. In our research we found that merely stalling the relying parties does not directly lead to meaningful attacks against the RPKI validation. The reason is that the relying party preserves the state in which it is stalled. In particular, if the ROA validation resulted in status ‘valid’, the relying party preserves this state when it is stalled. Therefore, the bogus BGP announcements can still be filtered by the BGP routers, despite the fact that the relying party is stalled.
Based on code analysis of the relying party implementations we developed a method to prevent the relying parties from downloading the RPKI objects, causing the cached objects to become stale. To do that we use low-rate attacks, exploiting the rate limiting in DNS and RPKI components.
We developed methodologies to overcome the hurdles of predicting when the relying parties initiate the refresh of the RPKI objects, and to target only specific victim relying parties.
We demonstrated how a combination of these methods in tandem with stalling attacks via long delegation chains, enable adversaries to disable RPKI validation, exposing the RPKI supporting networks to BGP prefix hijack attacks.
Conclusions
During our evaluations in the first half of 2021 we found all the relying party implementations to be vulnerable to our Stalloris RPKI downgrade attack.
In the meantime, the problems were fixed. Nevertheless, more work is required to enhance the resilience of RPKI, particularly in light of the complex dependencies between the different components and protocols in the Internet. Our work highlights how the vulnerabilities in different components can adversely affect the security guarantees of RPKI.
This article is based on a research paper Stalloris: RPKI Downgrade Attack, by Tomas Hlavacek, Philipp Jeitner, Donika Mirdita, Haya Shulman, and Michael Waidner that was accepted for publication at USENIX Security 2022.
This research will also be presented at BlackHat USA 2022.
Dr. Haya Shulman is Professor for computer science at Goethe-Universität Frankfurt, department director at the Fraunhofer-Institute for Secure Information Technology SIT and a head of the research area Analytics-based Cybersecurity in the national research centre ATHENE.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
The paper states “Eliminating manifests and using the actual validity of the ROAs could make it more difficult to launch the attack since the adversary would need to wait longer for RPKI objects to expire.”
From this sentence it appears the researchers misunderstood the purpose of Manifests. The CAs control the validity windows, anyone is free to use wider validity windows.
More importantly, Manifests have an important utility as described here https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents/
Manifests make it possible to detect replay attacks, and unauthorized in-flight modification or deletion of signed objects.
CRLs are not a substitute for Manifests. Both CRLs and Manifests offer distinct unique features, both are critical to the functioning of the RPKI technology stack.
Recommending elimination of Manifests is bad advice.
Very cool attack and a devastating one too! Good that the implementations were updated.
It is a phony certificate and DNS spoofing/redirects, variations on a theme. Attack methods hackers have used for years on a large scale, AS instead of local networks.