Crashing the Party: Securing the Border Gateway Protocol
In this article, I'll give you some insights into a research project that I did with a student colleague of mine in my final semester of my master's degree.
Introduction and Motivation
The internet is comprised of multiple networks, so-called 'autonomous systems' (AS). In order for inter-AS communication, routers need information where to route specific packets. This information is exchanged using BGP1. The specification itself lacks of robust security measures to prevent the publication of bogus BGP information. So either by accident2 or intentional, it is possible to hijack BGP routes illegitimately.
Luckily, there is a solution to all of this, namely the Resource Public Key Infrastructure (RPKI)3. This way, routing information can be checked for authenticity and authorization. RPKI relies on so-called relying parties (RP) to do that. These relying parties periodically synchronize the BGP announcements from RPKI repositories and then use digital signatures to verify whether or not an AS is authorized to claim a particular IP address range.
If someone were able to lead a RP to crash, it could have serious consequences for the stability and security of the internet’s routing infrastructure. For example, a crashed RP might lead to BGP hijacks. This could result in traffic being misdirected, networks being discon- nected, and potentially even security breaches or data theft.
What's all the fuzz about?!
In order to check whether the implementation of these RPs was robust, we tested it with various inputs using libfuzzer. In our case, we tested the FORT Validator (v. 1.5.3), which was implemented in C4. I won't get into detail about installing FORT. We used fuzzing, which is a type of software testing that attempts to cause a program to crash or behave improp- erly with unexpected input. To generate different input data and then to pass it to the program, a so-called fuzzing engine is used. Since the FORT Validator was written in C, the fuzzing engine "libFuzzer" developed by Google is used in the following.
We discovered a DoS vector by a vulnerability regarding memory allocation issues. The is rooted in misconfigured packet sizes in the RTR component of the server, i.e. the server that interacts with connected BGP routers to exchange validated RPKI information. An attacker sending the payload to the RTR server of Fort can crash the RP application by sending a message larger than the expected Protocol Data Unit (PDU) slot. The result is a memory corruption that leads to a full application crash, effectively disabling RPKI validation.
Further Reading
Our results were published in a paper5 with even more RPKI implementations that were tested. If you're interested, I strongly recommend reading the article as well as the paper. There was also an article6 being published as well as a presentation at the black hat conference7
Being the millenial kid that I am, I can recommend a YouTube video about this topic with some high-level insights:
Big shoutout to Haya Schulmann, Niklas Vogel, Donika Mirdita and their team from ATHENE who held the course in my master's degree. Their work makes the internet a more secure place, and it needs more recognition!