Метка: traffic engineering

  • Relabeling MPLS VPN’s traffic on the wire

    Relabeling MPLS VPN’s traffic on the wire

    Loki’s MPLS module is designed to relabel specified MPLS traffic with a given label. It can be used to manipulate the transport label and change the destination of the packet, or to redirect traffic into another MPLS-VPN. The module automatically detects all MPLS labeled traffic on the wire and let the user easily set up relabeling rules. It is possible to add a tcpdump filter to the relabeling rule, if the module should only redirect some special kind of traffic. Last but not least one can define which label in the label stack should be modified.

    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:

    Bi-Directional MPLS-VPN

    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:

    Cisco 3750 Label Overview

    Console: Cisco 3750 Label Overview

    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 I got a logical separation in the routing of each customer.

    Let’s further assume I 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. I need to specify the virtual routing and forwarding context of customer GREEN to use the customer’s specific routing table. If I run the same command in the context of customer RED, no response will be visible:

    Cisco 3750 test of MPLS-VPN Connection

    Next the attacker starts to redirect traffic from PE1 to PE2 in the backbone from customer RED’s MPLS-VPN 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:

    Redirecting MPLS-VPN Traffic with Loki

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

    Cisco 3750 Test of MPLS-VPN Connection after using Loki

    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).

  • Protecting your Juniper router from PSN-2010-01-623 using firewall filters

    Last Thursday Juniper Networks released advisory PSN-2010-01-623 urging Network administrator running JUNOS versions older then one year to upgrade. The advisory states that by sending ‘malformed’ tcp options will cause JunOS to crash. The advisory does not mention which tcp options will cause this behavior.

    So last Friday and Saturday I spend a few hours to trying to generate TCP packets with different kind of options set, trying to see if I could find out the exact options needed. However before I found the magic combination, Jermey Gaddis posted a blog post describing which options need to be set. He also published an exploit.

    I tried running this exploit, but for some reason the perl code does not run on my Mac book. After slightly rewriting some of his perl code I managed to get it working and was ready to give it a try on one of our lab routers, a M10 running JunOS 7.x.

    I was able to crash the router with only sending one packets, also see the video.

    Of course most routers have firewall/acl filters to only allow traffic to the RE from trusted sources. According to the advisory and some resources online firewall filters don’t help in this case. However in my lab testing applying a firewall did seem to help.

    To test this I configured my lab router with a firewall blocking all ssh traffic from all sources. I tried the exploit again and nothing happened. So it seems that at least in some cases a firewall filter does help. This might be different on a Olive box, as it doesn’t have hardware filtering in PFE’s. I assume that’s why filtering does work on a ‘real’ box, as it’s probably filtered out by the PFE’s before it reached the kernel.

    Although firewall filters do seem to protect you against this issue. It’s still fairly easy to spoof IP addresses and bypass the firewall. As router IP addresses are easy to find (traceroute) it will also be easy to guess the IP address of a BGP peer. Using that spoofed address will allow an attacker to crash your router. So, upgrading to a more recent release is the only real solution.