Looking and Peering - Attacking from beyond BGP Adjacency

The talk starts from a common assumption: a BGP router only accepts updates from configured peers, and GTSM's TTL check confirms that the peer is one hop away. The speaker argues that this adjacency boundary is the weak point, since most hardening work such as RPKI and BGPsec focuses on route validation. The question is whether an attacker without a peering session can get inside that boundary.

The attack path has three stages. First, looking glass web tools that pass user input into a router shell can give command execution on an edge router, and the speaker reports that several such tools are still vulnerable. Second, tunnel injection through a misconfigured VPN endpoint lets an off-path attacker appear adjacent to a target, and a use-after-free in FRR's attribute caching leads to remote code execution. Third, differences between FRR, BIRD and other daemons are abused: oversized or malformed optional attributes, and mismatched prefix limits, make one implementation re-emit or reject updates in a way that causes repeated session resets in another. A recorded demo shows a victim session dropping after the chain runs.

The speaker estimates exposure from PeeringDB data, counting roughly 300 networks running vulnerable looking glass software. The reach is still small compared with the total number of networks, and large default-free routers complicate any wide outage. The practical takeaways are to treat looking glasses as privileged systems, validate attribute lengths strictly, and avoid assuming that a peer list alone protects a router.