Skip to main content

Attacking MPLS VPNs

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
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 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:

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 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:

Redirecting MPLS-VPN Traffic with Loki
Once the redirection is in place it is possible to ping our 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).

Popular posts from this blog

Attacking BGP routers for BitCoin hijacking

A few days ago researchers at Dell SecureWorks published the details of an attacker repeatedly hijacking BGP prefixes for numerous large providers such as Amazon, OVH, Digital Ocean, LeaseWeb, Alibaba and more. The goal of the operation was to intercept data between Bitcoin miners and Bitcoin mining pools. They estimated that $83,000 was made with this attack in just four months. Let's take a closer look at  the BGP details of this specific attack.

BGP Attack details Our friends at Dell SecureWorks decided not to name the network from which the hijacks originated. As a result we won’t name the exact Autonomous System either, instead we will suffice by saying that the originator of this hijack is a network operating in Eastern Canada.



Initial experiment
BGPmon detected the first BGP attack by this Canadian Autonomous System on October 8th 2013. For about 14 minutes a more specific /24 IP prefix for a Palestinian network was hijacked. Looking at geographical scope of the announcements a…

Виртуальная сеть на базе Cisco CSR 1000V

Во время обучения, для того чтобы лучше разобраться как работает та или иная технология я пользовался и программой моделирования сетей DYNAGEN, и удаленным доступом к стенду с реальным оборудованием, любезно предоставленным нам организаторами обучения. Это, конечно же очень помогало, но меня все время не оставляла мысль найти какой-то вариант, который позволил бы иметь ощущение реальности при работе с устройством и в тоже время чтобы я мог его крутить так как мне захочется и в любое время, когда мне захочется. Я пробовал и GNS3, и IOU, при этом продолжая поиски. Так я узнал о таком продукте от CISCO как CSR 1000V Cloud Services Routerhttp://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html , скачать который можно в нашей подборке Cisco IOS. Небольшие выдержки из документации:
«Развернутый на виртуальной машине Cisco CSR 1000V с IOS XE обеспечивает точно такую же функциональность, как если бы IOS XE работала на традиционной аппаратной платформе Cis…

Проникновение в сеть оператора связи

Перво наперво стоит провести анализ идущего мимо сетевого трафика с помощью любого сетевого анализатора в "неразборчивом" режиме работы сетевой карты (promiscuous mode). В качестве сетевого анализатора для подобных целей замечательно подходит Wireshark или CommView. Чтобы выполнить этот этап, хватит и пары часов работы сетевого анализатора. По прошествии этого времени накопится достаточно данных для проведения анализа перехваченного трафика. И в первую очередь при его анализе следует обратить внимание на следующие протоколы: протоколы коммутации (STP, PVST+, CDP, DTP, VTP, и им подобные)протоколы маршрутизации (RIP, BGP, EIGRP, OSPF, IS-IS и другие)протоколы динамической конфигурации узла (DHCP, BOOTP)открытые протоколы (telnet, rlogin и подобные) Что касается открытых протоколов, – вероятность того, что они попадутся во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаютс…