Блог

Network Device Compromise

Obviously this is the first (and probably most likely) possibility that comes to mind. The North American Network Operators’ Group periodically collects data on network security incidents amongst its members. The following slide shows that devices from carrier environments actually get compromised in the real world:

Device Injection

The term “device injection” designates all scenarios where an untrusted party is enabled to place a device under its own control in the MPLS network of a carrier. While this may seem highly unlikely for an attacker (to “insert” an own device in a datacentre with strong physical access controls) it should be noted that some carriers allow very large customers to run their own PE routers (thereby potentially violating the assumption of a “trusted core which is solely managed by the carrier”). Similar scenarios might arise when PEs are located on customer premises which is why this practice is commonly advised against, see for example the following slide from a Cisco Live conference in 2010:

Wire Access

By this term all those scenarios are designated where an attacker gains access to the traffic path of certain packets without necessarily having compromised a device. This includes physical access to the wire as well as traffic redirection attacks in shared network segments.

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.

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.

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:

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:

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

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.

The peer again is a Cisco 3750ME with a MPLS-VPN virtual routing and forwarding table associated with the customer ‘RED’:

Loki is then used to inject the MPLS-VPN routing information:

Before setting up the session we need to overwrite the default session parameters with our custom BGP capabilities. This is done by filling in the optional connection parameters.

Next the AS number and the hold timer needs to be set. At last the target host is missing, which in this example is the host with the IP address 10.10.10.1. After clicking on “Connect” a session setup is performed.

If loki is able to establish the connection, a background keep alive thread is started, which sends an BGP keep alive packet every hold time / 4 seconds.

The next step is to assigns the BGP update message. 

This message defines, which routing information to publish to the connected host. In the example case we build up a RFC4364 Multi-Protocol-BGP update packet, which says we are announcing the network 192.168.113.111/32 with the route distinguisher 100:0, which should be forwarded to the next hop 10.10.10.10. In the end we send the prepared update message by clicking on “Update”.

After publishing the routing information, the routers virtual routing and forwarding table for the customer ‘RED’ looks like this:

One can see the new route for the host 192.168.113.111 pointing to our attack host (10.10.10.10). Click here to dowload Loki.

Trust Model

LDP uses TCP to establish sessions between two LSRs. UDP is used for basic operations like discovery mechanisms which are periodically sent over the network to a well-known discovery port for all routers of a specific subnet. As these are sent to the “all routers on this subnet” group multicast address, with regard to the discovery process all routers on the local link are regarded trustworthy.

Security Controls Inherent to Technology

To protect the authenticity and integrity of LDP messages, LDP supports the TCP MD5 signature options described in RFC 2385. It has to be activated at the LSRs and may protect the messages by validating the segment by calculating and comparing the MD5 digest. To use the MD5 option a preconfigured password on each LSR is necessary.

Attacking LDP

Loki contains a universal LDP module, written in python. It implements the most common used LDP packet and data types and can be used to participate in the LDP discovery process, as well as establish targeted LDP sessions for advanced signaling. If such a targeted session is established, the tool starts a background thread which sends keep-alive packages to hold the connection open and the signaled data valid. To create such signaling data e.g. EoMPLS virtual circuits signaling, the module provides build-in data types which can be merged to the appropriated signaling packet.

An Example for signaling EoMPLS virtual circuits

The peer is a Cisco 3750ME was configured, but not activated virtual circuit:

Loki is the used to establish an LDP session and to send the necessary signaling information:

First Loki needs to take part in the LDP discovery process; this is done by activating the Hello-Thread via clicking on the “Hello” button. Next the remote host tries to connect the attacks host via TCP, so Loki needs to listen for that incoming connection; this is done by activating the Listen-Thread via clicking on the “Listen” button. Once the Connection is established, the remote Host will show up in the Host-List. The next step is to configure the LDP update message, which defines the signaling message to publish to the remote host. In this case we generate a LDP Label-Mapping-Message. In the end we send the prepared update message by selecting the designated host from the host list and clicking on the “Update” button.

After sending the LDP Label-Mapping-message the configured virtual circuit is activated on the remote side:

So we activated the virtual circuit and mapped it to a label defined in the update message. A tool like mplstun could be used to set up a valid endpoint on the attacker’s side. Click here to download Loki.