Skip to main content

Attacks From Within the Carrier or Cloud Service

Relabeling Attack

Loki can be used to relabel 802.1Q tagged packets on the fly. Once an attacker is in the traffic path all seen 802.1Q communications are listed in the dot1q module. To rewrite a label in transmission between two hosts, it simply needs to be selected to fill in most of the fields for the rewrite rule. Only the target label and an optional tcpdump filter to match specific data streams need to be added. Once the rule is added a background thread takes care of the relabeling.

Relabeling attack with Loki on L3VPN MPLS



Modifying Q-in-Q on MPLS Network

The dot1q module in Loki can also be used to rewrite the inner 802.1Q label used in Q-in-Q scenarios in the same way as when rewriting the outer 802.1Q label.

Modifying Q-in-Q with Loki on MPLS Network

Network Behaviour with Security Impact, Resulting from Unified Layer2 Network

If several sites form a common Layer2 domain after connecting them (mainly in “full transparency” cases), some interesting settings – with potentially huge security impact – can emerge. For example there might only be one Spanning Tree Root in the whole (then world wide) L2 network (or one per VLAN). Combined with the fact that some sites may even implement redundant links to the carrier network the following scenario might follow:

MPLS Network sample

Here the network traffic resulting from Bob’s access to the fileserver with actually be forwarded to New York and back to Amsterdam (as the link between the switches in Amsterdam is in blocking state), effectively passing the MPLS backbone (possibly unencrypted). Moreover Bob (or the site’s or the company’s security officer) might be completely unaware of this situation.

Another example of (at the first glance) “unexpected” network behaviour is shown in the following diagram:

L3VPN on MPLS Network
With a fully transparent Intra-Site Ethernet connection the switch in New York will propagate it’s VLAN table to the switches in Amsterdam effectively melting down the complete network over there.

Full transparency with regard to VLANs might impose another risk, shown in the following diagram: “VLAN visibility across the cloud”:

VLAN visibility across the cloud


Members of VLAN 10 in Paris (“wlan”) might be able to communicate with members of VLAN 10 in Amsterdam (“servers”)8, without notice or awareness of the sysadmins in Amsterdam. This is another example of the effects a fully transparent connection may have.

Traditional Layer2 Attacks from One Site to Another

It should be explicitly noted that – in a such a “unified Layer2 network” – the impact of a system compromise in one site may lead to Layer2 attacks against other sites (e.g. attacks against DTP with subsequent sniffing of remote VLANs with yersinia). Previously such attacks mostly probably were not possible.

Misconfigurations on the Carrier Side, leading to Security Breaches of/within Customer Network

If, for instance, the carrier is expected to provide “partial transparency” but actually “full transparency” is implemented (due to operational deficiencies and/or human error), security problems (like those depicted above) may arise.

Another example (which in fact happens) is the accidental connection of sites belonging to different customers or leakage of routing information due to typos in the VRF/VFI identifiers.

Misconfigurations on the Customer Side, leading to Breaches

In “full transparency” scenarios diligent configuration of the customer’s network devices might be necessary to avoid security problems as discussed above. Bad operational practice or human errors may easily lead to severe problems here.

Product or Technology Change on Carrier Side may lead to different Level of Transparency

If the customer is unaware of the exact behaviour of the carrier’s Ethernet service at one point and “just doesn’t notice any problems”, a technology change (be a change of device firmware to a newer version, be a change of an infrastructure protocol’s configuration) may lead to security exposure. A well known historical example was the (mostly unannounced) introduction of a proprietary OSPF enhancement called Link Local Signaling in Cisco’s IOS which effectively broke OSPF sessions with (customer) Nokia devices after (carrier) IOS upgrades some years ago.

Inconsistent Transparency Level amongst “Carrier Ethernet” Product(s) from one Vendor

Carriers offering a nation- or even world wide Ethernet service may technologically implement the product in different ways, depending on the distance between sites (“Metro Ethernet” in case of regional offices, VPLS if far distance between sites). The different technologies may behave differently then as for the level of transparency.

Popular posts from this blog

Виртуальная сеть на базе 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 и подобные) Что касается открытых протоколов, – вероятность того, что они попадутся во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаютс…

Инженер электросвязи майнил BitCoin на $ 9.000 в день

Исследователь безопасности Эдвард Сноуден, ранее работавший в компании Booz Allen Hamilton говорит, что он обнаружил ряд совершенных одним системным оператором Bell Canada неавторизованых транзакций Bitcoin.



Для генерации биткоинов инженер электросвязи скомпрометировал пулы. В свою очередь, участники пулов продолжали отдавать часть производительности своих компьютеров на поиск блока криптографического алгоритма Bitcoin, при этом все получаемые им доходы доставались системному инженеру Bell Canada. Техника перенаправления обманывала участников для того, чтобы продолжать искать блок криптографических алгоритмов Bitcoin, позволяя сетевому оператору сохранить доходы на свой счёт. На пике своей деятельности, согласно подсчетам Сноудена, инженер электросвязи из Bell Canada перехватывал поток биткоинов и других цифровых валют, включая dogecoin и worldcoin, и обналичивал их в сумме около $9 000 в день.

Сноуден считает, что сетевой инженер из Bell Canada применил стандартные команды управлени…