The vast majority of computer security incidents involve some sort of phishing or malware. Typically, this is the type of incident that receives the most attention from organizations, and for which security controls are established. And rightfully so — malware that exploits a vulnerability or human error can cause significant damage to an organization.
However, attacks targeting an organization’s network or internet infrastructure components — such as Border Gateway Protocol (BGP) — have been generally overlooked, even as they gain traction. BGP hijack attacks are still far less common than distributed denial-of-service (DDoS) attacks, but several recent events have turned this unusual method into headlines.
What Is BGP?
Some consider BGP the glue that ties the internet together. Purists might argue that it is the Domain Name System (DNS) that plays this role, given that there can be glue records in a zone file. However, without BGP, your packets would not arrive at their intended destinations.
BGP is the routing protocol of the internet. It is used to determine the most efficient way to route data between independently operated networks, known as autonomous systems (AS). In technical terms, an AS is a collection of IP prefixes that are assigned an Autonomous System Number (ASN).
Put simply, BGP is the road map to the internet, whereas DNS is the phone book.
How BGP Routing Works
A BGP router uses a large table called the routing information base (RIB), which describes the networks it can reach and what the most efficient paths to these networks are. BGP peers are systems (or neighbors) from which the router receives information (networks or prefixes). These are configured manually.
Basically, BGP peers tell the router that it should process or include the information received by other manually entered peers. By combing the information coming from different peers, the router can then work out the most efficient path to a destination.
What Is BGP Hijacking?
In short, a BGP attack is a configuration of an edge router to announce prefixes that have not been legitimately assigned to it. If the injected announcement is more specific (meaning more efficient) than the legitimate one, then the traffic will be rerouted to the injected announcement. In this way, an attacker can broadcast false prefix announcements, polluting the routing table of all its connected peers.
Because of the propagation of routes through connected networks, if one peer includes the malicious information in its routing table, this information can be quickly propagated to other peers. Routing announcements are accepted almost without any validation, making a successful BGP hijack relatively easy.
There are two primary types of attacks: A complete hijack attack overtakes a specific IP prefix, whereas in a partial hijack, the attacker competes with the legitimate source by announcing the same prefix with the same efficiency.
There are also unintentional cases. Human error can cause the same effect as a BGP hijack attack. This is often referred to as a route leak.
Recognize the Impact
The most obvious impact of BGP hijacking is that packets do not take their most optimal route, slowing down users’ connections to the network.
Far worse, attackers can black hole an entire network, including the organization’s services, thus resulting in an outage resembling a DDoS attack. Similarly, attackers can censor certain sources of information by black holing specific networks.
The rerouting makes the attacker a middleman of the network flow — meaning he or she can eavesdrop on certain parts of the communication, or in some cases even alter the traffic. They can also redirect traffic from your customers or users to malicious sites pretending to be part of your network. This can result in the theft of information or credentials or delivery of malware that exploits weaknesses.
In addition, spammers can abuse the good reputation of your ASN to conduct spam runs. This can have a negative effect on your network if it gets blocked by spam filters.
Watch for a Secondary Attack
In some cases, the BGP hijack might not be the attacker’s final objective. The goal might be to steal credentials or divert your users to sources that could potentially exploit their systems.
During the incident response phase, it’s important to be aware of this possibility and try to gather as much material as possible that could help you analyze these attacks. Valuable data sources include passive DNS, Secure Sockets Layer (SSL) certificate history and full packet captures.
How to Detect a BGP Hijack
One of the problems with BGP attacks is that they do not always last very long, so by the time you know an attack is taking place, the situation can already be restored to normal. This stresses the importance of implementing monitoring tools and establishing an efficient alerting workflow.
Start by monitoring the BGP routes that relate to your AS. You can set up your own monitoring solutions, but you can just as well rely on publicly available sources, such as BGPMon and Oracle Dyn, to do the heavy lifting for you.
Build an Incident Response Plan
Proper reaction to a BGP hijack starts with an incident response plan. Unfortunately, this isn’t the type of incident for which you can set up a simple fallback solution or defensive security control. Nor is it one that you can easily detect.
That’s because BGP attacks take place outside the network of an organization. A well-conducted BGP hijack can intervene with traffic without your users ever noticing something was wrong. You might be able to convince your ISP to remove the false route or request it to convince its peers to drop these announcements.
For BGP hijack attacks, the containment, eradication and recovery phases of an incident response plan glue together. Because the route announcements will spread very quickly, containment might be a real challenge.
If you can’t free up the resources to develop a dedicated incident response plan, then you can reuse parts of your plan for combating DDoS attacks.
Be Prepared
Most organizations do not have their own ASN and must rely on the measures of their upstream internet service provider (ISP). But there are ways to prepare:
- Understand which network providers your organization uses. Does it rely on one single network provider or multiple? An AS relation model can give you insight on this.
- Once you have listed your network providers, reach out and ask them what precautions or response plans they have with regard to BGP security. You could start by asking for a high-level overview of the peering policy and what agreements toward protection they have in place.
- Build good working communication channels with your network providers. Next to the normal abuse contact, these should also include escalation paths.
- Establish out-of-band communication channels via another network provider. Use these channels to inform your customers in case of an attack. Possible options would be social media or a communication page hosted at a cloud provider (take into account phishing).
If you own an ASN, there are some additional measures to take:
- Write down your peering policy and make sure everyone understands the BGP interconnection policy.
- Implement the BGP-peering BCPs.
- Review and implement the best practices from Mutually Agreed Norms for Routing Security (MANRS).
- Specify an AS path. Be aware that this can quickly backfire since the intent of the system is to find the best path automatically. Introducing manual paths will weaken the system.
- Limit the amount of prefixes that can be received to prevent being flooded with announcements.
- Implement route filtering.
- Filter bogons, the IP prefixes that should not be allowed on the internet.
- Use a form of authentication before accepting announcements.
- Implement BGP time to live (TTL) checks, rejecting updates from routers located further away from you.
If you want to exercise your plan, you can, for example, make use of a virtual machine (VM) with the option to load +500k BGP routes.
Consider Automated Response Tools
A key element in fighting BGP hijacking is accurate and fast detection that enables flexible and equally fast mitigation of these events. This is where the Automatic and Real-Time dEtection and MItigation System (ARTEMIS) can provide future help.
ARTEMIS, presented in a research paper by the Center for Applied Internet Data Analysis (CAIDA), is a self-operated and unified detection and mitigation approach based on control-plane monitoring. Although still in development, the project shows potential to help network providers address these attacks.
The last phase in incident response — learning lessons — calls for collecting the necessary information to update and improve your plan, especially for the preparation and detection phases. Review whether all the communication channels worked as expected, the escalation paths gave the expected results and you were able to detect the attack in time. The best response plan is prevention.