Skill v1.0.1
currentAutomated scan+4 new
name: exploiting-bgp-hijacking-vulnerabilities description: 'Analyzes and simulates BGP hijacking scenarios in authorized lab environments to assess route origin validation, RPKI deployment, and BGP monitoring defenses against prefix hijacking and route leak attacks on internet routing infrastructure.
' domain: cybersecurity subdomain: network-security tags:
- network-security
- bgp
- routing-security
- rpki
- route-hijacking
version: '1.0' author: mahipal license: Apache-2.0 nist_csf:
- PR.IR-01
- DE.CM-01
- ID.AM-03
- PR.DS-02
mitre_attack:
- T1046
- T1040
- T1557
- T1071
Exploiting BGP Hijacking Vulnerabilities
When to Use
- Assessing an organization's exposure to BGP prefix hijacking and route leak attacks
- Testing RPKI (Resource Public Key Infrastructure) deployment and route origin validation effectiveness
- Validating BGP monitoring and alerting systems detect unauthorized route announcements
- Simulating BGP hijacking in isolated lab environments to train network operations teams
- Evaluating ISP prefix filtering and route origin authorization (ROA) configurations
Do not use to perform actual BGP hijacking on the live internet, against BGP peers without authorization, or to disrupt real internet routing infrastructure. BGP attacks on production systems are illegal and can cause widespread internet outages.
Prerequisites
- Isolated BGP lab environment using GNS3, EVE-NG, or Containerlab with virtual routers (FRRouting, BIRD, or Cisco IOS)
- Understanding of BGP path attributes, AS path, prefix announcements, and route selection
- Access to BGP looking glass servers and RPKI validators for monitoring real-world route status
- bgpstream, RIPEstat, and BGPalerter tools for route monitoring
- Written authorization for any testing that involves real AS numbers or prefix announcements
Workflow
Step 1: Build an Isolated BGP Lab Environment
# Install Containerlab for BGP simulationsudo bash -c "$(curl -sL https://get.containerlab.dev)"# Create a BGP lab topology filecat > bgp-lab.clab.yml << 'EOF'name: bgp-hijack-labtopology:nodes:# Legitimate AS (AS65001) announcing 10.0.0.0/24legitimate-router:kind: linuximage: frrouting/frr:v8.5.0binds:- legitimate-frr.conf:/etc/frr/frr.conf# Attacker AS (AS65002) that will hijack the prefixattacker-router:kind: linuximage: frrouting/frr:v8.5.0binds:- attacker-frr.conf:/etc/frr/frr.conf# Transit provider (AS65000) connecting bothtransit-router:kind: linuximage: frrouting/frr:v8.5.0binds:- transit-frr.conf:/etc/frr/frr.conf# Victim network receiving routesvictim-router:kind: linuximage: frrouting/frr:v8.5.0binds:- victim-frr.conf:/etc/frr/frr.conflinks:- endpoints: ["legitimate-router:eth1", "transit-router:eth1"]- endpoints: ["attacker-router:eth1", "transit-router:eth2"]- endpoints: ["transit-router:eth3", "victim-router:eth1"]EOF# Configure legitimate router (AS65001)cat > legitimate-frr.conf << 'EOF'frr defaults traditionalhostname legitimate-routerrouter bgp 65001bgp router-id 1.1.1.1neighbor 10.0.1.2 remote-as 65000address-family ipv4 unicastnetwork 10.0.0.0/24neighbor 10.0.1.2 activateexit-address-family!interface eth1ip address 10.0.1.1/30!interface loip address 10.0.0.1/24EOF# Configure attacker router (AS65002) -- initially not announcing the prefixcat > attacker-frr.conf << 'EOF'frr defaults traditionalhostname attacker-routerrouter bgp 65002bgp router-id 2.2.2.2neighbor 10.0.2.2 remote-as 65000address-family ipv4 unicastneighbor 10.0.2.2 activateexit-address-family!interface eth1ip address 10.0.2.1/30EOF# Deploy the labsudo containerlab deploy -t bgp-lab.clab.yml
Step 2: Verify Legitimate BGP Routing
# Connect to victim router and verify route to 10.0.0.0/24docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp"docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.0/24"# Expected: Route via AS65000 AS65001 (legitimate path)# Verify traceroute follows the legitimate pathdocker exec -it clab-bgp-hijack-lab-victim-router traceroute 10.0.0.1# Check BGP table on transit routerdocker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"
Step 3: Simulate Prefix Hijack (More-Specific Route)
# On the attacker router, announce more-specific prefixesdocker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'configure terminalrouter bgp 65002address-family ipv4 unicastnetwork 10.0.0.0/25network 10.0.0.128/25exit-address-family!interface loip address 10.0.0.1/25ip address 10.0.0.129/25exitendwrite memoryVTYSH# Verify the hijack on the victim routerdocker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24 longer-prefixes"# The victim should now prefer the /25 routes via the attacker# because more-specific routes always win in IP routingdocker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.1"# Expected: Route now via AS65000 AS65002 (attacker)
Step 4: Simulate AS Path Prepend and Origin Hijack
# Origin hijack: Attacker announces the exact /24 prefixdocker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'configure terminalrouter bgp 65002address-family ipv4 unicastnetwork 10.0.0.0/24no network 10.0.0.0/25no network 10.0.0.128/25exit-address-familyendwrite memoryVTYSH# Check which route the victim prefers# With equal prefix length, shortest AS path winsdocker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24"# Both routes visible, attacker may win based on AS path length# Analyze how BGP path selection determines the winnerdocker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24 bestpath-compare"
Step 5: Test RPKI Route Origin Validation
# Set up RPKI validator (Routinator)docker run -d --name routinator \-p 3323:3323 -p 8323:8323 \nlnetlabs/routinator:latest# Configure transit router to use RPKI validationdocker exec -it clab-bgp-hijack-lab-transit-router vtysh << 'VTYSH'configure terminalrpkirpki cache 172.17.0.1 3323 preference 1exit!route-map RPKI-FILTER permit 10match rpki valid!route-map RPKI-FILTER deny 20match rpki invalid!route-map RPKI-FILTER permit 30match rpki notfound!router bgp 65000address-family ipv4 unicastneighbor 10.0.2.1 route-map RPKI-FILTER inexit-address-familyendwrite memoryVTYSH# Verify RPKI statusdocker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show rpki prefix-table"docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"# Attacker's announcement should be marked as RPKI Invalid if ROA exists
Step 6: Monitor and Detect BGP Anomalies
# Install BGPalerter for real-time monitoringnpm install -g bgpalerterbgpalerter generate -o /etc/bgpalerter# Configure BGPalerter to monitor your prefixescat > /etc/bgpalerter/prefixes.yml << 'EOF'10.0.0.0/24:description: Production Networkasn: 65001ignoreMorespecifics: falsegroup: productionEOF# Start monitoringbgpalerter# Use bgpstream to query historical routing datapip3 install pybgpstreampython3 << 'PYEOF'import pybgpstream# Query for historical prefix announcementsstream = pybgpstream.BGPStream(from_time="2024-03-14 00:00:00",until_time="2024-03-15 00:00:00",collectors=["route-views2", "rrc00"],record_type="updates",filter="prefix more 10.0.0.0/24")for rec in stream.records():for elem in rec:if elem.type == "A": # Announcementprint(f"Time: {elem.time}")print(f"Prefix: {elem.fields['prefix']}")print(f"AS Path: {elem.fields['as-path']}")print(f"Peer: {elem.peer_asn}")print("---")PYEOF# Check RPKI status via RIPEstatcurl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS65001&prefix=10.0.0.0/24" | python3 -m json.tool
Key Concepts
| Term | Definition | |
|---|---|---|
| BGP Hijacking | Unauthorized announcement of IP prefixes by an AS that does not own them, diverting traffic through the attacker's network | |
| More-Specific Hijack | Announcing longer (more-specific) prefixes than the victim's, which always win in IP routing due to longest-prefix-match rule | |
| RPKI (Resource PKI) | Cryptographic framework that allows IP prefix holders to authorize specific ASNs to originate their routes via Route Origin Authorizations (ROAs) | |
| Route Origin Authorization (ROA) | Digitally signed object that authorizes an AS to originate a specific IP prefix, enabling RPKI-based route validation | |
| AS Path Prepending | BGP technique of adding duplicate AS numbers to the AS path to make a route less preferred, also used defensively against hijacking | |
| Route Leak | Propagation of BGP routing announcements beyond their intended scope, such as a customer re-advertising transit provider routes to other providers |
Tools & Systems
- Containerlab: Network lab orchestration tool for deploying virtual router topologies using Docker containers
- FRRouting (FRR): Open-source routing suite supporting BGP, OSPF, IS-IS with RPKI validation capabilities
- BGPalerter: Real-time BGP monitoring tool that detects prefix hijacking, route leaks, and RPKI status changes
- Routinator: RPKI Relying Party software that validates ROAs and provides validated prefix-origin data to routers
- pybgpstream: Python library for analyzing historical and real-time BGP data from RouteViews and RIPE RIS collectors
Common Scenarios
Scenario: Assessing an Organization's BGP Hijacking Resilience
Context: A cloud hosting company (AS12345) announces 203.0.113.0/24 for their customer-facing services. They need to assess their resilience to BGP hijacking attacks and verify their RPKI deployment is effective. The assessment includes lab simulation and real-world monitoring validation.
Approach:
- Build a Containerlab topology replicating the organization's BGP peering with two upstream ISPs
- Verify that ROA records are correctly published for all the organization's prefixes using RIPEstat
- Simulate a more-specific prefix hijack (/25) from a rogue AS and verify that upstream ISPs with RPKI validation drop the invalid routes
- Simulate an exact-match origin hijack and verify that RPKI ROV marks the route as invalid
- Test route leak scenarios where a customer AS re-announces the provider's prefix
- Deploy BGPalerter in production to continuously monitor for unauthorized announcements
- Verify that the organization's ISPs have proper prefix filtering (IRR-based and RPKI) configured
Pitfalls:
- Testing BGP hijacking on real internet infrastructure instead of isolated lab environments
- Assuming RPKI alone prevents all hijacking -- many networks still do not validate RPKI
- Not testing more-specific prefix announcements, which bypass origin validation if no max-length is set in ROAs
- Overlooking route leak scenarios where authorized peers inadvertently redistribute routes
Output Format
## BGP Security Assessment Report**Organization**: Cloud Hosting Co. (AS12345)**Prefixes Assessed**: 203.0.113.0/24, 198.51.100.0/24**Assessment Date**: 2024-03-15### RPKI Status| Prefix | ROA Exists | Max Length | Origin AS | Status ||--------|-----------|------------|-----------|--------|| 203.0.113.0/24 | Yes | /24 | AS12345 | Valid || 198.51.100.0/24 | No | N/A | AS12345 | Not Found |### Lab Simulation Results| Attack Type | RPKI Validation | Result ||-------------|-----------------|--------|| More-specific /25 hijack | Enabled | BLOCKED (Invalid origin) || More-specific /25 hijack | Disabled | SUCCESSFUL (traffic diverted) || Exact-match origin hijack | Enabled | BLOCKED (Invalid origin) || Route leak via customer | Enabled | NOT BLOCKED (valid origin, wrong path) |### Recommendations1. Create ROA for 198.51.100.0/24 (currently unprotected)2. Set max-length to /24 in ROAs to prevent more-specific hijacks3. Request upstream ISPs enable RPKI Route Origin Validation4. Deploy BGPalerter for continuous prefix monitoring5. Register with IRR databases and request prefix filtering from peers