attacks on MPLS?

http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

This is different from ATM or FRAME or Private lines how? In the end,
MPLS is just a transport layer for the private network, if you don't
secure your data over a transport, shocker, people can see it!!!

(I recognize steve knows this fact already...)

-Chris

Well if we pull apart the article a bit....

Quote 1)
Network infrastructure security has been in the limelight lately, with researchers uncovering big vulnerabilities in the Domain Name System (DNS), the Border Gateway Protocol (BGP), TCP, and in Cisco routers.

Wasn't aware of any big vulns in BGP (are they referring to the defcon talk that rehashed ages old bgp trust exploitation?). Cisco vulns (I realize cisco released several patches recently but not aware of any signifcant vulns).

Quote 2)
own set of switches and management infrastructures, and their own set of surrounding technologies," he says, "and the average attacker could not get his hands on that equipment."

Hmmmm. Really? http://www.gns3-labs.com/2009/01/23/mpls-vpn-and-traffic-engineering/ + torrent the appropriate IOS images. That seems like it would be enough to build a lab environment for exploit development.

Seems like the article is a lot of fear mongering.

Steven M. Bellovin wrote:

I'll wait to read their full presentation, but according to the
article it appears to me that if they have gained access to a Network
Management station or a Router, that the entire network has been
compromised, not just MPLS.

Meh...

Sure, it rehashes what we pretty well already know, "If a bad guy can
get access to your network or your management tools, you're boned."

It's still worth reminding folks that they need to take appropriate
measures to defend and monitor these devices. Too many networks and
servers get hacked not because the attacker was good, but because the
administrators (some of whom tend to be good security guys) became
complacent and stopped doing routine upkeep. So in that sense, a
little fear can be a good thing.

-Wayne

Wayne E. Bouchard wrote:

Meh...

Sure, it rehashes what we pretty well already know, "If a bad guy can
get access to your network or your management tools, you're boned."

Naturally. If one gets to the control plane of your routers and/or management network you have big problems. :slight_smile:

However if they develop a script kidde tool that twiddles the bits in the middle.... that's a bit more concerning, as it may be difficult to detect without significant monitoring.

It's still worth reminding folks that they need to take appropriate
measures to defend and monitor these devices. Too many networks and
servers get hacked not because the attacker was good, but because the
administrators (some of whom tend to be good security guys) became
complacent and stopped doing routine upkeep. So in that sense, a
little fear can be a good thing.

Oh of course.

actually... what it says is that 'hey, your "VPN' isn't really
'private' like an IPSEC tunnel was". Save some really high-end
crypto-cracking-gear if you ipsec your transport it doesn't matter
where in the world it goes, it's "secure" from end to end. (secure
from snooping, which seems to be the majority of their point in the
article).

Folks I saw at former-employer were moving from 'frame' or 'atm'
private networks and to 'mpls vpn' because it was:

1) less complex for the customer
2) cheaper for the customer
3) the 'new shiny thing!!'

There was little understanding initially that this might be:
1) run over the same IP core as the 'internetz'
2) not very 'private' if you count 'can not sniff' in your 'is
private' bailiwick
3) less/more/equally as 'secure' as what they had previously.

Noting to customers that MPLS-vpn was essentially as 'secure' as
Frame/ATM was sort of an eye-opener. Some of the customers even said:
"Why would I do this over internet-based IPSEC vpn?" or "Oh, so I'll
still have the IPSEC management pain?"

The thrust of the article (aside from the scare-mongering and press
for the 'researchers' of course) is that: "Hey, just because it says:
'VPN' in the name doesn't mean its really 'private'", and that ip or
application level security is still important for anything that leaves
your physical perimeter AND has some level of importance to you or
your business.

-Chris

That right there, is right on the money. In my past, I've delt with so many folks that are of the mindset that they're invulnerable due to their firewalls, router acls, etc. Fear can be a very effective driving force to ensure that one is diligent in protecting the network that they're entrusted with. When that little amount of fear is replaced by over confidence, then most often, complacency comes shortly thereafter. At that point is when things can go south in a hot minute.

They presented on the same topic at shmoocon, not sure if the info is any
more updated for BH EUROPE, but here is the pres they did in Feb09

http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf

oh and heres the vid so you can see the demos

http://www.shmoocon.org/2009/videos/AllYourPackets-Rey.m4v

* Christopher Morrow:

Steven M. Bellovin wrote:

http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220

So 2001 (*), slide 46+ here:

  http://www.securite.org/presentations/secip/BHUS-IPBackboneSecurity.pdf

(*) this slide deck is from a talk we've given in 2002 (and contains more
    details than the 2001 one).

Nico.

Modification to VPN labels in MPLS is interesting however it assumes that providers have exposed their core network to customers. Traffic can be injected into different MPLS VPNs by modifying vpn labels but this is not a trivial attack scenario. For one thing, it would mean the attacker has a view of existing traffic, an understanding of which VPNs are using specific labels, and a path that is inline to modify/inject traffic.

By this same token, attacks on route target membership associations to vpnv4 prefixes would also be a valid attack method. It's all feasible, but it's not trivial.

Truman