Exploiting Bgp Hijacking Vulnerabilities

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.

Most Often Missed & How to Confirm

• Route leak vs. origin hijack (most-missed): a leak keeps the correct origin AS (RPKI-Valid) but propagates the prefix over a wrong, longer path — ROV does not block it. Don't report "RPKI protects us" after only testing exact-origin hijacks; explicitly test a customer re-advertising a provider prefix.
• More-specific under a loose ROA: if a ROA's max-length is /25 or unset, the attacker's 10.0.0.0/25 validates Valid and wins by longest-prefix-match even with RPKI on. Confirm the ROA max-length before concluding a prefix is safe.
• NotFound ≠ protected: prefixes with no ROA validate as NotFound and are accepted by every ROV policy. Absence of an Invalid is not evidence of protection.

Concrete positive signal: in FRR, show ip bgp 10.0.0.0/24 on the victim shows bestpath via the attacker AS (e.g. 65000 65002) and show ip route 10.0.0.1 resolves through the attacker link — a confirmed hijack. Don't conclude "not vulnerable" until you've tested (1) exact-origin hijack, (2) a more-specific beyond ROA max-length, and (3) a route-leak path that keeps the legitimate origin.

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 simulation
sudo bash -c "$(curl -sL https://get.containerlab.dev)"

# Create a BGP lab topology file
cat > bgp-lab.clab.yml << 'EOF'
name: bgp-hijack-lab
topology:
  nodes:
    # Legitimate AS (AS65001) announcing 10.0.0.0/24
    legitimate-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - legitimate-frr.conf:/etc/frr/frr.conf
    # Attacker AS (AS65002) that will hijack the prefix
    attacker-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - attacker-frr.conf:/etc/frr/frr.conf
    # Transit provider (AS65000) connecting both
    transit-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - transit-frr.conf:/etc/frr/frr.conf
    # Victim network receiving routes
    victim-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - victim-frr.conf:/etc/frr/frr.conf
  links:
    - 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 traditional
hostname legitimate-router
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 10.0.1.2 remote-as 65000
 address-family ipv4 unicast
  network 10.0.0.0/24
  neighbor 10.0.1.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.1.1/30
!
interface lo
 ip address 10.0.0.1/24
EOF

# Configure attacker router (AS65002) -- initially not announcing the prefix
cat > attacker-frr.conf << 'EOF'
frr defaults traditional
hostname attacker-router
router bgp 65002
 bgp router-id 2.2.2.2
 neighbor 10.0.2.2 remote-as 65000
 address-family ipv4 unicast
  neighbor 10.0.2.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.2.1/30
EOF

# Deploy the lab
sudo 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/24
docker 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 path
docker exec -it clab-bgp-hijack-lab-victim-router traceroute 10.0.0.1

# Check BGP table on transit router
docker 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 prefixes
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/25
  network 10.0.0.128/25
 exit-address-family
!
interface lo
 ip address 10.0.0.1/25
 ip address 10.0.0.129/25
exit
end
write memory
VTYSH

# Verify the hijack on the victim router
docker 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 routing
docker 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 prefix
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/24
  no network 10.0.0.0/25
  no network 10.0.0.128/25
 exit-address-family
end
write memory
VTYSH

# Check which route the victim prefers
# With equal prefix length, shortest AS path wins
docker 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 winner
docker 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 validation
docker exec -it clab-bgp-hijack-lab-transit-router vtysh << 'VTYSH'
configure terminal
rpki
 rpki cache 172.17.0.1 3323 preference 1
exit
!
route-map RPKI-FILTER permit 10
 match rpki valid
!
route-map RPKI-FILTER deny 20
 match rpki invalid
!
route-map RPKI-FILTER permit 30
 match rpki notfound
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 10.0.2.1 route-map RPKI-FILTER in
 exit-address-family
end
write memory
VTYSH

# Verify RPKI status
docker 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 monitoring
npm install -g bgpalerter
bgpalerter generate -o /etc/bgpalerter

# Configure BGPalerter to monitor your prefixes
cat > /etc/bgpalerter/prefixes.yml << 'EOF'
10.0.0.0/24:
  description: Production Network
  asn: 65001
  ignoreMorespecifics: false
  group: production
EOF

# Start monitoring
bgpalerter

# Use bgpstream to query historical routing data
pip3 install pybgpstream

python3 << 'PYEOF'
import pybgpstream

# Query for historical prefix announcements
stream = 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":  # Announcement
            print(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 RIPEstat
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS65001&prefix=10.0.0.0/24" | python3 -m json.tool

Key Concepts

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:

1. Build a Containerlab topology replicating the organization's BGP peering with two upstream ISPs
2. Verify that ROA records are correctly published for all the organization's prefixes using RIPEstat
3. Simulate a more-specific prefix hijack (/25) from a rogue AS and verify that upstream ISPs with RPKI validation drop the invalid routes
4. Simulate an exact-match origin hijack and verify that RPKI ROV marks the route as invalid
5. Test route leak scenarios where a customer AS re-announces the provider's prefix
6. Deploy BGPalerter in production to continuously monitor for unauthorized announcements
7. 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) |

### Recommendations
1. Create ROA for 198.51.100.0/24 (currently unprotected)
2. Set max-length to /24 in ROAs to prevent more-specific hijacks
3. Request upstream ISPs enable RPKI Route Origin Validation
4. Deploy BGPalerter for continuous prefix monitoring
5. Register with IRR databases and request prefix filtering from peers