1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?)
2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where.
No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops.
3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops.
The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought?
4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack.
Would that network operators were so diligent.
And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch.
Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point.
Why use ISDN (ATM) when you can do something useful?
what do mpls, ipsec tunnels, ssl have anything to do with someone
announcing your address space and hijacking youre prefixes??
i think we all know this is not new.. and these guys didnt claim it to
be.. they're not presenting this to a 'xNOG' crowd, defcon has a
different type of audience..im not saying they dont know about this
kind of insecurity, but it is nice to see this material being
presented, and exposing it to different 'groups' especially with a
live demo...
The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing.
When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list.
The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing.
You are very confused how traceroute works.
Being confused is fine. Lots of people are confused & ignorant. In fact, everyone is ignorant about more things than they are educated about. However, when people like Adrian, who are clearly more versed in the technology than you are, try to educate you, ignoring his kind help and repeating your confusion to 10s of 1000s of your not-so-close friends is not fine.
Please read Adrian's post again, read about traceroute, and try not to post until you have understood them. (To be clear, if you come to the conclusion you are right and Adrian is wrong it means you have _not_ understood them.)
When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list.
The fact you do not understand how traceroute works makes it obvious why you misunderstand how to diagnosis something from that lack of understanding.
VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen.
"VPNs" do no such thing. To prove this to yourself, realize that IPsec and SSL are both types of "VPNs".
Encrypting the data is very useful. Hell, Anthony & Alex say so themselves. But that wasn't the point of the presentation. (And we'll ignore the fact that the size, speed, and even existence of a data stream - encrypted or not - might be useful information to a miscreant.)
Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r.
The traceroute utility that I used gave me a list of hops that the
packet I was interested in transited and a time when it transited the
hop. When the TTL was reached it would terminate the listing.
But if I can control your traffic I could change everything, couldn't I?
I mean, with the ability to inject whatever I wanted, I could spoof
traceroute, yes? I could filter for that traffic and return whatever I
wanted.
I could manufacture a series of packets showing that NYC and London were
only 10ms apart in such a case.
Thanks guys, going back to my Comer one more time. My issue, question was whether the organization doing the hijacking controlled all of the routers in the new modified path or only some of them?
They didn't have control of any routers other than their own. What they had to find is a single clueless upstream ISP that would allow them to announce prefixes that didn't belong to them.
Clueless or big and inattentive? AFAIK, Level3 will accept anything from me...as long as I put it in one of the IRRs the day before I plan to announce it.
That is correct. However, once a packet hits the miscreant's device, the traceroute is defeated.
Assuming their device is in the right place, you will not be able to see the difference.
Assuming it is in the "wrong" place, you may be able to detect the intrusion. But most people do not run traceroutes all day and watch for it to change. If you run the traceroute after the attack starts, well, how are you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02-$BLAH-$BAR is right?
Uhhh... network monitoring with traceroute and topology tools. There
are several off-the-shelf varieties to choose from, and I know of
several providers that use them.
I stand by my assertion that most people do not run traceroutes all day and watch for it to change.
That some people are diligent does not change the fact the overwhelming majority of people are not.
Or the fact that with the right placement of equipment (read "luck") and cooperation of networks involved (read "laziness"), even a traceroute won't show any change besides additional latency.
Leaving aside the ability blackhole prefixes that don't belong to you, they seem to harp on the part of being able to intercept traffic.
Well, yes?
Personally I don't trust GBLX (sorry) or whoever with my traffic any more than a random hacker who is rerouting the traffic. That's why things like SSL were invented. Yes, with that much control even SSL can technically be broken but if there was ever a pretext of complete trust about the possibilities of snooping on traffic then encryption wouldn't need to exist.
Ultimately though, the detailed work that needs to go into pulling something like that off would make it quite hard not to leave a trail somewhere. Also, it's still far easier to just pop a trojan onto a few million machines.
Shameless media hyperbole anyway... I think they saw the DNS people getting their 10 minutes of fame and wanted their own
They didn't have control of any routers other than their own. What they had to find is a single clueless upstream ISP that would allow them to announce prefixes that didn't belong to them.
Clueless or big and inattentive? AFAIK, Level3 will accept anything from me...as long as I put it in one of the IRRs the day before I plan to announce it.
Working for a company that has been steadily growing through acquisition, we have actually run into this problem a couple times before. I'm not sure if we hit the lottery, but our upstream providers (including LVL3) have definitely intervened when we've moved netblocks from a company that doesn't match our name into our facilities to be advertised under our ASNs. I'm not sure how diligent or widespread the validation checks are, but at least on occasion they do occur.
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?)
People (especially spammers) have been hijacking networks for a while now, maybe now that we have a presentation to whore around, operators can pressure vendors and bosses.
"Sprint has expanded its global MPLS network capabilities with
network-to-network interface (NNI) partnerships and has introduced the
industry's first standard end-to-end MPLS VPN SLA as part of its global
network."
I stand by my assertion that most people do not run
traceroutes all day and watch for it to change.
That some people are diligent does not change the fact the
overwhelming majority of people are not.
Or the fact that with the right placement of equipment (read
"luck") and cooperation of networks involved (read
"laziness"), even a traceroute won't show any change besides
additional latency.
Bingo!
Latency is the magic word and that *IS* measured by a lot
more people than do traceroutes. Unless the attackers are
lucky enough or smart enough to do their dirty work from
a server that is reasonably closely colocated to the router
that they exploit, you *WILL* see latency changes.
It would be wise to change the process for investigating
latency increases to include examining routers for this
BGP rerouting exploit.
