Метка: BGP MiTM

It should be noted that this attack requires that the attacker has access to the traffic path of the respective packets. The setup for this example looks like this:

The attacker is in a Man-in-the-Middle situation inside the data path between Provider Edge 1 and Provider Edge 2 in the MPLS backbone.

On PE1 the label association for the both MPLS-VPNs looks like this:

Which means outgoing traffic for customer RED’s location 2 is tagged with the MPLS label 18. In the other direction, traffic tagged with MPLS label 20 is sent out to customers RED’s location 1. The same for customer GREEN, outgoing traffic for location 2 is tagged with label 19, incoming traffic with label 21 is sent out to location 1. Both customers use the same IP address space for the two locations, which is possible, as we got a logical separation in the routing of each customer.

Let’s further assume we got a client with the IP address 192.168.113.100 connected to customer GREEN’s location 2. So it’s possible to ping this client from PE1 in the context of customer GREEN. We need to specify the virtual routing and forwarding context of customer GREEN to use the customer’s specific routing table. If we run the same command in the context of customer RED, no response will be visible:

Next the attacker starts to redirect traffic from PE1 to PE2 in the backbone from customer RED’s MPLSVPN to customer GREEN’s MPLS-VPN and redirect traffic from PE2 to PE1 in the backbone from customer GREEN’s MPLS-VPN to customer RED’s MPLS-VPN by loki like this:

Once the redirection is in place it is possible to ping our assumed host from both, customer RED’s and customer GREEN’s context:

So this actually means that with right position in the traffic path and the right tool (e.g. Loki) an attacker can easily redirect a given site’s traffic of a given customer to a different destination (provided the IP addresses are the same which presumably is a valid assumption when it comes to addresses like 10.1.1.1 or 192.168.10.1).