Forgot your password?
typodupeerror
Security The Internet

The Internet's Biggest Security Hole Revealed 330

Posted by kdawson
from the kaminsky-was-a-warmup dept.
At DEFCON, Tony Kapela and Alex Pilosov demonstrated a drastic weakness in the Internet's infrastructure that had long been rumored, but wasn't believed practical. They showed how to hijack BGP (the border gateway protocol) in order to eavesdrop on Net traffic in a way that wouldn't be simple to detect. Quoting: "'It's at least as big an issue as the DNS issue, if not bigger,' said Peiter 'Mudge' Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. 'I went around screaming my head about this about ten or twelve years ago... We described this to intelligence agencies and to the National Security Council, in detail.' The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network." Here's the PDF of Kapela and Pilosov's presentation.
This discussion has been archived. No new comments can be posted.

The Internet's Biggest Security Hole Revealed

Comments Filter:
  • by symbolset (646467) on Tuesday August 26, 2008 @11:18PM (#24760119) Journal

    Must have the world's largest collection of online porn.

    Which would figure, actually.

  • Fun fun fud (Score:2, Interesting)

    by Anonymous Coward

    Everyone loves sensationalist news headlines. *sigh*
    Anyone have any insight as to how serious this ACTUALLY is?

    • Re:Fun fun fud (Score:5, Insightful)

      by lordsid (629982) on Tuesday August 26, 2008 @11:24PM (#24760167)
      Depends on how much you value your privacy.
    • Re:Fun fun fud (Score:5, Interesting)

      by QuantumG (50515) * <qg@biodome.org> on Tuesday August 26, 2008 @11:26PM (#24760191) Homepage Journal

      Let's put it this way. Email right? It's delivered between hosts completely unencrypted. Imagine you could sniff all the email passing into, say, the white house.. would that be worth something?

      Note, I've also given you the hint to prevent this bullshit from being a problem.

    • Re:Fun fun fud (Score:5, Insightful)

      by jd (1658) <imipak AT yahoo DOT com> on Tuesday August 26, 2008 @11:27PM (#24760209) Homepage Journal
      Find me an internet provider not using BGP, and I'll show you a European who favours ESES. Yes, this is a major problem, BGP is (almost) the only WAN protocol anyone takes seriously and is the only one meaningfully deployed. I've worried about the possibility of BGP poisoning attacks myself, but only because we have a virtual monoculture and monocultures are generally a Bad Idea. They are dangerous animals.
      • by Z34107 (925136) on Tuesday August 26, 2008 @11:57PM (#24760521)

        Monoculture is bad? Good thing Internet Explorer offers a different take on W3C standards...

        I kid, I kid.

    • by RuBLed (995686) on Tuesday August 26, 2008 @11:37PM (#24760309)

      Anyone have any insight as to how serious this ACTUALLY is?

      Yes. Someone had managed to re-open the goatse.cx site again.

      if you don't believe me, you know there is only one way to find out

    • Re: (Score:3, Interesting)

      by kjots (64798) *

      Anyone have any insight as to how serious this ACTUALLY is?

      How serious? This could potentially render the entire Internet inoperable. For real. Anyone who knows anything about basic Internet protocols should be shitting themselves right about now.

      What we have here is a basic weakness in one of the fundamental Internet protocols; an assumption of trust that is no longer valid. Think spam but a million times worse.

      I'm not usually one to fall prey to 'Imminent Collapse Of The Internet' hyperbole, but this one has me really worried.

      • Re:Fun fun fud (Score:5, Informative)

        by Anonymous Coward on Wednesday August 27, 2008 @12:50AM (#24760955)

        How serious? This could potentially render the entire Internet inoperable. For real. Anyone who knows anything about basic Internet protocols should be shitting themselves right about now.

        You obviously don't know the basics of Internet protocols then. Anyone who knows BGP basics knows this problem is inherent in current interdomain routing.

        This is not an attack that just anyone can pull off (unlike Dan's DNS vulnerability). You need possess a BGP peering relationship with a provider who doesn't filter the prefixes listed in the NLRI of a BGP update message, as well as any further upstream providers. A _very high_ bar to say the least.

        We're seen numerous accidental route leakages over the years and even some malicious hijacking of IP space for nefarious activity as noted in the presentation. Any significant hijacking for the purpose of MITM (hijacking for spam really isn't a priority for ISPs) would be tracked down instantly on the NANOG list and have severe peering repercussions for the offending ISP. Bumping the IP TTL isn't going to do squat for all the BGP anomaly detection systems continually monitoring the routing infrastructure (Renesys, PHAS, etc).

        • Re:Fun fun fud (Score:4, Informative)

          by adri (173121) on Wednesday August 27, 2008 @04:42AM (#24762149) Homepage Journal

          Just stuff the AS numbers of the BGP anomaly detection systems into the path you're using to hijack and voila! They'll never see it.

          The attack uses spoofed AS paths which include the AS numbers of the ASes in the -return path- of your hijacked traffic. It works because the default eBGP behaviour is to drop routes w/ an AS in the path that matches theirs (loop detection!)

          Its not fool-proof, but you -can- reasonably selectively remove ASes from receiving the announcements.

          Furthermore, if you know the topology near the network you're hijacking, you could figure out all the exit (transit) ASes, spoof those so the announcement never makes it out to the general internet and hijack the traffic near them. Dense peering relationships at multiple places around the internet == your friend in this method.

      • Re:Fun fun fud (Score:5, Informative)

        by lucifuge31337 (529072) <daryl@@@introspect...net> on Wednesday August 27, 2008 @10:12AM (#24764841) Homepage

        Anyone who knows anything about basic Internet protocols should be shitting themselves right about now.

        And those of us who actually do this stuff for a living (who already knew at least most of this) are neither surprised, nor any more paranoid about it. As a matter of fact, this might be the sauce needed to get more providers to properly filter announcements, and possibly more. So making this more public might actually be a good thing.

        The ability to hijack space is already very well known to anyone in a position to do it, and most of us have accidentally done so at some point in our careers. I know I haxxored 192.168.0.0 by accident once by announcing it to an upstream. Yeah....it happens. And it never should. TO this day, you'll more often than not see RFC1918 space being announced if you get a full routing table.

        BGP routing table entry for 192.168.0.0/16, version 3564
        Paths: (1 available, best #1, table Default-IP-Routing-Table)
        Advertised to non per-group peers:
        202.10.0.201 202.10.0.202
        Local
        192.0.2.1 from 0.0.0.0 (192.189.54.221)
        Origin incomplete, metric 0, localpref 101, weight 32768, valid, sourced, best
        Community: 2764:20

  • SSL (Score:5, Insightful)

    by jamesh (87723) on Tuesday August 26, 2008 @11:26PM (#24760185)

    I hope that all of those people who thought that getting users to blindly accept self signed certs was a good idea are starting to feel a bit stupid now...

    An SSL cert signed by a trusted central authority isn't the absolute solution to all mitm attacks, but it's a whole lot closer to 'safer' than not.

    • Re:SSL (Score:5, Interesting)

      by Free the Cowards (1280296) on Tuesday August 26, 2008 @11:30PM (#24760229)

      I don't think anyone thinks that self-signed certs should be blindly accepted.

      What should be done is that self-signed certs should be acceptable, with the right handling. The way ssh does this is a good one; it alerts you when you initially connect, and throws up an extremely loud and nasty warning if the host's cert has changed from the last time you connect. This gives you the opportunity to verify the cert out of band if you should care to, and forces an attacker to hit you on your very first access to a given site.

      Properly signed certs should be given higher priority, but a self -signed cert is still vastly better than nothing. The problem is that current browsers treat self-signed certs as being the worst of the three, when in reality they're much better than a naked HTTP connection.

      • Re:SSL (Score:5, Insightful)

        by Jah-Wren Ryel (80510) on Wednesday August 27, 2008 @12:00AM (#24760555)

        What should be done is that self-signed certs should be acceptable, with the right handling. The way ssh does this is a good one; it alerts you when you initially connect, and throws up an extremely loud and nasty warning if the host's cert has changed from the last time you connect.

        That's great and all if you are an internet mechanic. But what if you just want to drive the damn car? For those people, who are the majority, those messages don't mean squat. Which means they have just as much a chance of picking the unsafe choice as they do the safe choice. So Firefox's solution has been make it hard to pick the unsafe choice. Make it so that you pretty much have to understand what's going on in order to even get the chance to pick the potentially unsafe choice. That seems like a pretty good policy to me.

        • > So Firefox's solution has been make it hard to pick the unsafe choice.

          Except they really haven't. They've made it hard to make the sorta-kinda-theoretically-less-safe choice, the one that might result in a MITM attack, but in doing so they discourage SSL use generally.

          Do you think that hypothetical user you're talking about is going to notice whether the page is using SSL or not? I doubt it. And a lot of companies seem to agree, and use plain old HTTP for all sorts of stuff when they shouldn't (we j

        • Re:SSL (Score:5, Insightful)

          by bit01 (644603) on Wednesday August 27, 2008 @04:08AM (#24762027)

          For those people, who are the majority, those messages don't mean squat.

          Until self-signed certificates are less safe than bare http any justification for putting up scary messages for self-signed only is nonsense.

          The real problems that need to be fixed are:

          1. The potential for confusion between externally signed and self-signed and the degree of trust thus evidenced. Firefox should use a different lock icon for encrypted transport and for identity validated instead of conflating the two. Some more extensive interface change might be appropriate (color change somewhere?)
          2. It's a site change from externally signed to self-signed or bare, or from self-signed to bare that should be flagged. Firefox should remember signed site state and flag with popups when those transitions occur. Those popups should be integrated with the existing warning popups.

          That seems like a pretty good policy to me.

          It's not good policy to put up popups that have no meaning. Just like the boy that cried wolf and Vista UAC all you're doing is training the user to ignore popups when they do matter.

          Programmers complain incessantly about users ignoring messages. Almost always it's the programmer's fault for not designing their user interface for their target audience. Why on earth should a user take any notice of messages that

          1. are meaningless because they're written in software dialect English not mainstream English
          2. are often more important to the programmer than to the user
          3. do not give the user any avenue to respond. i.e. do not tell the user step-by-step what to do.

          ---

          "Advertising supported" just means you're paying twice over, once in time to watch/avoid the ad and twice in the increased price of the product to pay for the ad.

          • Re:SSL (Score:4, Insightful)

            by Jah-Wren Ryel (80510) on Wednesday August 27, 2008 @04:37AM (#24762125)

            Until self-signed certificates are less safe than bare http any justification for putting up scary messages for self-signed only is nonsense.

            Consider this - how often is a neophyte going to connect to a site with a self-signed certificate that actually has important information to keep encrypted but without any special instructions given ahead of time? Now how often is a neophyte going to connect to a spoof site (of a site which, by definition has important information, else it wouldn't be spoofed) with the use of a self-signed certificate?

            I think the second case is going to be a lot more common than the first.

            It's not good policy to put up popups that have no meaning. Just like the boy that cried wolf and Vista UAC all you're doing is training the user to ignore popups when they do matter.

            Talk about missing the point. Neophytes will NEVER know what to do with a pop-up of highly technical nature like this one. So better that the pop-up guide the neophyte into the default safe case while still providing information and choice to cognizant users. That's exactly what firefox does now.

          • Re: (Score:3, Insightful)

            by radarsat1 (786772)

            Programmers complain incessantly about users ignoring messages. Almost always it's the programmer's fault for not designing their user interface for their target audience.

            whoa whoa whoa... what is the programmer doing designing the user interface??

            I kid, I kid. I know it happens all the time, even I do it. But in the cases of companies like MS or even larger organizations like Mozilla, I'm not really joking..

        • Re:SSL (Score:5, Insightful)

          by maztuhblastah (745586) on Wednesday August 27, 2008 @09:47AM (#24764405) Journal

          That's great and all if you are an internet mechanic. But what if you just want to drive the damn car? For those people, who are the majority, those messages don't mean squat.

          And you know, teenage kids who "just want to drive the damn car" are also responsible for a substantial portion of collisions. Coincidence?

          The fundamental mistake of computer security is assuming that it can be made easy for the lowest common denominator. It can't. Sorry, I've got no clever analogy for this one -- but it's true. There is simply no way that you can design a system that can retain its security in the face of a user that is both ignorant and has no desire to learn how to properly use the tools at his disposal. You just can't do it. Warnings will be ignored, errors will be bypassed, and someone who wants to remain ignorant will, no matter how many hoops he has to jump through to do it. Most users aren't just ignorant -- they revel in it: how many times have you heard someone say "Oh, I'm just hopeless with computer stuff", followed by a smirk and a giggle? There ain't enough crypto in the world can protect that user.

          Designing a security measure around the lowest common denominator will make everyone less secure, all in the name of making someone who wants to remain ignorant slightly more comfortable. And for the benefit of all of us who want real security, this is a very, very bad idea.

      • Re:SSL (Score:5, Insightful)

        by nine-times (778537) <nine.times@gmail.com> on Wednesday August 27, 2008 @12:12AM (#24760657) Homepage

        Properly signed certs should be given higher priority, but a self -signed cert is still vastly better than nothing. The problem is that current browsers treat self-signed certs as being the worst of the three, when in reality they're much better than a naked HTTP connection.

        Exactly. I certainly don't want to sign on to my online banking for the first time and find that it's using a self-signed certificate. On the other hand, if I had to choose between a self-signed certificate and transmitting login information in plain-text, there's no contest.

        I'm of the opinion that encryption should be encouraged in order to stop simple snooping, even if it doesn't prevent more complex attacks. It's not as though certificate authorities are all that diligent in their identity verification anyhow.

        • Re: (Score:3, Insightful)

          by epine (68316)

          This whole debate would be better centered if Firefox put up the same scary boxes for unencrypted .htaccess as it does for self-signed certs. How could one be worse than the other?

          Unless you use a password generator (such as apg on OpenBSD) and have a photographic memory, passwordsafe, and never suffer hang-overs, most people re-use similar password structure even if the careless passwords and careful passwords are significantly different (which I doubt is the norm).

          What do you think the entropy is on the

    • Re:SSL (Score:5, Informative)

      by Antique Geekmeister (740220) on Tuesday August 26, 2008 @11:31PM (#24760245)
      And you actually trust Verisign to be a primary signature authority for SSL? Why? They've cooperated in all sorts of stupidity, such as their temporary insistence on returning their own squatting domain as a valid entry for every non-existent domain in *.com, which was particularly nasty because they own the .com master servers. Do you really think that Verisign is that secure, and wouldn't cooperate in faking keys if a national security agency asked them to?
      • Re:SSL (Score:5, Informative)

        by jd (1658) <imipak AT yahoo DOT com> on Tuesday August 26, 2008 @11:38PM (#24760325) Homepage Journal
        They gave away Microsoft's private keys to someone who called them, a while back, in a rather infamous case that forced Microsoft to change their entire update system and their collection of "secure" sites. If they've done it once, it can clearly happen again, and the lack of publicity may simply be evidence of better media management. I'd be very wary of trusting them with anything and would be skeptical of any institution that relied on Verisign for any kind of critical proof-of-identity situation, though they're probably reasonable enough for personal certs.
        • Re:SSL (Score:5, Informative)

          by Anonymous Coward on Wednesday August 27, 2008 @12:24AM (#24760749)

          Here's a link to information about the incident you mentioned:

          http://www.microsoft.com/technet/security/Bulletin/MS01-017.mspx

        • Re:SSL (Score:5, Informative)

          by dacut (243842) on Wednesday August 27, 2008 @02:30AM (#24761547)

          They gave away Microsoft's private keys to someone who called them

          Not quite. Microsoft's private key wasn't compromised; their identity was stolen. The attacker convinced VeriSign to sign his certificate claiming to be "Microsoft Corporation." The whole point of PKI is to never transmit your private key, even to an authority like VeriSign. As usual, the technology is secure; it's the people running it who aren't.

  • Scary Much? (Score:5, Informative)

    by creature124 (1148937) on Tuesday August 26, 2008 @11:27PM (#24760201)
    I find the thought of this genuinley scary. Correct me if I am wrong, but we would have to change the BGP protocol itself to fix this issue. That isn't going to happen anytime soon I reckon, so I guess there is nothing we can do but encrypt senstive transmissions and hope for the best.
    • Re:Scary Much? (Score:5, Insightful)

      by dlgeek (1065796) on Tuesday August 26, 2008 @11:33PM (#24760265)
      Well, no. Large ISPs don't have to accept and forward routes from customers without verifying them. The solution to this is the same as preventing forged IP source addresses: stop it at the origination point. If you're an ISP with customer A and customer A starts advertising routing for an IP range they haven't previously advertised, don't accept the advertisement and forward it up the chain until you verify that they actually should advertise that route.
    • Re: (Score:3, Informative)

      by jd (1658)

      BGP is supposed to be authenticated between peers, but clearly not nearly enough. If IPSEC was enabled (it's likely to already be present) on all routers, then BGP traffic between routers would be guaranteed both encrypted AND authenticated. Or, if you prefer, there are a very very few other routing protocols for WANS - ESES probably being the one most taken seriously. (ESES is the exterior gateway version of ISIS. Both are mature protocols with a lot of hardware out there that can support them.)

      • ESES is mature? (Score:5, Insightful)

        by thegameiam (671961) <thegameiam@@@yahoo...com> on Wednesday August 27, 2008 @12:01AM (#24760567) Homepage

        I've seen implementations of ISIS, and have deployed it myself in both IP and ATM environments. I've never seen an actual deployment of ESES, and I've never heard of one either. I've encountered ISIS adjacencies which don't form correctly, and come up as ESIS, though.

        What hardware supports ESES?

      • Re:Scary Much? (Score:5, Informative)

        by Alascom (95042) on Wednesday August 27, 2008 @12:39AM (#24760853)

        BGP is authenticated, and using IPSec will not solve anything. BGP peers must configured the IPs of their neighbors, and in many cases an MD5 secret as well. This is pretty strong authentication. The point here, is that anyone can get a high-speed link from an ISP, and that ISP will talk BGP to you. Then you simply tell you ISP about your network through BGP, and also tell it about some additional network routes and the ISP passes it along.

        The way to prevent this today, would be for the ISP that peers with you to know which IP blocks you own, any filter out any other routes your send over. But, this is a lot of work for the ISP so very few of them do it.

  • by teknopurge (199509) on Tuesday August 26, 2008 @11:34PM (#24760279) Homepage

    BGP is almost always setup manually, at least when first configured. Network admins: DO NOT PUT UNTRUSTED PEERS IN THE ACLs. Joe smith running BGP on 123abcxxxhost.nl has no business being in your tables. If you're accepting adverts from any AS you deserve what you get.

    The routing on the Internet has always been hierarchical: get updates from your upstreams. If they send you bad info you're SOL anyway, just like SSL certs and Verisign's root certs.

  • by Caspian (99221) on Tuesday August 26, 2008 @11:35PM (#24760291)

    ...that the good folks at the NSA (and/or the FBI, CIA, DHS, ATF, etc., as well as their counterparts in other nations) have been exploiting this for years.

  • This is the guy who taught the NSA how to spy on us en masse.

    I'm glad he exposed the truth. Now we can protect against it. right?

  • by sleeponthemic (1253494) on Tuesday August 26, 2008 @11:38PM (#24760323) Homepage

    A hacker marauding by the name "Goatse" exposed it quite effectively some years back.

  • ...he could bring down the internet in 30 minutes...

    OK, So do it. Now.

    Really.

    (Just don't wait until I am 90 and on Internet based life-support, without my consent because my money-grubbing heirs are just waiting for such a thing to happen then :-)

  • I archive the talk (Score:5, Informative)

    by stits (1351949) on Tuesday August 26, 2008 @11:39PM (#24760345)
    It was really cool, opened a lot of peoples eyes. Here is the archive, http://www.stits.org/fp/Defcon_16/ [stits.org]. Please don't flood it and only download it if you will use the info. I also took a ton of photos: http://www.flickr.com/photos/stits/sets/72157606608859399/ [flickr.com] Hope to see you all next year!
  • by Alsee (515537) on Tuesday August 26, 2008 @11:40PM (#24760361) Homepage

    Wait, you're telling me that they taught US intelligence agencies and the National Security guys how to attack the internet with man-in-the-middle attacks and exploits to fool routers into re-directing data to an eavesdropper's network...

    and they didn't do anything to end the interception and eavesdropping problem???

    I am shocked.

    -

  • by kwabbles (259554) on Tuesday August 26, 2008 @11:40PM (#24760369)

    The guy's been involved in many of security's moments in history.

  • by mbone (558574) on Tuesday August 26, 2008 @11:43PM (#24760405)

    There is a lot of harm you can do, least for a short while. But I have to say, this seems like a lot of FUD to me.

    It is not trivial to get BGP peering, or to keep it if you are doing bad things. You will need one or more peers, and they will have to do this for you manually, not automatically. And (as I can attest) the AS prepending this attack relies on is a very blunt instrument.

    Here are the troubles I see

    - You need to be able to offer a better path from Point A to Point B than the existing Internet topology

    - Unless you are Dr. Evil and can afford infinite bandwidth, this better path had better not also apply to a large chunk of the Internet, or you will get hosed with a lot of bandwidth (and, also, instantly stick up on the screens of NOCs all over the place) and

    - If you are relying on AS prepends, these affect the path from you, but not directly the path to you. They are notoriously tricky and may stop working (because of changes in other people's advertisements) at any time.

    So, to me, this is a might work sometimes for some people in some places, but probably not that well on a general basis.

    The DNS cache poisoning sounds a lot worse, frankly.

    • by CodeBuster (516420) on Wednesday August 27, 2008 @12:09AM (#24760643)

      You need to be able to offer a better path from Point A to Point B than the existing Internet topology.

      It has been done before. In fact for many decades during and after the Cold War the United States offerred some of the best quality data services at the highest speeds for cheap prices (subsidized by your tax dollars) merely to ensure that the majority of the international telephone and non-satellite data traffic passed through the United States somewhere along the way from Point A to Point B.

      Unless you are Dr. Evil and can afford infinite bandwidth, this better path had better not also apply to a large chunk of the Internet, or you will get hosed with a lot of bandwidth.

      As I mentioned above the US Government can afford a lot of bandwidth when they want to and they want to ensure that as many ISPs around the world chose our fast subsidized fiber backbones (I say backbones because last-mile service for consumers in the US still sucks hard core compared to Korea, Japan, and even Europe) to route their traffic across the globe (i.e. they lease bandwidth from US companies and the data passes through US borders). If some people don't think that US companies are complicit in this, *cough* AT&T *cough*, then the whole telecom immunity debate just went over their heads.

      So, to me, this is a might work sometimes for some people in some places, but probably not that well on a general basis.

      Better than none of the time so why not try and make the best of it if you can (NSA's point of view).

    • Correction (Score:5, Informative)

      by thegameiam (671961) <thegameiam@@@yahoo...com> on Wednesday August 27, 2008 @12:12AM (#24760655) Homepage

      - If you are relying on AS prepends, these affect the path from you, but not directly the path to you. They are notoriously tricky and may stop working (because of changes in other people's advertisements) at any time.

      Not quite.

      Prepends affect your outbound announcements, and this affects inbound traffic to you. Prepends are the most effective tool for BGP manipulation because they're transitive - announcing more specifics works too, but that's not quite the same thing.

    • Re: (Score:3, Informative)

      by DeadBeef (15)

      I haven't come across a good technical description of the attack, but I expect that the AS path prepending is just to stop the transit AS that you are using to reinject the traffic from sending the traffic straight back at you.

      ie. if you know AS666 is a transit for AS69 (that you are hijacking the traffic from), then you prepend AS666 in the path you advertise to the rest of the internet and bgp loop detection on the routers in AS666 will drop the bogus path and send your traffic to the real target AS69 ins

  • Sigh... (Score:3, Insightful)

    by ZarathustraDK (1291688) on Tuesday August 26, 2008 @11:46PM (#24760425)

    'I went around screaming my head about this about ten or twelve years ago... We described this to intelligence agencies and to the National Security Council, in detail.'

    For a hacker he's pretty dumb. Everyone knows that the best way get attention directed to an exploit is to publish the entire kiddie-porn-folder of the person who can fix it, using the exploit in question.

  • by Animats (122034) on Tuesday August 26, 2008 @11:49PM (#24760459) Homepage

    I looked at this problem back in the early 1980s, when I was doing some work on TCP. I was trying to come up with a routing protocol that didn't require passing the same information around repeatedly, because backbone networks had very low bandwidth back then, and the existing routing protocols had either O(N^2) traffic or the "hop count to infinity" problem.

    I came up with something called "Gateway Database Protocol", which was a scheme for passing tuples of the form "X says Y=Z" around. The idea was that any node seeing inconsistencies in "X says ..." would propagate the tuple back to X, revealing the problem to X.

    This is enough to detect hijacking, but not enough to stop it. I'd worked out a scheme good enough to automatically correct erroneous data, but not one good enough to deal with the insertion of hostile data. The design goal back then was to guarantee that if the hostile site was removed from the network (perhaps forcibly), the system would then stabilize into a valid state.

    That's not enough any more. But it is worthwhile considering that a routing protocol should have the property that if X's info is being faked anywhere in the network, X hears about it. BGP doesn't do that.

  • Latency jump (Score:4, Informative)

    by Bill, Shooter of Bul (629286) on Wednesday August 27, 2008 @12:02AM (#24760571) Journal
    The whole MITM thing would raise a flag unless the attackers were close enough to the real routers for the ip address block it was hijacking. Several companies I know notice when BGP screws up and doubles their latency. They notice and complain loudly.
  • by frovingslosh (582462) on Wednesday August 27, 2008 @12:16AM (#24760681)
    a drastic weakness in the Internet's infrastructure ...to eavesdrop on Net traffic in a way that wouldn't be simple to detect. ... testified to Congress in 1998 ... disclosed privately to government agents how BGP could also be exploited to eavesdrop. '..... We described this to intelligence agencies and to the National Security Council, in detail.'....

    Great, give the very people who want to abuse this the most the inside details, then show shock when it isn't fixed.

  • that requires one teensy weensy detail to work (in other words, one huge wonking detail)

    here, it is to be a bgp level peer

    kind of like i can empty a bank of all of its money

    all i need is the key to the safe

    yeah, minor detail

    so do i panic now?

  • by Doc Ruby (173196) on Wednesday August 27, 2008 @01:08AM (#24761065) Homepage Journal

    So these guys go and convince the spooks that the Internet can be hijacked for comprehensive but totally stealth eavesdropping. And the spooks "don't do anything about it".

    Except they do, don't they. The spooks go ahead and snoop the entire Internet. For the last 10 years.

    I'm surprised at only the fact that the L0pht guys and others are still alive and running around loose to tell anyone that the spooks have known how to do this for this whole time.

    Why is it taking so long for all Internet traffic to be encrypted end to end by default?

  • brilliant (Score:3, Insightful)

    by binaryseraph (955557) on Wednesday August 27, 2008 @02:19AM (#24761487)
    Oh great idea, lets go straight to the NSA, FBI, CIA, SS and any other agency out there and explain in full detail how to spy on the entire world. Wow, real shocker they didn't fix this one. Even bigger Internet Security Hole: Best Intentions.
  • One Word (Score:3, Insightful)

    by Nom du Keyboard (633989) on Wednesday August 27, 2008 @02:35AM (#24761581)
    One word: encryption.

    End-to-end encryption prevents eavesdropping.

  • I think not (Score:5, Insightful)

    by DrHyde (134602) on Wednesday August 27, 2008 @05:41AM (#24762327) Homepage

    A man-in-the-middle attack on BGP would require that you intercept and re-write BGP data. The only place to do that is if you can insert some hardware on the physical route between two BGP-speaking routers. That is, on the cable between two ISPs that are peering with each other or have a transit agreement. While the BGP protocol could, in theory, be routed across the internet, my understanding is that in practice it never is.

    Add to that that to successfully perform such an attack, you would need appropriate (expensive) network interfaces and hardware capable of speaking fast enough, and this "attack" becomes something that needs a *lot* of resources to pull off. Sure, governments and big corporations can do it, maybe big organised crime could too, but yer average bedroom cracker couldn't.

    And why would the big boys bother anyway, when they can just announce bogus routes [renesys.com]?

1 + 1 = 3, for large values of 1.

Working...